Allow journal managers to invite users to adopt a role

[ajnyga]

Tagging @bozana here

The issue is discussed here: https://forum.pkp.sfu.ca/t/ojs3-editing-user-roles-in-multi-journal-installations/28711

The problem: if a user is registered to more than one journal, the journal manager can not edit the roles the user has in her journal. In OJS2 this was possible and in OJS3 journal managers can still add the reviewer role when doing a review assignment.

Suggestion:

• allow editing user roles within a given context but do not allow editing the user detail (name etc.).
• add a new "edit roles" feature to the users grid
• for users that exist in multiple journals, do not show the "edit" feature for journal managers (no use if they can not edit anyway)

Problem with legislation: @bozana raised the problem with data privacy and user "contracts". Maybe we could just send a notification when journal managers adds a new role for a user. Basically the same thing we do now with the reviewers in OJS3.

[NateWr]

I've given this a "Community Priority" label because there does seem to be demand in the forum for better handling of this scenario.

I think we should consider an "Invite user to be a X" feature. It would send an invitation email, which would grant a user a role when they click on the link in the email. It should also display the invitation URL, so a Journal Manager can copy/paste that into any existing communication they have with the user.

This would address privacy issues and also give editors a more straightforward way to accomplish what they want. @ajnyga any objections to this approach? If so, I may rephrase the issue title to be more specific.

[ajnyga]

Hi,

Invite makes sense and would work very well IMHO, I think this was also discussed as one option in the forum thread above.

A connected matter is that is it ok GDPR wise that for reviewers we create an user account (name, email) without the consent of the user when the reviewer does not exist in the database?

[NateWr]

After some discussions about #2860, it was decided that this is a necessary feature alongside some changes with the new users list panel, so we'll be transitioning the Add User process over to an "invite" workflow for journal managers.

This will include adopting an invite workflow for the Reviewer selection as well, so it will be good to keep #1146, and the whole Reviewer Selection project (https://github.com/pkp/pkp-lib/projects/7) in mind.

Admins will still be able to add or edit a user at will.

[ajnyga]

Just checking, after the planned changes, can an editor remove an editor role from another editor in the same context if that editor is also enrolled to another context?

This is needed when an editorial board changes.

[NateWr]

That's a good question. I think the current system allows that to happen, and don't foresee that changing. But I don't know whether it should be possible. My gut reaction would be to allow it.

[ajnyga]

Pretty sure the current system does not allow it. It will not let a journal manager to access the user profile form at all if the user is registered in multiple contexts.

What if there would be a separate form that would only show the list of available roles for the selected user:

• For site managers selecting a role for a user would add the role instantly
• For journal managers selecting a role would send the invite for the role
• For both site managers and journal managers deselecting a role would drop that role instantly

So as you suggested, just allow journal managers to remove roles. I do not think that GDPR poses a problem to this direction.

[Enro]

Hello, sorry to jump in without taking the time to read the full discussion. I just wanted to mention a potential link between this issue and this GDRP-related feedback https://forum.pkp.sfu.ca/t/privacy-concerns-regarding-user-enroll/19860 although I am not sure whether it still applies under OJS v3...

[NateWr]

Hi @Enro, yes we're aware of this issue, which is why it's been assigned to the GDPR project. It is also a blocker for #2860 (comment). We do see it as a priority and I personally have got a good few weeks' worth of work sitting on the shelf waiting.

[jmvezic]

Are there any updates on this issue?

[NateWr]

No, there have not been any movement recently.

[ajnyga]

Is #4959 somehow different? @NateWr @israelcefrin ?

[NateWr]

In this issue, a journal manager (ROLE_ID_MANAGER) should be able to invite a user -- any user to any role -- by entering their email address. That user may already have an account in the system for another journal, and in such cases the journal manager should not know that. Journal Managers should not be able to discover who has an account on a separate journal.

So the invitation workflow should work the same whether or not they already have a user account.

In #4959, we want any editor to be able to invite a reviewer. The solution for this issue should provide a general facility that we can use to solve #4959 (the invitation and acceptance workflow should be the same). But I don't think you need to actually support that for this issue. Just the ability to kick off an invitation from the users list should be sufficient for this.

[ajnyga]

Ok, you are probably correct that better tackle users & roles first, since the reviews is probably more complicated. But I already wrote this longer roundup that includes the review stuff as well.

Comments? @NateWr @asmecher @jmacgreg

Requirements

1. Users & Roles. We add a new "Invite user to a role" action that can be used to invite any user on the site based on an email address.

