[OJS] Provide option to restrict low-level editors to "recommend" only, not make decisions

[jmacgreg]

We've received this request from numerous science journals. They often have one or more senior editors who are overall responsible for submissions, and can make decisions, etc.; and lower-level editors who manage the review process but can only make recommendations, not editorial decisions.

The request would be to provide a configurable option at the role level to restrict said role to recommend only, not to be able to decide. This would be reflected in the review stage only. Such editors would see a "Recommend" button rather than the accept/reject buttons; and the "Recommend" button wouldn't commit an action, but would send an email to all recorded senior editors, and would be recorded in the history.

[alexxxmendonca]

This would be extremely benefetial for us. That's the case of several SciELO journals and it would likely be a solution to one of our customized SciELO Plugins.

👍

[NateWr]

the "Recommend" button wouldn't commit an action, but would send an email to all recorded senior editors, and would be recorded in the history.

And update the round status. (Just noting for later.)

[asmecher]

@jmacgreg, is this something that could be done through the Discussions tool, perhaps with some facilitation via templates and the like? Having the Discussions buttons actually make changes, vs. just having them just notify the Editor, feels like a potentially confusing behavior.

Alternately, perhaps we could introduce some kind of requested/confirmed behavior that could be skipped for full Editors?

[ajnyga]

I realize that the workflow was totally different in OJS2, but maybe Ubiquity Press' OJS modification for this same issue has something to offer to this discussion: https://github.com/ubiquitypress/OJS-Draft-Editorial

[jmacgreg]

@asmecher I think it could be (as suggested at https://github.com/pkp/pkp-lib/issues/2549). The Decision buttons would then just have to be hidden, and the SE would make the recommendation in a discussion.

However: there would be no additional notification, or recorded state (eg. "In review: recommendation to accept"). I could see some significant benefit to the "recommendation" being an actual reportable state, so that Editors could see it in the "Active" list, or in downloaded reports.

@ajnyga thanks for the link to that - I had forgotten! Here's a link to the patch: https://github.com/ubiquitypress/OJS-Draft-Editorial/commit/9135893848e9d40923c105a2cafc59b0529659c9. I think the workflow (and code) is different enough that we wouldn't be able to just merge this in, but it may provide a good reference for what production journals are working with.

[asmecher]

@jmacgreg, hmm, it does seem pretty important to have the Editor's status indicators show that the submission is awaiting confirmation, so they don't have to e.g. find a textual recommendation somewhere in a discussion.

[NateWr]

Is this just relevant to review rounds? If so, they have a status and we could add a decision-pending status there. (I'm using the review round status to flag up status stuff in the new submissions list panel I'm working on.)

[jmacgreg]

Hi Nate, yep - just relevant to review rounds, doesn't have any bearing on other stages. (Also, if you have any mockups of the submissions list panel, I'd love to see them. That's one of the areas that has been flagged as under-informative by some of our early adopters, and I'd love to see what you are doing there!)

[asmecher]

Hi @bozana -- something to start thinking about!

[asmecher]

(Note to myself as much as anything: this is a high priority for SCIELO and would be good to include in 3.1.)

[bozana]

Hi all,

Here some conceptual thoughts/questions regarding this issue and its implementation: How to implement "recommend only role"?

I think we cannot have a configurable option at the user role/group level, because it could happen that a user have different i.e. both roles, for different articles -- It looks to me that it is a per submission decision, right? -- i.e. we would need two different user roles/groups. Do you agree (above all @jmacgreg )?

Regarding the implementation: I think a new role permission level (s. https://github.com/pkp/pkp-lib/blob/master/classes/security/Role.inc.php#L18-25) is not necessary -- also to keep our access policies as they are -- the new role permission level is actually the same as the current role permission level "manager" or "sub-editor", just that it differs in review decision actions (recommend instead of a real decision) i.e. it looks more like a new user role/group to me. Thus I see two ways to solve this:

1) With an additional column or setting for a stage assignment: In this case the user would have the same current roles/groups (e.g. Journal editor or Section editor) and there would be a checkbox to define "recommend only" when assigning an editor/section editor to a submission, in the participants list. This option will have to be saved in the DB table stage_assignments i.e. we would need an additional column or _settings table there, which is maybe not so nice.

