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

[Devika008]

Hello,

Since https://github.com/pkp/pkp-lib/issues/3022#top was too big, upon discussion we decided to divide it into four smaller issues.

This third issue focuses on making the user invitation process GDPR compliant with respect to which pieces of user information can be stored on the platform, which can be entered or seen by the editor/journal manager/system administrators, or which can be entered or seen by the user. The work here reflects all the research, discussions and feedback received over the last few years along with brainstorming with our editorial group at the Copenhagen Sprint.

Summary of the requirement

1. The editor can enter user email id but can only suggest the Given Name, Last Name and affiliation. The editor cannot set the password or enter information which is stored in the system anymore
2. Once the user receives the invite the user can not only validate the information entered by the editor but can also change the information and add more details about themselves. Only the information entered by the user is regarded as the point of truth in OJS going forward

Here is a link to the table showing what information can be seen, modified or entered and by whom: https://docs.google.com/spreadsheets/d/1geSRG1MsGYPvkOISXn1rwf-izZf5v67GxUSgXNweuRI/edit?usp=sharing

@withanage please enter any information you think I might have forgotten

[marcbria]

Hi Devika,

All looks great to me, except for two details:

Right now, Editor CAN'T edit (on behalf of the User) fields "First Name, Last name and Preferred Public Name". If this could only be done by "admin" users this could be an important bottleneck. It's not clear to me if Journal Managers will be able to edit, but I think they need to be.

And I don't see any problem in making this editable also by Editors. What GDPR tells us to restrict data as much as possible but we can justify this as a requirement of our soft.

And same apply with "Editors able to see user's last login".

In some scenarios Editors are also doing user managment and preventing them of doing this task will derivate in role scalation (Editors will ask to be JM) and "will be worst the remedy than the illness". :-)

So, the questions are:

• Do you mind to confirm that JM will be able to edit?
• What prevents us from allowing Editors edit names and see last login if, in the end, in some scenarios are the ones who perform these tasks?

[ajnyga]

I think we need a clear matrix/datasheet that will show different permission different roles have around the system. This could be part of the user documentation.

[marcbria]

Full agree AJ. It's great to slice the problem in parts but then, it's kind of difficult to get the whole picture.

A matrix like the one you mention would help with this. I started a first draft, taking in consideration that some features/permissions could work differently in single and multi-tenant installations. Not sure if what I say there is write, so an overview is really apreciated.

https://docs.google.com/document/d/1DU4UrnWKEmLgbeVLNMgdhHl1igk3AzD4MMq9e8ee0GQ/edit?usp=sharing

It's under CC0 :-P so feel free to use / reuse or just ignore it. ;-)

[Devika008]

Hello @marcbria and @ajnyga

Firstly, thank you for bringing up your concerns and highlighting a common doubt. There's already a matrix that @withanage and I created during the Copenhagen Sprint, incorporating user testing feedback and input from multiple editors and journal managers. The matrix, which details the information that can be viewed, modified, or entered by whom, is referenced in the issue. I propose that we consolidate our modifications and suggestions into a single document to avoid confusion and streamline our documentation process.

https://docs.google.com/spreadsheets/d/1geSRG1MsGYPvkOISXn1rwf-izZf5v67GxUSgXNweuRI/edit?usp=sharing

Regarding the issue raised by @marcbria about requiring Journal Managers/Editors/Admins to enter user information such as Family Name, Given Name, and Preferred Public Name:

1. Larger portals/installations already lack permissions to frequently edit accounts, so this change doesn't introduce a loss of functionality or major disruption.
2. Through multiple user tests conducted during the previous sprints and consultations with editors, the proposed change was positively received. Editors appreciated the ability to suggest information input and felt relieved from the responsibility. Authors and reviewers also valued the autonomy to accept or modify suggestions during the workflow.
3. This change aligns with our commitment to empowering users by giving them control over their data, even for seemingly small details like their name.
4. While there was an edge case where a user was not tech-savvy and preferred the editor to fill in their information, the modified process of editors suggesting information and users accepting it upon account creation proved effective in addressing this concern.