2. Add reviewer in Review stage. We replace the current "Add a new user" and "Enroll an existing user" actions with a single "Invite a new reviewer" action.

Workflows for editor

1 a. The editor needs to add an new user. The user has no existing roles in the context and the editor can not see her in the list. The editor selects Add new user and fills in the form. The system says that the email is already used => The system shows a link "Invite the user to acquire a role in [contextName]" => New modal window opens showing the users email (not editable) and a selection of roles (checkbox) that the invitation will include. At least one role needs to be selected to send the invitation.

1 b. The editor needs to add an new user. The user has some role in the context but the editor does not find her in the list for some reason. The editor selects Add new user and fills in the form. The system says that the email is already used => The system shows a link "Invite the user to acquire a role in [contextName]" => New modal window opens showing the users email (not editable) and a selection of roles (checkbox) that the invitation will include. The roles that the user already has are active but checkboxes are disabled. At least one role needs to be selected to send the invitation.

1 c. The editor needs to add a new role to a known user. The user has some role in the context and the editor finds her in the list. There is a new "Invite to acquire a role" action available. => New modal window opens showing the users name and email (not editable) and a selection of roles (checkbox) that the invitation will include. The roles that the user already has are active but checkboxes are disabled. At least one role needs to be selected to send the invitation.

1 d. The user has role X in the context, the editor needs to remove role X from that user. What should be done with this? We could of course allow users the deselect editorial roles by themselves from the User Profile? This would be the most GDPR compliant way.

2. The editor tries to send a review request but the selected person is not a reviewer yet or the editor does not find her on the list. We have a new "Invite a reviewer" action that opens an ordinary review request form that has an email field on top. The editor fills in an email address and checks the request details and sends in the request. As long as the reviewer has not reacted, the system will only show the email address in the review assignments grid. (@NateWr, I know you have been thinking of using hashkeys, but here the editor really needs to see some concrete information about who has been invited, has to be the email I think!)

Workflows for user

1. The user receives an email telling her that she has an existing user account in [siteName] and that she has been offered new roles in [contextName]. The email will then list the offered roles and will include an accept link. By clicking the link, the user will be logged in to the context and the offered roles are attached to her account. The system will give a success message.

2 a. The invited reviewer does not have an existing user account. She receives a message saying that she has been invited to do a review in [contextName] the review details are in the bottom. The email explains that she first has to create an user account by following the link given in the email. Clicking the link will open a simplified version of the registration form. After filling in the form, an user account is created, the user is logged in and then redirected to the review form step 1. At this point, the editor starts to see the full name of the reviewer in the review assignments grid.
There is also an alternative link for rejecting the request and in this case no user account is ever created.

2 b. The invited reviewer has an existing user account but no reviewer role. She receives a message saying that she has been invited to do a review in [contextName] the review details are in the bottom. Clicking the link will open review form step 1 which is now accessible for users without the reviewer role. By accepting the review, a reviewer role is attached to the user. At this point, the editor starts to see the full name of the reviewer in the review assignments grid. If the user declines, no role is attached.

2 c. The user was a reviewer already, but the editor did not find her and used the Invite a new reviewer action. Here the system will figure things out and will send an ordinary review request. The editor will see the user's name right from the beginning.

[NateWr]

This looks great, @ajnyga. I've had a read through and I think it covers things nicely. A few thoughts on the editor workflow:

• For the add user workflows (1a-1c), I think we should replace the Add User form with an Invite User form that is just an email address. If I recall, this was one of the GDPR conditions and I think it's a good practice for us to enforce. So the editor only ever provides the email address and the user fills in the details.
• For 1d, I think the editor can already do this, right? If an editor edits a user, they can remove roles.
• For 2, 👍. And yes, it's ok to use the email address in the reviewers grid.

On the workflows for user:

• These all look good, but buttons in emails are tricky things. Some email clients will strip out HTML code or cut URLs in half for line breaks. I think it will be most reliable for us to link to an invitation page where the user accepts or denies on the website (rather than from the email). For reviews, this can be part of the first "accept review" form.

[ajnyga]

For the add user workflows (1a-1c), I think we should replace the Add User form with an Invite User form that is just an email address. If I recall, this was one of the GDPR conditions and I think it's a good practice for us to enforce. So the editor only ever provides the email address and the user fills in the details.

Yes, in general we should not be creating user accounts without consent. Of course in many cases where the add user action is used it is usually creating editorial staff accounts and consent is maybe not a big issue. On the other hand, this new approach is also an excellent way of making sure the email actually works.

Maybe leave the old Add user form accessible for site managers?