2) As a new default user group: Additionally to the current default user groups "Journal editor" and "Section editor" we would have a group "Recommend only editor" (or something like that). We would have to see if the sub_editor role would be enough for this group, or if it should be the role manager? In this case, a user would need to have that user role/group assigned to her/him. The assignment to a submission in the participants list would be the same as till now i.e. the new user role/group and the appropriate user would have to be chosen/assigned. We would then have to differentiate this user role/group somehow, thus also here a new DB column (something like "recommend_only") in the table user_groups or a new setting in the table user_group_settings would be needed. If I see it correctly, then only an additional case have to be considered here: https://github.com/pkp/pkp-lib/blob/master/pages/workflow/PKPWorkflowHandler.inc.php#L205 -- when defining the decisions actions to be displayed.

I think I prefer the solution number 2.

@asmecher, what do you think would be the best way to implement it? If we implement it as a new user role/group, what do you think would be the best way to differentiate that group?

Thanks a lot!!!

[ajnyga]

I have a lot of spoons... "I think we cannot have a configurable option at the user role/group level, because it could happen that a user have different i.e. both roles, for different articles -- It looks to me that it is a per submission decision, right? -- i.e. we would need two different user roles/groups."

I think that editors would prefer giving a user role once than deciding this on every submission?

[bozana]

@ajnyga, but would that user then only be able to recommend and never make a decision? -- Maybe a user can act differently -- for one submission it would be able to decide and for another it would be only able to recommend... Somehow I think that we will have to enable this possibility (that a user can act as both) too, right? Similar as a user can be an editor, but also a reviewer or author or... He/she would need to have all the roles/groups and then it will be decided/assigned which role/group she/he has for a submission...

[alexxxmendonca]

I agree with @ajnyga.

At least for the SciELO Brazil journals, that is something that works across the board.

Basically we have journals where the final decision is only up to the Editor-in-Chief (Section Editor only recommends), and we have journals where the final decision is shared by both the Editor-in-Chief and the Section Editor.

But at least in our case, this is not something submission-based, but role-based.

[ajnyga]

Ok, fair point. I guess it all depends on how you build the UI for making the decision.

edit: but maybe having just a specific role with these permissions is more transparent and obvious for the editors?

edit2: nevermind, I finally figured out how the option 2 above works

[bozana]

As @jmacgreg suggested above, the user with the role/group "Recommend only" (assigned as such a participant in the participants list) would only have the button "Recommend" while the user with the role/group "Journal editor" or "Section editor" would see the decision buttons.

@alexxxmendonca, in your case then, the current "Section Editors" will have to have the new role/group "Recommend only" in those journals, so that they will only be able to recommend.

Theoretically, as @jmacgreg said we could consider a configurable option at the role level -- that would be per journal because the roles are defined per journal -- but I think this restricts that that role is always used in the same way (either just recommending or just making decisions) in a journal, which excludes the other journals where a user should act in both ways, differently for different sections or articles. The other solution -- having a new user role/group -- would support everything.

[ajnyga]

@bozana https://i.imgflip.com/q0p1h.jpg

[jmacgreg]

Hi all,

The scenario I see is that you have the role, for example “Guest Editor” or “Assistant Editor” which have been created with the “recommend only” option, and they always can only recommend (as per the configuration). If a person who is initially a guest editor eventually graduates to a position of higher responsibility, they would be assigned a new role. If they have two editorial roles for some reason, the higher role should override the lower role - so, for example, if they were originally enrolled as a guest editor, and then were added as a section editor (who could make decisions), but were not relieved of the guest editor role because someone forgot, they should be able to act as the section editor.

Does that make sense? Basically: roles should be configured once and then probably rarely modified; and user authorizations should change by which role is assigned to them.

Cheers, James

On Aug 15, 2017, at 8:29 AM, bozana notifications@github.com wrote:

As @jmacgreg https://github.com/jmacgreg suggested above, the user with the role/group "Recommend only" (assigned as such a participant in the participants list) would only have the button "Recommend" while the user with the role/group "Journal editor" or "Section editor" would see the decision buttons.