I'm open to discussing further and addressing any use cases supporting the proposed change. I'm available for a call to delve deeper into this matter and find a collaborative solution.

[marcbria]

Hello @Devika008

Yes, I am aware of the table linked at the beginning of this thread as I have participated in it for a few months, but although the table is and has been useful for data vs actions-in-roles, it does not allow us to systematically visualize all actions vs roles related, nor does it allow us to be clear about the differentiated operation in single-multi tenancy.

The second table (complementary to the first one) is inspired by the Drupal permission system (a successful model for decades), try to answers AJ's request when he suggests that "I think we need a clear matrix/datasheet that will show different permission different roles have around the system" to which I agree 100%.

I also share with AJ that it would be good to add this information to the final documentation, so if the proposal I make is not convincing, is there any alternative to cover the 4 axes that I mentioned (action, role, data and tenancy)?

Anyway, even if we don't like to use this second table for documentation, transposing it could be a good exercice to reflect about what we are doing, don't you think?

Related with all this, this comment made me think...

Larger portals/installations already lack permissions to frequently edit accounts, so this change doesn't introduce a loss of functionality or major disruption.

Although large facilities are the ones that have the most say, I don't think it is a good idea to ignore that the vast majority of our facilities are small (beacon data indicates this, but a non-negligible number of large facilities that have chosen by the single-tenant model) so it is important to make the differences (if there are any) explicit.

Regarding your answer, I understand the arguments but please, to clarify... but as the initial table don't cover all the roles, it's still not clear to me. Could you confirm the answer to this question with a Yes/No (or check the new table to see if I set it right)?

• Will JM be able to edit name, surname and mail?
• During the redesign of the permissions, has the possibility of implementing "admin0" been considered as other CMS do?

Finally, although you argue about the reflection process (which I thank you for as it clarifies some doubts for me), I am not clear about the conclusions that lead to limiting the possibility of Editors editing the names and surnames (never the username) of users or seeing the last login when in some scenarios it is a real functionality and limiting JM or admin will result in escalation of privileges.

If the answer is GDPR, let me advance that the law don't prevent us to do this, only demands us to be clear about who is reaching each data. If we think it's something necessary, and we explain it in the Privacy Note, we are safe.

Thank you for your time and work Devika.

[Devika008]

Hello @marcbria

Firstly thank you so much for constantly pushing us to innovate and think on situations from multiple perspectives.

The second table (complementary to the first one) is inspired by the Drupal permission system (a successful model for decades), try to answers AJ's request when he suggests that "I think we need a clear matrix/datasheet that will show different permission different roles have around the system" to which I agree 100%.

What I will do is, that I will make this table as the primary point of contact and delete the first one which is linked on the thread. My point was that we need one point of truth and having multiple could be confusing. So Ill use this table designed so thoughtfully by you as the source of truth. I hope that works with everyone.

Although large facilities are the ones that have the most say, I don't think it is a good idea to ignore that the vast majority of our facilities are small (beacon data indicates this, but a non-negligible number of large facilities that have chosen by the single-tenant model) so it is important to make the differences (if there are any) explicit.

I apologize if what I wrote made it sound that we were considering or preferring the findings from one group of users. What I meant to say is that since it was working so easily it could be used to as a pathway for change for all our users whether small or big. This was the assumption we worked with when we started and I personally tested smaller journals throughout the Copenhagen Sprint along with all the conversations I was having with independant smaller journals throughout the year. I received a great number of thumbs up for this process. Some editors felt the need to input user data but also realised the importance of users having ownership on their own data and gave kudos to the mechanism of them entering the user given name and family name as suggestions and users being able to approve it. Some editors also pointed out that this new mechanism actually help eliminate any malpractices happening or incorrect data being admitted into the system

Will JM be able to edit name, surname and mail?

The JM will not be able to SUGGEST and INPUT the user mail id, name and surname at the time of sending an invitation. Once the user accepts the invitation and accepts the suggestion or modifies it, the editor will not be able to edit the name, surname and mail of the users.

During the redesign of the permissions, has the possibility of implementing "admin0" been considered as other CMS do?

Yes it has. The admin can edit every user information barring the username and the password.