For 1d, I think the editor can already do this, right? If an editor edits a user, they can remove roles.

They can not access any user settings if the user is enrolled in several contexts.

[NateWr]

Maybe leave the old Add user form accessible for site managers?

I think if we can make the case for GDPR, we should not include it. The invited user should have a chance to fill it out though.

@mfelczak what do you think? For GDPR we are switching from "add a user" where the journal manager adds all the details to "invite a user" where they enter an email and select the roles to invite them too. The user then has to fill in their own details. Do you foresee any gnashing of teeth with this?

[mfelczak]

From my experience I can see possible edge cases where it'd be helpful to retain the ability to manually add users without needing to go through the more formal invite user process. For example, when importing content or testing imports it's sometimes useful to be able to quickly create non-person import user accounts with test/invalid email addresses.

Given that this will be a significant change with impact for all journals, I can also check-in with a sample of our hosted journals to solicit input on this proposed change. I'm also including @amandastevens and @jmacgreg here as they may have additional feedback.

[NateWr]

Thanks @mfelczak. Would a ROLE_ID_SITE_ADMIN capability to simply confirm an invitation (similiar to login as) suffice to solve this problem?

[israelcefrin]

I was wondering how this change could affect a JM workflow and I have two points to draw attention at first moment regarding when a user is invited.

1. If an JM invites a user who was already invited, OJS should let the JM knows that that email address is already invited rather than only in use. This message should cover the time gap from the invitation till confirmation by the user.

2. When an user rejects the invitation, will the JM be able to invite again without any system warning? Because a user might be no willing to join the journal, and different JMs might be not aware of it and invite him over and over again till the user send an email complaining about it.

On that note, could a user have an option such like:

• I do want to join (accepts the invite)
• I don't wan join now (doesn't accept the invite but would like to join in the future maybe. He/she would like to join on the next 6 months/ day / weeks or any other time frame )

It could add some extra work, but I was wondering how to improve the experience of being invited going further than just yes or no to the invitation.

[ajnyga]

I think the scenario where a user rejects but is invited again mostly applies to review requests. The other case where you usually need the invite feature is when you add new editorial members and the invite process there is more a formality: the new editorial member probably already knows she will be invited before receiving a message.

Now that we are not creating a full user account before the user accepts the review request, I do not know if it is a good idea to limit the amount of requests/invitations. Two reason:

1. If a person says no to a request concerning submission A, it does not mean she wants say no to submission B. The decisions the user is making is not about creating an user account. It is a decision whether she wants to review this submission and that can depend on many things.
   (I think already now editors are sending review requests for persons who have rejected before. Probably it is even more common than with this new feature, because with the current code after the first request the system has created an user account and a reviewer role so the user is visible in the reviewers list against her will.)

2. We also have to take multijournal installations into account. If a person says "no" to Journal A, it does not mean she wants to say "no" to Journal B as well.

---

Partly related to this question is what happens after the rejection of a review request. The only data we have stored is the email. Can we keep on showing that in the rejected review request?

If we decide that it is personal data which we can not store without consent, then what do we do with it? Do we only present it as "Review request #24356" and delete the email? And if we do that, how do we prevent the editor from requesting the same reviewer again on that same submission? Or do we maybe delete the email after the review stage is ready? Do the editors have an obligation to store the email for archiving purposes? Or is it enough that they store the names of the reviewers who accepted and did the actual review?

If we decide that we can store the email without consent when the request is declined, then the user might create an user account by herself later. Do we in that case attach the stored review request to the user account that she creates? Remember that the solution described above is based on the idea of creating a "proto user account" that uses the users table but only stores the email when the invite is created.

I am maybe more inclined to delete the email and the "proto account" after the review stage in cases where the reviewer has declined. I think it is enough for archiving purposes to know the amount of requests and the names of the reviewers who accepted and did the review.

[NateWr]

I agree with @ajnyga that the invite is usually related to a task. It should be possible to be invited multiple times. I suspect the case of being invited again and again is not a big problem out in the real world, but if we find that it is, we can consider recording the number of invites a user has declined and providing that info to the editor when they are making the invitation.

I think that we should store the email address for review requests. Without any user interaction, the data is not storing any private information on what the user did in the system. It is just recording input from another user -- the editor. In this sense, it is the private information of the editor, not the reviewer.

Storing the email address allows us to record a meaningful editorial history and display a sensible list of review requests for editors. If and when they become a user, we can recover that information as part of their own record of activity (we show stats on review requests accepted/declined/completed).