@alexxxmendonca https://github.com/alexxxmendonca, in your case then, the current "Section Editors" will have to have the new role/group "Recommend only" in those journals, so that they will only be able to recommend.

Theoretically, as @jmacgreg https://github.com/jmacgreg said we could consider a configurable option at the role level -- that would be per journal because the roles are defined per journal -- but I think this restricts that that role is always used in the same way (either just recommending or just making decisions) in a journal, which excludes the other journals where a user should act in both ways, differently for different sections or articles.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pkp/pkp-lib/issues/2433#issuecomment-322453271, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMS5ilM5J4855r07iNaf2vuXlX_r8mVks5sYY8SgaJpZM4M449j.

[ajnyga]

If I understood Bozana correctly, that is pretty much how the option 2 above would work.

When assigning the section editor / Recommend only editor to a new submission, you would do: => Add participant => List all "Recommend only editors" => Choose the right one

Here you could have a person with both roles (section editor or Recommend only editor), all depends on which role you use when you assign the person to the submission.

Or, I am totally lost with @bozana's suggestion :)

[bozana]

Yes @ajnyga you are right... that is what I was thinking... The thing is that you always have to assign a user to a submission in a specific role/group -- via the participants list you will always have to chose a role/group and then the user. This defines the role/group of that user within that submission. I thought that it would be good to have an extra role/group for "recommend only" (and not to change the existing one) and this role/group would always only recommend -- in order for the existing roles/groups to further exist and for them not to clash with each other. This way any journal workflow would work: the one where a user can always only recommend and the one where a user could have both roles/groups, so that the user can sometimes only recommend and sometimes also make decisions. But... In general these possibilities are there: a) Define/configure the "recommend only" restriction per user with the role/group "Section editor" (or some other), on the user management page. This would restrict a user to only be able to act in one way, either just recommending or making decisions. b) Define/configure an existing role/group (e.g. Section editor) as "recommend only" on the journal level. This would restrict all users with that role/group to be able to act only in one way, either just recommending or making decisions. Also, we cannot use any arbitrary existing role/group for that -- the role/group permissions in the system have to stay and work as till now so that we do not have to implement the access policies anew. Thus the only existing role/group I see would be possible to adapt is Section editor -- Guest editor does not function at the moment as far as I know; we need Journal editor role/group as it is so that it can make decisions; other roles are not suitable/have wrong permissions and access policies. c) Define a new default role/group and call it whatever, that would have the same permissions as Section editor or Journal editor but would be restricted to only recommend. This way all users having only this role/group would only be able to only recommend, but there would be a possibility for a user to also have other role/group and to be able to make decision too, if needed/wished so for some cases. @jmacgreg and @alexxxmendonca, what do you think about these 3 possibilities? As far as I understand the solution b) i.e. restriction for the Section editor per journal would work in your case @alexxxmendonca, right? @jmacgreg, I am not sure if you prefer/suggest b) or c) and why? :-) And finally, very important, @asmecher what do you think especially with regard of our current permissions levels and access policies? Do you see any problems with the solutions b) and c) i.e. are my assumptions correct (e.g. could we use any other existing role/group than Section editor for b))? THANKS!!!

[alexxxmendonca]

That is right, option b) seems to work best for us. Option c) would work too but I think there are plenty of roles already and adding a new one could pottentially add a layer of complexity and confusion.

I am all for roles as standard as possible and having an option at the journal level setup in which journals can configure what kind of permission their Section Editor would have (final decision vs recommendation).

We developed a plugin that we call "Section Editor Workflow Options" that has the following options:

These options work in an cumulative fashion -- the journals can multi-select and the system would behave accordingly.

This is how we've been working (pretty well) so far with SciELO Brazil journals. But there is one thing missing: although the Section Editor can't record a decision, they can't record a recommendation either. That part is still missing and I hope this will be addressed in this new feature.

[NateWr]

Sorry to pile in here. My preference would be to take a hybrid approach of role-based and participant-based settings. I think this is a hybrid of 1&2 or a&b:

