Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Users assigned to submissions after changing their roles lose access to files to which they should have it #9127

Closed
Vitaliy-1 opened this issue Jun 29, 2023 · 5 comments
Assignees
Labels
Bug:1:Low A bug that does not have a severe consequence or affects a small number of users. Hosting Bug reports and feature requests from Publishing Services's hosted clients.
Milestone

Comments

@Vitaliy-1
Copy link
Collaborator

Describe the bug
Described in this comment
If user was assigned to a submission in one role and then the role has changed, SubmissionFileAccessPolicy won't grant access to the file even if new role should allow the access. E.g., user was assigned as a journal editor and then demoted to a section editor, or assigned as designer and promoted to the section editor.

Such behaviour was introduced by this commit as part of this issue aimed to prevent double-assigned editors from accessing unauthorized files.

To Reproduce
Steps to reproduce the behavior:
See: #9104 (comment)
In this case this policy is failing:

$subEditorFileAccessPolicy->addPolicy(new AssignedStageRoleHandlerOperationPolicy($request, Role::ROLE_ID_SUB_EDITOR, $roleAssignments[Role::ROLE_ID_SUB_EDITOR], $stageId));

What application are you using?
OJS, OMP or OPS version stable 3.3.0, 3.4.0, main branch

@Vitaliy-1 Vitaliy-1 added Hosting Bug reports and feature requests from Publishing Services's hosted clients. Bug:1:Low A bug that does not have a severe consequence or affects a small number of users. labels Jun 29, 2023
@Vitaliy-1 Vitaliy-1 added this to the 3.3.0-15 milestone Jun 29, 2023
@asmecher asmecher modified the milestones: 3.3.0-15, 3.3.0-16 Jun 30, 2023
@Vitaliy-1
Copy link
Collaborator Author

User with manager role assigned as an assistant with stage restrictions, e.g., designer, will have an access to all workflow stages and submission files. I think AssignedStageRoleHandlerOperationPolicy was created to prevent this

Vitaliy-1 added a commit to Vitaliy-1/pkp-lib that referenced this issue Jul 4, 2023
@Vitaliy-1
Copy link
Collaborator Author

PRs pkp-lib
main: #9133
tests: pkp/ojs#3961

Requires porting to stable branches

@Vitaliy-1
Copy link
Collaborator Author

Vitaliy-1 commented Jul 4, 2023

@asmecher, can you review this PR?

edit
It appears to me like a more general problem with user accessible roles in case of dual assignments. I think, the solution applied for this issue is better: #9131 (comment). I'm keeping the PR here open in case if there are drawbacks with a general approach.

@Vitaliy-1
Copy link
Collaborator Author

This PR modifies AssignedStageRoleHandlerOperationPolicy in the way that it grants the access to submission files according to stage assignments, even for roles with global access, like managers and admin. E.g., journal editor assigned as a layout editor won't have access to files in the submission stage. When this user loses the layout editor global role, the access to submission files is restored - meaning that assignment as a layout editor isn't taken into account. This prevents the bug described above.

What this PR doesn't change, is the access for dual assigned users with managerial roles to workflow stages. In the example above, journal editor assigned as a layout editor still has access to all of the stages. It doesn't affect also review files as they are controlled by SubmissionFileAssignedReviewerAccessPolicy

@Vitaliy-1
Copy link
Collaborator Author

Should be fixed by #9131

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug:1:Low A bug that does not have a severe consequence or affects a small number of users. Hosting Bug reports and feature requests from Publishing Services's hosted clients.
Projects
None yet
Development

No branches or pull requests

3 participants