based on the idea of creating a "proto user account"

What about repurposing the disabled column in the users table to a status column, with options for enabled, disabled, and invited? That might make it easier to have all queries by default only return users with status=enabled, so coders have to deliberately ask for disabled or invited users.

[mfelczak]

Thanks @mfelczak. Would a ROLE_ID_SITE_ADMIN capability to simply confirm an invitation (similiar to login as) suffice to solve this problem?

@NateWr, we had a discussion about this on the hosting team and it may be more helpful to use the JM role for the manual confirmation. In our hosting environment, and possibly others where the Site Admin role is reserved for staff who maintain the install, Editors and Journal Managers often create accounts for their editorial team when first getting started with OJS and they like to configure their OJS install before inviting these users to start using the system, e.g. setup all Section Editors, assign them to Sections.

[NateWr]

Thanks @mfelczak. In this case, does the editor want to prevent the invitation email from being sent at all, so that section editors aren't alerted to the new journal yet?

I'm trying to think through how we do this in a way that doesn't just lead to rampant GDPR-abuse-by-ignorance. Ideally, the JM would invite, then have a special button where they could confirm an invitation, and that action would have a clear warning like "Are you sure you want to do this? Before confirming an invitation you should be sure that you have permission from this person to create an account for them." or something like that.

But I think that workflow would result in the invitation email getting sent out anyway...

[mfelczak]

Hi @NateWr, it's probably fine if the invitation email goes out as it'll contain each user's login info. As long as JMs are able to add and start using the accounts for journal setup, e.g. to assign to Sections, without needing to wait for each SE's email confirmation, this should be ok.

[ajnyga]

That's only part of the work, I maybe have something for testing in June

[jmvezic]

Great to hear, I'll try to replicate my production database (which has a lot of journals and users) to development server, which should be a great testing ground for the feature.

[kshuttle]

+1 for this issue from a journal manager.

[librariam]

+1 from a multi-journal PKP|PS client

[librariam]

• 1 from a PKP|PS client with a multi-site install

[asmecher]

Note from the CRedIT Helsinki sprint group: When an invitation process is supported for co-authorship, consider the QuickSubmit plugin being used for back-issue entry. Historical submissions will include authors without emails and an invitation process will not be workable; in this case editors should be able to authorship data directly.

Another complicated example: a submission includes a photograph of a sculpture. It may be necessary to credit the sculptor and the photographer.

[luizbgomide]

+1 from a multi-journal admin

[Devika008]

Hello,

I made a user flow that reflects the all the research, discussions and feedback received on this issue over the last few years along with some minor testing with a small user group at the Copenhagen Sprint. A big shout out to @withanage, @ajnyga, @bozana, @asmecher, @jardakotesovec and John for helping me fine tune the work further and make the process more GDPR compliant.

Summary of the requirement

1. In the “Users & Roles” section of the settings, we add a new “Invite user to take a role” action that can be used to invite any user to the journal OJS software based on an email address. The email sent will add the following:

• Invitation request along with details of the role, starting date etc.
• ORCiD verification details
• GDPR compliance

2. Reviewer can be added to OJS in two ways

• Through the review section of the submission: Here the Journal Manager (JM henceforth) / Editor can click on “Add a reviewer” action and will see the following: Reviewers already associated with the Journal and added to OJS and send a review request to them, “Add a new user”- here the JM/Editor can invite a user via email to not only review the submission but also be an OJS user in reviewer capacity- and “Enroll an existing user” - here the JM/Editor can add the reviewer role to a user who already has other OJS roles along with sending an invitation to review the submission.
• Through the “Users & Roles” section: Here the JM/Editor can either add a new user to OJS as a reviewer or add a reviewer role to an existing OJS user. The user will then be shown in the existing reviewer section of “Add a reviewer” on a submission.

3. Multiple hosted Journal OJS Installation: For Multiple Hosted Journals, Editors/ JMs cannot access information of users of one Journal to another. In spite of the journals being hosted on the same OJS instance, the user will have to go through the verification again to protect the information to be GDPR compliant. This is the same method followed by likes of Slack wherein even if the channel is hosted by the same company, the invitation process needs to be followed and accepted by the user. However, I as a user will not have to create a new account, I can use my existing OJS logins and verify and accept the role.

4. Other important considerations

• Even if the user information is publicly available, the JM / editor cannot input the information without consent. This will be translated in the journey in a way where the editors can input the information but they wont be stored in the system. They are shown to the user as suggestions when they accept the invite and the user approves or changes it. Post which the information is stored in the system
• Co-author reauthorization is required even if the user is an existing OJS user