• Any role created with ROLE_ID_MANAGER or ROLE_ID_SUB_EDITOR has a configurable option defining whether they can recommend or make decisions. (Option in the Create/Edit Role form.)
• When a participant of ROLE_ID_MANAGER or ROLE_ID_SUB_EDITOR is assigned, their stage_participant record is assigned the decision setting from their role. (Option in the Assign Participant Form.)
• Any ROLE_ID_MANAGER can toggle the decision setting of any stage_participant. (Option in the Assign Participant Grid.)

In this way, roles define default behaviour and journal managers can override stage participant behaviour. But during the workflow, we only ever check stage_participant permissions to decide what a user can do.

[bozana]

@NateWr thanks a lot! I think that would cover everything, so if no objection I will go with that... Maybe then just one more question: I can use user_group_settings to save that setting for a user group. Shall I add a new column for the DB table stage_assignments? -- currently there is no DB table stage_assignments_settings...

[ajnyga]

Maybe this is already mentioned and thought of, but what actually happens when the new "junior section editor" presses the "Recommend" button? I mean, does it open an email tempalte and she will have an opportunity to enter free text of some sort that the editor will see?

[bozana]

@ajnyga, when the button is pressed, a modal will be displayed with the recommendations list and an e-mail template for the editors. The recommendations will get new constants, like the decisions here https://github.com/pkp/ojs/blob/master/classes/workflow/EditorDecisionActionsManager.inc.php#L20-L26. They will be saved together with the decisions in the DB table edit_decisions. For now, they will only be displayed in the submission's Editorial History. That is what I thought...

[NateWr]

@bozana it might be worth thinking about how this intersects with #1662. Ideally, a stage could have a status which we could query in the database (and then filter by in the submissions list). And a status which could be used to indicate to a Journal Manager that a recommendation has been made would be useful.

[bozana]

@NateWr, oh yes, I will... 👍

[asmecher]

Sorry to jump in at a late hour -- good conversation so far. Some options (just for the sake of considering):

• What about just adding a journal setting that causes all ROLE_ID_SUB_EDITORs (e.g. Section Editors, Series Editors) to be able to just recommend rather than recording?
• What if we forced this to be always enabled, i.e. made all Section Editors recommend-only? (@stranack) This may seem radical, but it may suit users of that role (who are in the minority -- most journals just use Editors/Managers, I bet)

Both options would be relatively low on code, and the latter wouldn't cause an additional parallel "mode" we need to maintain/test.

[ajnyga]

Hi all,

Regarding @asmecher suggestion two, I think that there is a problem there. Many journals use Section editors to solve the problem that editors see ALL the submissions, including their own. So although using section editor role, they presume that the role has full rights.

Also, Section editors in many cases have a specific section to take care of and I would presume that the editors of the journal may not want to double check everything that is happening in the section the section editor is taking care of.

I am worried about the workload of the editor here.

[bozana]

I agree with @ajnyga. Thus, I would rather leave the configuration option for the user group management page, when editing and creating a new user group and only for groups with role_id_manager and role_id_sub_editor. As @NateWr suggested.

But: could we maybe not put the option for a stage_assignement? -- the stage_assignment is so much used in the code, so I will have to double check every place, if the new option has to be considered somewhere there, e.g. when building a new stage assignment, inserting or updating. Thus would it be OK to say: if the journal needs a user to have both roles/groups (recommending and decision making), it should create a new manager or sub_editor user group with the recommendOnly option checked, so that both groups would exist and the user would have them both. Else, if the journal does not need a user to have both roles/groups i.e. if it is enough to have either commending or decision making, than the appropriate configuration for that group has to be made. And we will then only look at the group setting and stage_assignment could stay as it is. I already started to implement the new option for stage_assignment -- so not a problem at all -- I just wanted to double check and hear you opinion if this other solution (considering only the group configuration and necessity to create a new group by the journal, if a user should have/act with both roles/groups) would work equally well/intuitive for the users/journals, because it would mean less changes. What do you think about that? THANKS!!!

[NateWr]

@bozana Your dual-role suggestion makes sense. And if I understand the needs of others who have commented, it sounds like it will capture 90%+ of the use-cases. It's always hard to balance the benefits of one approach with the additional work it might require. So I'll just outline what I see as the benefits of housing the permissions in the stage assignment.