Finally, although you argue about the reflection process (which I thank you for as it clarifies some doubts for me), I am not clear about the conclusions that lead to limiting the possibility of Editors editing the names and surnames (never the username) of users or seeing the last login when in some scenarios it is a real functionality and limiting JM or admin will result in escalation of privileges. If the answer is GDPR, let me advance that the law don't prevent us to do this, only demands us to be clear about who is reaching each data. If we think it's something necessary, and we explain it in the Privacy Note, we are safe.

What I meant is that it would really help me and everyone else if you mentioned scenarios in which editor editing the user name, family name and preferred name would be beneficial. The answer to these changes is not only GDPR (because I am aware that there's a way out of this) the answer to this is the onus which editors did not want about putting in user data, the onus they wanted to give to the user to be in control of their data. It is also to reduce malpractices which many smaller journals are facing because of this in south-east asian and MENA region journals.

I would open the floor again to this topic to put in your thoughts @ajnyga @asmecher @bozana @withanage

[jonasraoni]

An extended permission system (not based solely on roles) would make things easier. We could have a default "Manager cannot edit XYZ", and whoever doesn't like it, can just go and modify (although bug reports will become more complex 😅).

[withanage]

Hi @Devika008 , I got the response last week from our GDPR officer for your question in the last week and I think we are good with our plans.

She wenn through the #9660 and gave a general response , I think will help us for the next two issue too.

Here is an english translation of what she said.

I agree with the excel table. When inviting reviewers, it should not be possible to fill in any further data; 
the person concerned must do this themselves. 
The email address must be deleted after a certain period of time if the user does not register themselves.

Furthermore,   of course cases are conceivable in which the JM or editor fills in information
 in the user's profile because the user is unable or unwilling to do so themselves.
However, this must be covered by prior consent. This consent can be contained in the terms of use; 
a reference in the privacy policy is not sufficient.

FYI @asmecher @marcbria @ajnyga

[marcbria]

Sorry for the long silence, @Devika008 I completely forgot that you had asked me for a use case for "Editors wishing to edit names and surnames".

The cases that come to mind are (in order of relevance):

1. Digital skills: Incredible as it may seem there are still users who have few digital skills (due to age or professional profiles) and send mails but are not able to change their own profile.
2. Mail issues: If I have not lost the thread, the whole workflow involves mails that (as MTAs are working lately) are becoming an increasingly unreliable tool (they go to spam, sending limits are exceeded...). It would be desirable for the editor to be able to modify this data "on behalf of".
3. Data curation: If the Editor (who is the ultimate authority over the content of the journal) detects an error in a user's personal data, he/she should be able to change it. If he/she has to start a workflow to do so, laziness may outweigh the need and the data may remain unchanged.
4. Relieve the burden on reviewers: One of the most necessary and "spoilt" roles in journals are the reviewers. Minimising the tasks they are asked to perform is something that some editors want.

On the other hand, being able to see the "last login" does not seem so pressing to me, but it does offer two advantages:

1. Feedback on the user's activity on the platform.
2. Security mechanism if the user reports that they "did not log in since XXX".

@withanage about the feedback from your GDPR officer, full agree in every point and happy she raised this one:

The email address must be deleted after a certain period of time if the user does not register themselves.

See you tomorrow, m.

[ajnyga]

My concern with erasing the email when that is the only piece of information about the reviewer is that the journals loose editorial history which they might want to preserve. In any case this can not happen too fast to ensure that the editor know who has been invited and who not.

[marcbria]

Never thought about this and you are right. Aproposal to be pulished:

• Create a "last notification" date field visible to Editors and Admins.
• Allow Editors&Admins "send a reminder" with a single click.
• Create a "vacum" process that will remove mails not confirmed during the "temporary period".
• I suggest "Temporary period" (ie: 6 months?) to be a constant in the system so it's easy to remember/understand). It can also be a config variable so each admin decide for each context.
• Once the email is removed, the "last notification" will be shown in red (or in a way that makes clear "something happens").
• Thinking if would be a good idea to let the "vacum process" (or as an option for admins) full remove temporary users non confirmed during certain time.