[OJS] change of rights/operation for the Production Editor role between version 3.3 and 3.4.

[forgive38]

In OJS version <=3.3, the production editor has access to all stages of all submissions, even if assigned to the submission as production editor.

In 3.4, the production editor has access to all stages of all submissions EXCEPT on a submission to which he/she is assigned as production editor.

I think the way the Production Editor role works in version <=3.3 makes more sense.

[asmecher]

@Vitaliy-1, can you have a look at this one?

[Vitaliy-1]

@Hafsa-Naeem, can you check whether it's still relevant for 3.5 and 3.4?

[Hafsa-Naeem]

@Vitaliy-1 Ready for review:
OJS (stable-3_5_0): pkp/pkp-lib#10387 Submodule update ##Hafsa-Naeem/i10387_stable-3_5_0_fix
pkp-lib(stable-3_5_0): pkp-pkp-lib#10387 Restore Production Editor access to workflow stages #11731
ui-library (stable-3_5_0): pkp-pkp-lib#10387 Restore Production Editor access to workflow stages #693

[Hafsa-Naeem]

@Vitaliy-1 Reminder to review, thanks.

[Vitaliy-1]

@Hafsa-Naeem, that also would likely require migration and some other changes and considerations...

I don't mind returning it to how it was before but in that case the role of the production editor would look like useless. What is the difference from the journal editor, who also has access to all stages? @jardakotesovec, you just raised the similar question. Do you think we should return the behaviour back for now?

As far as I recall, that came with #9131 - alongside with other issues, including dual assignment. Thus, returning it back might require digging deeper into policies described in that issue

[Hafsa-Naeem]

Thanks for the comment, @Vitaliy-1
For this PR, I've limited the changes strictly to what was described in #10387 , aligning the Production Editor's permissions with the expected workflow rules between 3.3 and 3.4. The current behaviour was inconsistent across policies, which is why these updates were needed.

Regarding the broader implications (migrations, reassessing the role, or revisiting #9131): that feels outside the scope of this specific issue. #10387 doesn’t request re-defining the Production Editor role or changing its responsibilities... it only addresses the permissions regression that happened during the transition.

@asmecher, i remember discussing this issue but may be I missed something.. could you confirm whether the intent here was just to fix the permissions regression, or whether we should instead revert to the previous behaviour and/or expand the scope to revisit the Production Editor role more broadly (including #9131)?

Once we have that clarification, I'm happy to adjust this PR accordingly.

[jardakotesovec]

Maybe just to note that if we make production editor to be able to access all stages even when he is assigned. Than we could clean up some of the special treatment that was introduced for production editor in #12002 and #10929 .

One of the places which I identified that was giving production editor only copyediting&production stages access is here - https://github.com/pkp/pkp-lib/blob/main/classes/user/Repository.php#L254 .

UPDATE: I see that the policies that are being touched are using that getAccessibleWorkflowStages. So if thats the only source of the truth, it could be simple adjustment there. I think what we do for 3.5 depends on our confidence in the change to avoid regressions. If we can confidently make production editor access all stages as before, I would be supportive of that.

And I agree that restricting production editor when he is assigned is unlikely being useful.

Btw you can achieve this effect by giving user both JOURNAL_MANAGER and SECTION_EDITOR roles. Then if you assign such user to submission via SECTION_EDITOR role - it will apply the limitations that comes from SECTION_EDITOR (assuming he has some limitations configured for accessing stages)

[jardakotesovec]

Oki, now I remember, getAccessibleWorkflowStages is not only source of truth. For efficiency same logic is also in https://github.com/pkp/pkp-lib/blob/main/classes/submission/maps/Schema.php#L877 .

Either these two places would need to automatically add all stages for ROLE_ID_MANAGER (when being assigned), but especially in second scenario that would be quite difficult.

Thinking about alternatives. Do we have any tricks in sleeve to update the database, to have the assignments there? Could we maybe just check if the production editor logs in, whether the userGroupStages are already there and if not to add them?

Edit: Here is PR.. to basically give all the stage assignments for the ROLE_ID_MANAGER, regardless of its actual assignments - #12040 . That would probably make it work good enough (we can test this properly if we decide to go with this approach), but it for example does not cover listing of participants. So if there would be way to address it in database, I think that still would be least mess.