From a UX perspective, the dual-role approach requires a certain amount of lateral thinking for the use-case where a manager wants the same person to make decisions on some submissions and recommendations on others. First, the manager arrives at a situation where they have an editor who they want to have different capabilities than they usually have on a system. The manager must understand how participants have roles, and how these roles effect the workflow for a participant. Then they must know that they can set up an editorial role that only recommends in a different part of the app (Users > Roles > Add New Role). Then they must know that a single user can have multiple roles. Then -- the lateral thinking part -- they must use their knowledge of the participants system, the roles system, and the user identity system to intuit a solution to their problem in which they combine these systems. As developers, this seems obvious to us because a) we know the systems pretty well and b) our job day in and day out is to find novel solutions by combining systems like this. But it's a big ask for a non-technical user, so we end up investing time in expanding documentation or answering questions in the forums to get them over the hurdle.

By placing the permissions into the stage assignment, we can surface the option when (during participant assignment) and where (in the submission itself) a journal manager is most likely to encounter a need for it. This isn't always successful, but when done right we short-circuit the lateral thinking required which allows people to identify and solve the needs more easily themselves.

From a platform maintenance perspective, I think we gain more long-term flexibility by introducing the option to the stage assignment. If each assignment has it's own permission, we'll also enable customisation requests we don't yet foresee. For example, perhaps one journal wants only journal managers to be able to make decisions for submissions to a particular section. If the data structure already supports assignment-based permissions, it would be much easier to write a small plugin to do this.

Neither of these benefits necessarily means it's worth the extra investment of time and energy that will be needed now. And implementing the dual-role approach you describe wouldn't preclude us from changing the approach later.

[bozana]

Yes, OK, I see... :-) I will then continue as already started... with the option for a stage_assignment... :-) THANKS A LOT!!! :-)))

[bozana]

@NateWr, I defined these review round statuses:

// The following statuses are calculated based on the statuses of recommendOnly EditorAssignments // and their decisions in this round. define('REVIEW_ROUND_STATUS_PENDING_RECOMMENDATIONS', 12); // Waiting for recommendations to be submitted by recommendOnly editors define('REVIEW_ROUND_STATUS_RECOMMENDATIONS_READY', 13); // One or more recommendations are ready for an editor to view define('REVIEW_ROUND_STATUS_RECOMMENDATIONS_COMPLETED', 14); // All assigned recommendOnly editors have made a recommendation

I would then leave it to you to decide how to display them on the submission listing page, OK? Or, if you would tell me how, I could do it :-)

[NateWr]

Ok great. We'll need to surface this information in the API at least for the backend endpoint. We'll need to know if the current user can make decisions on each stage, and we'll need access to those new constants.

We've got an approach for passing constants to the frontend here that should get merged soon.

Then we'll probably want to add the information about the current user's capability to each stage in the SubmissionService::toArrayStageDetails() method:

https://github.com/pkp/pkp-lib/blob/master/classes/services/PKPSubmissionService.inc.php#L450-L551

Eventaully we may want to add some details about the stage assignments. But for now I think just a key in each stage currentUserCanMakeDecisions set to true or false should be sufficient to display the right notice to the right users.

[bozana]

@NateWr, just to double check/be sure because I have not such a good overview yet: Because the recommendOnly option is only applicable to the review stages, I will add currentUserCanMakeDecisions index/key (set to true or false) to the stage array/data only for the internal and external review stage in the SubmissionService::toArrayStageDetails(), correct? Else, I will wait till the constants PR is merged, then I will add the constants in the same way to the controllers/list/submissions/PKPSubmissionsListHandler.inc.php and eventually try to add them correctly in the js/controllers/list/submissions/SubmissionsListItem.vue. And, later we can then see to provide details about a stage assignment somewhere. Correct?

[NateWr]

@bozana Yeah, just add the currentUserCanMakeDecisions boolean to the review stage for now. (Or should it be currentUserCanRecommendOnly? Whatever matches your existing naming scheme better.)

Then I presume the review round status information is getting passed already. So you can already update SubmissionsListItem.vue by checking the review round status without the constants, and add them in later.

[bozana]

