Pkp-lib: Implement access control for the publication tab features

[NateWr]

We need to decide what roles should have access to a) view the publication tab, b) edit a version and c) create a new version? My sense is that everyone who has access to the production stage should also have access to do these things. But we may want to consider whether some things, like creating a new version, should be more restricted. Or whether we need a new kind of permission, similar to how user groups can select the stages to which they should have access.

Once decided, we need to implement the access control to the publication tab.

We also need to make sure that the newly introduced feature to selectively permit users to edit metadata also works (https://github.com/pkp/pkp-lib/issues/3758).

Acceptance Criteria for OJS

• [x] When assigned as a copyeditor, I can only access and edit publication data when the submission is in the copyediting stage.
• [x] When assigned as a copyeditor, I can never publish a publication.
• [x] When assigned as a production assistant (eg - layout editor), I can only access and edit publication data when the submission is in the production stage.
• [x] When assigned as a production assistant, I can publish a publication when the submission is in the production stage.
• [x] When assigned as a section editor, I can access and edit publication data at any time.
• [x] When assigned as a section editor, I can publish a publication at any time.
• [x] When I am a Journal Manager and I am not assigned to a submission in any way, I can access and edit publication data, and publish a publication, at any time.
• [x] [API] All of the acceptance criteria above is the same when I am logged in as that user and try to issue POST and PUT requests to the /submissions/{submissionId}/publications/{publicationId} API endpoint.
• [x] Merge final fixes
• [x] After merging the final fixes, check the metadata editing issues for press editors.

---

Acceptance Criteria for OMP

• [x] when assigned as a copyeditor, I can only access and edit publication data when the submission is in the copyediting stage.
• [x] When assigned as a copyeditor, I can never publish a publication.
• [x] When assigned as a production assistant (eg - layout editor), I can only access and edit publication data when the submission is in the production stage.
• [x] When assigned as a production assistant, I can publish a publication when the submission is in the production stage.
• [x] When assigned as a press editor, I can access and edit publication data at any time.
• [x] When assigned as a press editor, I can publish a publication at any time.
• [x] When I am a Press Manager and I am not assigned to a submission in any way, I can access and edit publication data, and publish a publication, at any time. Publishing is possible, editing metadata is not possible for PM.
• [x] All of the acceptance criteria above is the same when I am logged in as that user and using apiToken and try to issue GET requests to the /submissions/{submissionId}/publications/{publicationId} API endpoint.

[asmecher]

@NateWr, I think the existing publication stage checkbox covers this nicely. Also, I'm hesitant to further densify our access controls at all, in anticipation of the changes that are tentatively planned for 2.3.

[NateWr]

@asmecher

Thinking about this a little further... since the title, abstract and metadata are now under the Publication tab, we'll need to make sure that users assigned to other stages can still access those parts. But we'll probably want to restrict access to the galleys and the issue entry details to those with access to the production stage.

Does this logic sound alright? (pseudo-code)

currentStage = the stage the submission is currently at
if (isManager || hasStageAssignment(currentStage, [sectionEditor,assistant])) {
  // allow access to title, abstract, metadata, authors, but not galleys
}
if (isManager || hasStageAssignment('production', [sectionEditor,assistant])) {
  // allow access to galleys, issue assignment, etc
}

So an assistant that is only assigned to the Copyediting stage would only be able to edit the metadata while the submission was in that stage, after which they would lose access.

Does that sound right or should we grant any editor/assistant with any stage assignment access to the metadata (except galleys/issue assignment) at all times?

[asmecher]

I think the first option makes sense. It would also support the second option if the manager chooses to configure the roles that way.

[librariam]

Testing acceptance criteria:

[pass] When assigned as a copyeditor, I can only access and edit publication data when the submission is in the copyediting stage.

[pass] When assigned as a copyeditor, I can never publish a publication.

[pass] When assigned as a production assistant (eg - layout editor), I can only access and edit publication data when the submission is in the production stage.

[FAIL] When assigned as a production assistant, I can publish a publication when the submission is in the production stage.
_Comment: As a layout editor assigned to a submission in production stage, when I attempt to schedule it for publication, I get “the current role does not have access to this operation” error. I have double-checked that the Layout Editor role has access to Production stage in the Roles grid._

[pass] When assigned as a section editor, I can access and edit publication data at any time.

[pass] When assigned as a section editor, I can publish a publication at any time.
_Comment: The criterion calls for "publish at any time", so this is to clarify the "publish" vs "schedule" test cases. As a section editor, I can schedule a submission into an issue at any time. A submission scheduled into an already published issue will be published immediately. However if I schedule a submission into a new issue, I do not have an option to publish that issue - no Issues tab visible to this role._

[pass] When I am a Journal Manager and I am not assigned to a submission in any way, I can access and edit publication data, and publish a publication, at any time.

I did not do the last criteria [API] - this would need to be assigned to someone else since I don't know how.

[NateWr]

Thank you @librariam! I've addressed the failing criteria in fd94a09.

[NateWr]

I've tested the API acceptance criteria and they all pass. However, I found a few more issues regarding who can view what when.

PRs:
https://github.com/pkp/pkp-lib/pull/5367
https://github.com/pkp/ui-library/pull/56
https://github.com/pkp/ojs/pull/2564
https://github.com/pkp/omp/pull/737

[withanage]

@NateWr

Acceptance Criteria for OMP

• [x] when assigned as a copyeditor, I can only access and edit publication data when the submission is in the copyediting stage.
• [x] When assigned as a copyeditor, I can never publish a publication.
• [x] When assigned as a production assistant (eg - layout editor), I can only access and edit publication data when the submission is in the production stage.
• [x] When assigned as a production assistant, I can publish a publication when the submission is in the production stage.
• [x] When assigned as a press editor, I can access and edit publication data at any time. ACCESSISG IS POSSIBLE, EDITING METADATA IS NOT POSSIBLE.

• [x] When assigned as a press editor, I can publish a publication at any time.

  - [x] When I am a Press Manager and I am not assigned to a submission in any way, I can access and edit publication data, and publish a publication, at any time. Publishing is possible, editing metadata is not possible for PM. ACCESSISG,PUBLISHING IS POSSIBLE, EDITING METADATA IS NOT POSSIBLE.

• [x] NOT TESTED [API] All of the acceptance criteria above is the same when I am logged in as that user and try to issue POST and PUT requests to the /submissions/{submissionId}/publications/{publicationId} API endpoint.

[NateWr]

Thanks Dulip! Once I get some final fixes merged I'll check out those two issues you had and see if I can reproduce them.

[NateWr]

@withanage I've merged in the permissions fixes. Would you be able to take another pass at the problems you found before (https://github.com/pkp/pkp-lib/issues/4874#issuecomment-5687749580) and see if they are fixed?

[withanage]

Thanks @NateWr
I have tested the both working scenarios and now all of them work.
I could also test the apiToken with get requests and they work too.
Updated the ticket header with all the confirmations.