5. ORCiD Pre-requisite

• Starting with 3.5.0, ORCiD Verification would not happen through a plugin. We're rewriting ORCiD support to be integrated into OJS rather than maintaining a plugin. The option to make ORCiD mandatory should be present as part of the 3.5.0 implementation; it shouldn't be necessary to write up a plugin to add the "make ORCiDs mandatory" checkbox.
• If the JM/System Administrator/Editor has marked ORCiD verification as mandatory, then the email invitation sent will highlight that the verification is mandatory. If it’s not enabled then the ORCiD mandatory message on the email will not be shown
• Mandatory or not, when the user is redirected to the ORCiD website to verify they have an option to skip the step. Since we cannot customize the ORCiD verification screen to show skip or not, the email will be the vehicle for communication.

Below are the user flows for inviting users to a role in OJS

A. Landing Page ( Settings > Users & Roles > Users)

B. The JM/editor needs to add a new role to a known user and searches for the user via their username or email ID by clicking on “invite user to take a role

1. 

• If an invitation is sent to an existing user to acquire a new role then the users name will appear in both the tables and not just one table

2. 

How the roles table functions

• Selecting a role from the drop down is compulsory
• The start date auto defaults to “today’s date” with an option for the Journal Manager to set a date in the future as well as past
• End date is not a field the JM can fill. Once the JM clicks on “Remove Role” the end date defaults to that date.
• Journal Masthead --> always auto defaults to appearing in the masthead with options of them not not certain roles which can be managed from the settings
• Once the JM clicks on “Remove Role” then not only the user access is removed but they stop appearing in the masthead as well
• Nothing can be toggled or changed once invitation is accepted by the user

3. 

C. The JM/editor needs to add a new role to a known user and finds the user in the list or searches for the user via their username or email ID.

• the user can choose to skip the ORCID iD Verification

D. The editor needs to add a new user and the user doesn’t have any existing OJS Account

• As you can see here, the editor can input user data limited to their email, given name and family name. Once the user accepts the invite, these inputs will appear as suggestions which the user can leave or change. Once the user accepts and saves information, only then is information stored in the system

E. For Multiple Hosted Journals, Editors/ JMs cannot access information of users of one Journal to another. In spite of the journals being hosted on the same OJS instance, the user will have to go through the verification again to protect their information and fort he process to be GDPR compliant. This is the same method followed by likes of Slack wherein even if the channel is hosted by the same company, the invitation process needs to be followed and accepted by the user. However, I as a user will not have to create a new account, I can use my existing OJS logins and verify and accept the role

As you can see the process is similar upto this point because to the editor its inviting a new user to their journal.

An existing OJS user, has two options here, either to link their existing OJS account or to create a new one using a new email id. Do note that even if the user uses an existing account, no information about the user activity can be shared with other journals in the same installation

[Devika008]

Continuing from the previous comment, here are the workflows for editors inviting reviewers.

As mentioned above the reviewer can be added to OJS in two ways
- Through the review section of the submission: Here the Journal Manager (JM henceforth) / Editor can click on “Add a reviewer” action and will see the following: Reviewers already associated with the Journal and added to OJS and send a review request to them, “Add a new user”- here the JM/Editor can invite a user via email to not only review the submission but also be an OJS user in reviewer capacity- and “Enroll an existing user” - here the JM/Editor can add the reviewer role to a user who already has other OJS roles along with sending an invitation to review the submission.
- Through the “Users & Roles” section: Here the JM/Editor can either add a new user to OJS as a reviewer or add a reviewer role to an existing OJS user. The user will then be shown in the existing reviewer section of “Add a reviewer” on a submission.

Here, I am showing the workflow of editor inviting the reviewer from the reviewer panel in the workflow

A. The reviewer does not have an existing user account. And the JM/Editor want to invite the reviewer through the reviewer panel in the submission

B. Enrol Existing User as a reviewer who is ORCiD Verified

C. Invite existing reviewer (not ORCiD Verified)

1. 

[Devika008]

Hello,

As this issue had too many components and journey's mashed into one, for decreasing the cognitive load on everyone, we all decided to break down the issue into four parts each highlighting an important element. If I have missed anything, please feel free to add them in the issues:

1. Allow Journal Managers to invite users to adopt a role - Editors, Authors, Readers, etc

2. Allow Journal Managers to Invite users to adopt a role - Reviewers

3. Allow Journal Managers to invite users to adopt a role - GDPR

4. Allow Journal Managers to invite users to adopt a role - ORCiD