PRs: pkp-lib master: https://github.com/pkp/pkp-lib/pull/2749 ojs master: https://github.com/pkp/ojs/pull/1512 omp master: https://github.com/pkp/omp/pull/438

[bozana]

@NateWr, could you review those PRs above?

Some notes: In a strange case where an user was assigned to a submission in the editorial role several times and one of those assignments have recommendOnly option set, the user will have recommendOnly permissions i.e. only recommending and not the decision making possibility.

If the editor recommendation is made before any review is completed, the recommendation review round status will be considered and displayed however. If the recommendation is pending i.e. not yet made, the review statuses have the priority and are considered and displayed -- first when all reviews are there, the pending recommendation notification/status is displayed.

Similar to the reviews statuses also the recommendations statuses will not be saved in the DB table review_rounds -- they will only be determined in the function ReviewRound::determineStatus().

UI/UX for participant assignment: The recommendOnly checkbox is displayed only if the user chooses an user group that has this option set.

Upgrade: the existing user groups will have no recommendOnly option set and the new column "recommend_only" for the DB table stage_assignments should be created with default values "0" for the existing assignments.

[NateWr]

Looks great! A few comments on UI/UX stuff:

In a strange case where an user was assigned to a submission in the editorial role several times and one of those assignments have recommendOnly option set, the user will have recommendOnly permissions i.e. only recommending and not the decision making possibility.

I wonder if we can do both. If a user has a stage assignment that can recommend only, show the recommend button. If a user has a stage assignment that can make decisions, show the decision buttons. This would lead to a case where a user might have a recommend button alongside the decision buttons. This might allow them to opt for a recommendation in cases where they want a senior editor's input.

Any thoughts on this from @jmacgreg, @alexxxmendonca or @ajnyga?

If the editor recommendation is made before any review is completed, the recommendation review round status will be considered and displayed however. If the recommendation is pending i.e. not yet made, the review statuses have the priority and are considered and displayed -- first when all reviews are there, the pending recommendation notification/status is displayed.

:+1:

Similar to the reviews statuses also the recommendations statuses will not be saved in the DB table review_rounds -- they will only be determined in the function ReviewRound::determineStatus().

:+1:

UI/UX for participant assignment: The recommendOnly checkbox is displayed only if the user chooses an user group that has this option set.

I'd like to see the checkbox displayed for any editorial user role, but set to checked or unchecked by default based on that user role's setting. That allows us to fulfil the one-off cases where an editor won't have set up a special role, but wants to restrict a section editor to recommending.

Also, I think you'll need to update the checkbox visibility when a user is selected, rather than when a role is selected. At the moment, I can choose a role, select a user, check the recommend option, then change the role. The user selection disappears, but the recommend option is still around.

I think you'll need to update the checkbox visibility on:

• A new role is selected: hide the checkbox.
• A user is selected: show/hide the checkbox.

Upgrade: the existing user groups will have no recommendOnly option set and the new column "recommend_only" for the DB table stage_assignments should be created with default values "0" for the existing assignments.

:+1:

A few other notes:

1. If a recommendation is in, show the recommendation that was made above the recommend button and change the button label to "Change Recommendation. Similarly, for the overseeing editor, display the recommendation, either in the notification at the top of the stage, or directly above the editorial decision buttons.

2. Can we capture the recommendation email in a discussion instead? We'd get a log of any further discussion that happened, a task for each participant in the discussion, and users will eventually be able to better control their own email notifications related to discussions.

3. The skip email option label is "Do not send author email" but this should be "editors".

[alexxxmendonca]

I wonder if we can do both. If a user has a stage assignment that can recommend only, show the recommend button. If a user has a stage assignment that can make decisions, show the decision buttons. This would lead to a case where a user might have a recommend button alongside the decision buttons. This might allow them to opt for a recommendation in cases where they want a senior editor's input.

That sounds good to me 👍

And the other notes are good, too. Specially Note 1 -- very important. It's not so unusual the Editor-in-Chief requesting the Section Editor to review their recommendation.

[bozana]

If a recommendation is in, show the recommendation that was made above the recommend button and change the button label to "Change Recommendation. Similarly, for the overseeing editor, display the recommendation, either in the notification at the top of the stage, or directly above the editorial decision buttons.

