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

[Devika008]

Hello,

Since Allow journal managers to invite users to adopt a role was too big, upon discussion we decided to divide it into four smaller issues, the first one being this.

This issue highlights only the user flow of journal managers inviting users like editors, authors, readers, etc to OJS. The user flow reflects 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.

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. 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.

3. 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

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

A. Landing Page ( Settings > Users & Roles > Users)
I have tweaked the interface to make it more accessible, instead of the arrows at the start of each row, I have added a "more options" icon at the end. I have shown three states of it below.

1. 

2. 

3. 

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. 

4. 

5. 

6. 

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.

1. 

2. 

3. 

4. 

5. 

6. 

If the user goes ahead with the ORCID Verification

7. 

8. 

Incase the user decides to skip ORCID verification, the following screen will come

9. 

10. 

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

1. 

2. 

3. 

4. 

5. 

6.a

Incase the username already exists, the following indication/error message will appear

6.b.

7. 

8. 

9. 

10. 

11. 

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

1. 

2. 

3. 

4. 

5. 

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

6. 

7. 

8. 

9. 

10. 

[withanage]

@Devika008

hi Devika,

We talked about the validation errors in the forms today!

The general technical idea behind this is that we have the REST API endpoint that gives us a list of errors, and the forms in a specific step select from a custom list of fields that they need to display.

I have gone through the designs and we seem to have one way of displaying errors or information, when the step has failed.

Would you be suggesting a similar display for validation errors or may be form-field level validation errors for those specific errors, such es entered email format is not correct?

FYI @jardakotesovec @ipula

[Devika008]

Hello Dulip,

I'll share the designs for validation errors with you and Ipula shortly. My basic logic is to provide inline error validation and not when the user clicks "Next" or comes on the "review screen"

Are there a list of specific errors you are looking at? If yes, then it will be easy for me to provide the designs keeping those specific errors in mind.

[withanage]

Thanks Devika,

Are there a list of specific errors you are looking at? If yes, then it will be easy for me to provide the designs keeping those specific errors in mind.

yes, I was meaning the inline errors as you anticipated. Actually, the set of errors, I was looking at was the non-occurance of an input text or the validation according to a certail rule . A message e.g. for missing email and the sytnax validation would be an example.

I tested the ui-library for some of the developments from Jarda and Ipula today and saw some of the validation error messages are still available there. May be they are from the old code still.

[jardakotesovec]

@Devika008 I would like to specifically check with you, whether the fields in table (like selecting start date for role) would also show it inline the same way as any other form fields?

[Devika008]

It would be great if the errors on the table were inline so to replicate the behaviour elsewhere on the system and ease the cognitive load and learning graph of the user however I leave it to you if you think it would be difficult in the table then we can discuss

[mreiko]

@Devika008 @jardakotesovec Can this ticket plus #3022 now be closed given that #9660 and #9661 are in progress?