@NateWr, I think there could be several recommendations -- the decision making editor could ask several other editors to make recommendations. Thus, should they all be displayed as notifications?

Also a recommending editor can change recommendation, so there could be several recommendations from the same editor, but I will then only display the last one in that case, right?

I am not sure that I understand number 2 correctly -- to create a discussion with all assigned decision making editors instead of sending them an e-mail, correct?

[NateWr]

I think there could be several recommendations -- the decision making editor could ask several other editors to make recommendations. Thus, should they all be displayed as notifications?

You should only display one notification. Can you display all the past decisions in a single notification? That'd be best, but I know it can be hard to get the notification to display some custom content. If you can't get them all into a notification, maybe list them above the editor decisions.

Also a recommending editor can change recommendation, so there could be several recommendations from the same editor, but I will then only display the last one in that case, right?

Yeah that sounds good. They can go to the editorial history if they want all the details.

I am not sure that I understand number 2 correctly -- to create a discussion with all assigned decision making editors instead of sending them an e-mail, correct?

Yeah, that's what I was thinking. The editors should receive an email when a discussion is created. They'll also get a task created.

[bozana]

Hmmm... Sorry @NateWr, a few more questions :-\ I would then use the same text (i.e. e-mail template) for the e-mail body and the discussion message -- because I do not think the e-mails are generally sent when a discussion is created and thus I would then also need to add such an e-mail template... -- OK? Then shall I also leave the checkbox "Do not send editors email" in the recommendation form? What kind of task should be created: That a recommendation is there/ready? Or just to create a task if all assigned recommending editors have made a recommendation and thus the decision should be made? THANKS!!!

EDIT: also for each recommendation a discussion will be created. And what about a recommendation change? Maybe also to add an option "do not create discussion" in the recommendation form?

[NateWr]

Hmm... all good questions. I'm stepping away for the day, but it would be good to get some feedback from @jmacgreg or @alexxxmendonca regarding whether to prefer email or discussion creation, or both.

What kind of task should be created

When a discussion is created, a task it created for that which just says "A new discussion has been opened." If we go the discussion route, I think it's ok to rely on this and not create anything else.

[alexxxmendonca]

I would think e-mail notification is essential. Many editors rely on this, otherwise the Editor-in-Chief would have to access the system to check if there is a new task alerting about the new discussion.

Personally, I think e-mail is a must, discussion is a plus.

[bozana]

@NateWr, I made all changes, I believe :-) Could you please take another look? All changes are in the pkp-lib. There is still one thing to do: to reload the page after assigning a participant in the review stage/on the review page as well as after recording a recommendation (in order to display the recommendations and discussions, if exist).

Notes: A discussion will be created every time a recommendation is recorded. There is now also a checkbox "Do not create review discussion" (similar to the option "Do not send editors email"), so that this can be skipped.

The editor's last recommendation is displayed in a div above the editor actions buttons. If an editor is assigned in both roles, with a recommendOnly as well as makingDecision permission, he/she will see both, his/her last recommendation as well as all (last) recommendations (from all editors) above that.

[bozana]

@NateWr, thanks a lot for reviewing!!! I fixed the bug and added a small test for recommendation -- there is one new commit in pkp-lib and ojs for that. I will wait to see if something else should be changed, then I will integrate it into OMP as well... THANKS!!!

[NateWr]

This looks really good! I just noticed one issue with the discussion creation. the {$recommendation} variable doesn't seem to get injected into the text of the discussion.

[bozana]

Thanks a lot @NateWr! Crazy -- I see where the problem/bug is -- but the variable is replaced for me :-O I'll fix it... My new recommendation test has a problem with PostgreSQL -- the only thing I can imaging is because of the creation of the new column for the DB table stage_assignments... but... Hmm... I'll see how could I debug that... @asmecher, is it possible to get that PostgreSQL dump? THANKS!!!

[bozana]

I figured it out, why the tests for PostgreSQL are failing... Hopefully they will go through now... @asmecher, I modified one of the existing submissions tests to test the recommendation -- I hope that's OK so... ?