Pkp-lib: Authored submission cannot be easily accessed via Editor role

[mfelczak]

There are times when an editor will author a submission and also see it through the editorial workflow, e.g. when publishing an editorial.

At the moment the submission always defaults to the Author view and it's not possible to view it as an Editor without manually altering the URL, e.g. http://somejournal.org/index.php/acronym/workflow/index/15/1

It would be helpful to have a toggle in the UI that would allow Editors to access these submissions via either the Author or Editor role.

[NateWr]

Would this include subeditors or just the editors, journal managers and admins?

[NateWr]

In my tests, admins, journal managers and editors could view the editorial workflow of their own submissions. Did you want this for section editors? Would most journals want their section editors to have this capability?

[carzamora]

hi @NateWr, from my point of view, it's for section editors too!
It is common for section editors to publish from time to time in the same journal, even more than the editor in chief (journal editor role)

[NateWr]

Giving section editors this capability over their own submissions will also mean that a section editor will always be able to see reviewers. It won't be possible for a section editor to make a "normal" submission that goes through blind peer review.

It feels like shaky ground but happy to hear from others on the upside/downside of this.

[mczirfusz]

We also experience this as a burden in a reviewer - editor double role, i.e. if an Editor is also a Reviewer of a submission. Also after completing the review, if clicking on the submission on the My assigned tab, the Review process comes up, and not the Editor view. An Editor cannot access the editor view from the frontend, we have to copy the index.php/[journal_abbrev]/workflow/index/ID_number url to access this page and work further with the submission as an editor.

[mfelczak]

Hi @NateWr, I've followed-up with the editors on this issue and wanted to confirm that the original description was inaccurate: the Editor was assigned as a Reviewer on the submission and could only access the submission as a Reviewer via the submission lists. In order to access it as an Editor, he had to manually type the URL, as per @mczirfusz's comments.

[NateWr]

Ok, let's presume that an Editor has been assigned to perform a Double Blind Review of a submission. Shouldn't they be blocked from viewing the editorial workflow for this submission during the review stage? If not, under what conditions should they be given access to that submission during the review stage, and how will that impact other journals which may expect a Double Blind Reviewer to _not_ have access?

[alexxxmendonca]

Ideally, an Editor shouldn't be able to see the peer review for his own article, to assure neutrality of the review process. So it shouldn't be possible to assign an Editor when he is the author or co-author of a given submission.

Alternatives are:

a) assigning a differing editor;
b) the editor should have a different account with Author-only role for submission purposes.

[mczirfusz]

To make the discussion more structured: we have two issues which perhaps will need a different workflow solution.

_- Author is also the Editor_
I am happy with @alexxxmendonca 's solution and his comments that if we take double blind peer review seriously, an Editor has never ever to be able to access the editor view if being an author of a submission. Workaround a) seems fine. Workaround b) does not make too much sense (if the Editor logs in with the other account they can see the reviewer names anyway), and another issue then is that OJS does not allow to have two accounts with the same e-mail address (but you want to use the same e-mail address with both accounts).

_- Reviewer is also the Editor_
In this case my suggestion would be re @NateWr 's question to be able to access the editor view (as default) _after_ submitting the peer review, but having no access to the editorial workflow _before_ finishing the review.
We have a small journal in which 3 people who oversee all of the submissions have all Editor roles in OJS (in order to have an overview of all submissions at all time), but we also occasionally assign peer reviews for ourselves.
As for larger journals working with several editors I can think of an example that an editor who made a review is also assigned (or assigned later) to oversee this particular submission (e.g. looking at revisions, managing a stage 2 review), but this editor now is only able to access the editorial workflow via the URL and not the UI. Having the editorial workflow view as default _after_ submitting the review would solve this without compromising the double-blindness of the review process.

[NateWr]

Unfortunately, I think we're at a bit of an impasse between this:

There are times when an editor will author a submission and also see it through the editorial workflow, e.g. when publishing an editorial...
the Editor was assigned as a Reviewer on the submission and could only access the submission as a Reviewer via the submission lists. In order to access it as an Editor, he had to manually type the URL

And this:

Ideally, an Editor shouldn't be able to see the peer review for his own article, to assure neutrality of the review process. So it shouldn't be possible to assign an Editor when he is the author or co-author of a given submission.

I think my preference would be to respect the role(s) to which a user has been assigned on the particular submission, regardless of their general role, and to show them what's appropriate for the highest-level role they're assigned on the submission. If they have no role in the submission, we can default to the global role.

This would mean that editors would need to do some gymnastics if they wanted to be authors and editors.

I'm open to other approaches but I'd like to see more clarity on the various use-cases before trying to architect too complex a logic around access.

[alexxxmendonca]

If I may add another layer to this, according to the Council of Science Editors (CSE), in their _CSE’s White Paper on Promoting Integrity in Scientific Journal Publications, 2012 Update_, in the section "2.1.3 Conflicts of Interest", they say:

One challenge for editors is to recognize the potential for biases arising from conflicts of interest in the publishing process and to take appropriate action when biases are likely. Some specific types of conflict of interest are mentioned below.

• _Personal conflicts_. Editors should avoid making decisions on manuscripts that conflict with their own interest, such as those submitted from their department or by research collaborators, co-authors (in the case of collaborators or co-authors, some time period should be established, such as “for the past five years”), competitors, or those addressing an issue in which they stand to gain financially (e.g., stock in a company whose product is discussed in the article). If they may have a perceived or actual conflict of interest, editors should delegate handling of any decision to other editors with decision-making responsibility. Also, editors should submit their own manuscripts to the journal only if full masking of the process can be ensured (e.g., anonymity of the peer reviewers and lack of access to records of their own manuscript). Journals should have a procedure in place to guide the handling of submissions by editors, associate editors, editorial board members, and colleagues/students of any of these to allow for peer review and decision making that avoids any conflict of interest. Editorials and/or opinion pieces are an exception to this rule.

Source: http://www.councilscienceeditors.org/wp-content/uploads/entire_whitepaper.pdf

[mczirfusz]

@NateWr

I think my preference would be to respect the role(s) to which a user has been assigned on the particular submission, regardless of their general role, and to show them what's appropriate for the highest-level role they're assigned on the submission.

That is a good point and perhaps easily configurable in OJS and complies with the CSE guidelines @alexxxmendonca found

[NateWr]

Based on the premise that we respect the role a user is assigned on a submission, I've drawn up the following flowchart outlining the access controls.

This would involve some changes to current behaviour which could disrupt existing workflows. And it doesn't address the original request, except to say that they'll need to manage the participant assignments differently.

@mfelczak and @asmecher do you have any thoughts on this?

[NateWr]

Also, while it's on my mind, here are some of the actual changes that could be made around this access if we go forward:

1. Ensure the access chart is followed. At the moment I think an editor can access the editorial workflow regardless of their assignment (by following the URL).
2. During submission, if an editor is making the submission, maybe we should ask them if they should be assigned as an editor in addition to author. This should clearly indicate that if assigning as an editor, they'll be unable to perform blind peer review.
3. When assigning a reviewer, if that reviewer is also an editor on the submission, clearly indicate that they can not be assigned a blind peer review unless they're removed as an editor.
4. Allow journal editors to "assign self as editor" or some other facility for single-editor journals to recover editorial control over a submission if they've been assigned as an author/reviewer.

[asmecher]

@NateWr, I think the expectation that editors should be able to blind-review submissions is going to continue to dog us unless we address it. This is unfortunately a little convoluted, because we've had somewhat conflicting requests. Here's a thought that might satisfy all requirements, with a few noted caveats, specifically around users who are both editors and reviewers of a submission.

The Simple Option

Because we can't guarantee double-blind reviews when editors are also reviewers, we should flat-out prevent double-blind reviews from being created when the reviewer is also an editor.

(Motivating example: A journal has two editors. Editor A views the incoming submission and sees the author's identity. Editor B later tries to assign editor A as an ostensibly double-blind reviewer, but the system prevents this, as it can't guarantee that Editor A hasn't already seen the submission per their rights as an Editor.)

The Complicated Option

• The system's behavior will depend on the review type ("double-blind" vs. other types).
• For "double-blind" reviews, the reviewer role trumps the editor role, i.e. an editor should not be able to view the submission except within the reviewer interface. (We could consider adding a warning when an editor self-assigns as a reviewer to help prevent accidental lock-out, as often seems to happen inadvertently with test submissions.)
• For all other review types than double-blind, the editor role trumps the reviewer role. There are a few issues filed to help beef up the editor's control over reviews, usually used on the reviewer's behalf if they email the editor but also useful in this case.

This doesn't provide perfect assurances of blind reviews -- I will continue to recommend that editors not be reviewers, just as a matter of scholarly policy -- but it's a common enough case/request that we should probably accept that it'll happen.

[NateWr]

I think your "complicated option" aligns with my approach of respecting the user role assigned to a submission. When an editor is assigned as a reviewer, they'll see the review workflow (regardless of double blind or whatever). When the review stage is complete, they'll regain access to the editorial workflow.

If a journal is assigning editors as reviewers, there's just no way to ensure blind review unless there's a separate assigning editor and all other editors are section editors. We can be clear that this is not a recommended setup when we alert the user that they're assigning an editor as reviewer.

[asmecher]

@NateWr, I think we could possibly achieve this without needing to duplicate logic both in the submission list and in the policies as follows...

• Have the submission lists always bounce to the most "powerful" role available
• Modify the policies to reject editor access when there's an active review
• Use the "advice" capability of the policy framework to bounce to the reviewer interface on the above sort of rejection.

This would mean clicking a link on an Editor's list, when they were also assigned as a reviewer, would bounce them from the editor workflow to the reviewer workflow.

[NateWr]

I like it. Just to clarify, when you say "Have the submission lists always bounce to the most "powerful" role available", you mean the most powerful role _as assigned to that submission_, correct? If no assignment, then use most powerful role in context.

[NateWr]

Oh but I did think of one more thing (sorry). Perhaps these restrictions should be rescinded _after_ the review stage is complete. That way an editor could participate in copyediting/production later in the process.

[alexxxmendonca]

I don't know about that. That would compromise the neutrality and blindness of the process.

[asmecher]

@alexxxmendonca, I don't think we can guarantee blindness. (See "motivating example" in https://github.com/pkp/pkp-lib/issues/3130#issuecomment-356097412.) As long as editors are allowed to view author lists for new submissions -- and I don't think anyone is proposing that -- we can't guarantee they don't already know the author identities by the time the review process starts.

[alexxxmendonca]

Agreed. We can't guarantee that. But we also shouldn't ease that access.

If they do happen to find out one way or another, that's another issue and the system isn't to be responsible for that.

[asmecher]

Oh but I did think of one more thing (sorry). Perhaps these restrictions should be rescinded after the review stage is complete. That way an editor could participate in copyediting/production later in the process.

Yes, I suspect we'll get frustrated reports if we maintain the blindness after the review is done.

I would also suggest that we add two warnings:

• A warning when an editor is assigned as reviewer, basically saying "you're taking review blindness into your own hands" and "this editor will not be able to access the editorial workflow until the review process is complete", and
• Perhaps an additional warning if the editor tries to assign themselves as reviewer, since that'll immediately lock them out of the editorial workflow

[NateWr]

I don't know about that. That would compromise the neutrality and blindness of the process.

@alexxxmendonca Just so I can understand better, which part of the suggested approach was it that you were worried about. Giving access after the review stage is complete?

[alexxxmendonca]

Giving access after the review stage is complete?

@NateWr yes.

[NateWr]

Can you describe in more detail how this would compromise the blindness of the process? My understanding is that once a submission hits copyediting, it's accepted and will be published. So a reviewer will eventually see the identity of the author in the publication.

[alexxxmendonca]

The problem here is the Editor-in-Chief having access to the reviews and reviewers later. Who said what.

But thinking better about all of this, the Editor-in-Chief should really try not to submit their papers to their own journals in the first place, as best as possible. If still they would like to go on that road, the warnings suggested by @asmecher should be helpful enough and opening it up after the peer-review process is over should be fine.

I think we should try to follow CSE's guidelines (https://github.com/pkp/pkp-lib/issues/3130#issuecomment-355546895) as best as possible.

[NateWr]

Oh, right, I was thinking of the Editor+Reviewer combo and forgetting about the Editor+Author combo. Yes, I agree, the only "submissions" an editor should make as an author will be editorials, journal introductions or other non-peer-reviewed material.

I suppose it would be possible to add an additional check after the review stage is complete: if user is assigned as Author, always show a "you can't access this and here's why" message for the review tab. They'd have to stay assigned as an Author, but can also be assigned as an Editor.

[alexxxmendonca]

That sounds good! 👍

[NateWr]

Here's a flowchart including that access check.

[NateWr]

Another report related to a Section Editor having access to details based on their global role when they should be assigned as an Author to the submission: https://forum.pkp.sfu.ca/t/ojs-3-1-authors-can-see-the-activity-log/37183

This one's something that needs to be accounted for in the submission lists. To do this properly, when the REST API returns stage details, it should return a list of the current user's assigned roles.

[ajnyga]

This is looking good! I have to read this with better time in the near future.

[asmecher]

@NateWr, I asked for further clarification on the forum thread regarding Section Editors: https://forum.pkp.sfu.ca/t/ojs-3-1-authors-can-see-the-activity-log/37183/11

[jifarquharson]

I think my preference would be to respect the role(s) to which a user has been assigned on the particular submission, regardless of their general role, and to show them what's appropriate for the highest-level role they're assigned on the submission.

Ideally, an Editor shouldn't be able to see the peer review for his own article, to assure neutrality of the review process. So it shouldn't be possible to assign an Editor when he is the author or co-author of a given submission.

I agree that it would be great to see a solution to this. This issue has recently been raised for our journal. The possibility for authors with editorial privileges to see the identities of reviewers means that the double-blind approach could potentially be circumvented.

[asmecher]

The possibility for authors with editorial privileges to see the identities of reviewers means that the double-blind approach could potentially be circumvented.

@jifarquharson, my current view is that users with full Editor roles will not be guaranteed blindness even with the proposals discussed here. See Motivating Example.

[ajnyga]

@asmecher I think that you are mixing two different cases (also in at the forum yesterday https://forum.pkp.sfu.ca/t/ojs-3-1-authors-can-see-the-activity-log/37183/11)

I think that @jifarquharson is talking about a situation where the editor acts as an author.
I think that you (the motivating example) is talking about a situation where the editor acts as a reviewer.

These are clearly two separate concerns. I think that your case simply can not be resolved. An editor should not be a reviewer. But the other example is something that is something that could be fixed. At the moment section editor role is used to fix that but according to the forum thread above it is not working in 3.1.0.1?

[jifarquharson]

Aye, apologies if I was unclear. The issue arises when:

1. A user has both author and section editor roles in the journal, and
2. That user has submitted an article as an author

S/he--as an author--can now see the activity log, names of reviewers etc., due to their section editor privileges.

[asmecher]

Thanks, @ajnyga and @jifarquharson -- yes, I think it should be possible to ensure blindness when an editor acts as an author.

[NateWr]

@asmecher It's easy enough to hide the activity log button for the SE+Author combo. When a submission's properties return details about each stage, each stage should have a currentUserAssignedAs array which lists their stage assignments. This can be used on the client side to change the display.

I'm having a harder time envisioning how we integrate the per-submission-assignment access checks with the existing operation authorization setup. When assigning a role to a page operation, could there be a way to assign it against a specific object (like a submission), and then use that in PKPRouter::_authorizeInitializeAndCallRequest? Or is this something that would be taken into account in the SubmissionAccessPolicy?

[asmecher]

The closest we have to what you describe is the "capabilities" bitfields we occasionally use. See e.g. SubmissionFileAccessPolicy.inc.php:

// Define the bitfield for submission file access levels
define('SUBMISSION_FILE_ACCESS_READ', 1);
define('SUBMISSION_FILE_ACCESS_MODIFY', 2);

These are used when the policies are added, to tell the policy what level of access is needed.

[NateWr]

PRs:
https://github.com/pkp/pkp-lib/pull/3499
https://github.com/pkp/ui-library/pull/14
https://github.com/pkp/ojs/pull/1881
https://github.com/pkp/omp/pull/515

The PRs above implement a number of changes that address users with dual assignments on a submission. The access chart in this comment should be more or less correct. These changes include:

• When a user is assigned to a submission, their assigned roles take precedence over any other roles they have in the context (ie - journal).
• When a user is not assigned to a submission, managers and site admins are given permissions based on their role in the context.
• The authorized context object, ASSOC_TYPE_ACCESSIBLE_WORKFLOW_STAGES, is now checked specifically against roles that fit the workflow type (editorial or author).
• When a user is assigned as an author on a submission, and also has editorial access, blind review details should be anonymized. (Open review details are still available.)
• When a user is assigned as an author on a submission, and also has editorial access, editorial actions for the review stage are not available, and they can not perform some actions on review assignments (like change due dates, unassign reviewers, or add new reviewers).

These represent some pretty big changes to the authorization code in the workflow. If you've shown an interest in this issue, I'd really appreciate it if you could try to test these changes out with your specific use-cases. We won't get a long testing period before 3.1.1 ships.

Most of this work is under-the-hood but here are a few screenshots of the anonymization and warnings that now appear in the UI.

Anonymized reviewer grid (with a few open reviews) for author+editor assignments:

Anonymized reviewer actions in submission history for author+editor/assistant assignments:

Access to both workflows when a user is dual-assigned:

When assigning reviewers, those who may have had access to author details before are "locked". This can be overridden by clicking a link:

When assigning a stage participant, it will warn if you try to select an existing blind reviewer (and it's still in the review stage).

[jifarquharson]

Hi @NateWr,
I'd certainly be willing to road-test these changes. Thanks for all the effort you've put into this.

[NateWr]

@asmecher and @bozana the tests are not happy, but I'm working on that. Would you want to get started with a code review while I'm sorting that out? PRs in this comment. Hoping to get a really thorough review on this one. :face_with_head_bandage:

[asmecher]

Congrats on getting it this far, @NateWr! @bozana and I will both take a thorough look -- right, @bozana? ;)

[ajnyga]

Hi @NateWr, this is looking very good!

Just a couple of things that come to mind:

Access to both workflows when a user is dual-assigned:

This shows links to author and editorial workflow. But it works also when you are editor and reviewer, right?

With this change I think it is also very important to clearly communicate that it does not solve "editor as author" problem completely which has been raised many times in the forums. The editor can still find ways to check her reviewers if she wants by using "login as" or just by creating a new editor account (creating an account, using that to check the reviewers and then removing the account does not leave a trace). And also this does not check the secondary authors in the submission. Many of the editors using OJS do not understand the difference between "users" and "authors".

I will try to find time to test this, but I am really just so horribly bad with git that I can not make any promises... But when these are merged I will definitely take a closer look while doing the needed changes to the open reviews enhancements.

[NateWr]

This shows links to author and editorial workflow. But it works also when you are editor and reviewer, right?

Good point! Once assigned as a reviewer, they no longer have a link to the editorial workflow. I can think of two ways of addressing this:

1. Provide the dual-link option like the editor+author combo.
2. Force the reviewer link until the submission has entered the copyediting stage. Once in copyediting (or later), show the editorial workflow link.

I'm leaning towards (2), because it goes further in discouraging editors to act as reviewers, which in most cases seems to be a breach of the basic premise of what a review is. That said, I'm open to good arguments for (1).

With this change I think it is also very important to clearly communicate that it does not solve "editor as author" problem completely which has been raised many times in the forums. The editor can still find ways to check her reviewers if she wants by using "login as" or just by creating a new editor account

This is true for ROLE_ID_MANAGER but not for ROLE_ID_SUB_EDITOR. If a sub-editor has never been assigned to the submission in an editorial or assistant role, they should be able to have a fully blind experience.

And also this does not check the secondary authors in the submission.

Correct. I think in the future we may have some kind of association between authors and users, to support browsing by author. It may be easier to resolve that issue then.

I am really just so horribly bad with git

Welcome to the club. :) If you already have the repository checked out, GitHub will actually provide you with instructions on how to merge via the command line. If you follow just Step 1, you can check out the pull request without merging it.

[ajnyga]

Provide the dual-link option like the editor+author combo.
Force the reviewer link until the submission has entered the copyediting stage. Once in copyediting (or later), show the editorial workflow link.

I'm leaning towards (2), because it goes further in discouraging editors to act as reviewers, which in most cases seems to be a breach of the basic premise of what a review is. That said, I'm open to good arguments for (1).

How about a situation where the editor is acting as an open reviewer? I agree that editors should not act as reviewers, but the logic there, I think, is that the editor breaks the blindness of the review. This is not the case with open reviews?

This is true for ROLE_ID_MANAGER but not for ROLE_ID_SUB_EDITOR. If a sub-editor has never been assigned to the submission in an editorial or assistant role, they should be able to have a fully blind experience.

Yes, I do not think the problem applies to sub-editors to begin with and using the sub-editor role is a solution that is in many cases offered also at the forums.

Many journals use only the editor role because it is more flexible for small journals. And you have to have at least one editor in a journal with ROLE_ID_MANAGER to handle the settings, users and most importantly assigning papers to sub-editors (that is why I suggested some time ago that there should be a role between ROLE_ID_MANAGER and ROLE_ID_SUB_EDITOR).

Thanks for the pointers for git, I will see what happens :D

[mczirfusz]

Also an issue which might be able to address in case of _editor-reviewer double role_ [OJS 3.1]:
Assume, I am an editor serving also as a reviewer, and therefore the name of the author is currently not visible for me in the GUI which is good. But if I search for the author name of that anonymised submission, this is still found as a result.
(In most cases it is not a problem, but for example if there are several papers in the queue by the same author / with the same / with a similar name, it might occasionally and inadvertently uncover an author's name through the search function.)

[NateWr]

@mczirfusz We do have a check in place to prevent this with any roles which require assignments (eg - sub-editors and assistants, here). But we don't support ROLE_ID_MANAGER users acting as blind reviewers. It's just not possible to blind the author name in this case, and I think we want to discourage this practice.

ROLE_ID_MANAGER users who are also acting as reviewers can still access the editorial workflow, even though they don't receive a link to do so. That's why we now present a "reviewer is locked" notice for ROLE_ID_MANAGER users when selecting a reviewer, and require the user to manually unlock them.

[NateWr]

@ajnyga How do you feel about this for cases where a reviewer (any review type) has also been assigned a role in the editorial workflow (I also added the "Review submitted" feedback).

In such cases, the user still won't get the full editor experience from the submission list (for example, they won't see overdue notices). But since this is an edge case we want to discourage anyway, I think I'm ok with a degraded experience.

[ajnyga]

Hi @NateWr

I think that the important thing is that users do not end up in a situation where they "loose" the access to the editorial workflow altogether. You see this fairly often at the forum.

Does the limited editor experience mean that after adding herself as a reviewer, the editor looses control over review assignments in that submission?

I would happy even with a solution where you would basically prevent an assigned editor/subeditor from adding herself to the submission as a reviewer. Or that it would be only possible as an open review.

[NateWr]

Sorry for the confusion @ajnyga. The editor will still have full access to the submission workflow. What they won't get is all the additional features that are available directly from the submission list. They won't see the dropdown toggle with additional details straight in the submission list. They'll need to go to the workflow to see those details.

[ajnyga]

Ok, I understand! I think that is a small trade-off. And if I undestood correctly, the editor is warned of breaking blind review if she adds herself as a reviewer.

[markagregory]

Please forgive me if this is a FAQ. I have just added the copyeditor role to one of the team and he can copyedit only two papers out of four that are in copyedit now. For the other two papers he gets the message "You don't currently have access to that stage of the workflow."

Is the only solution now to create a new account for the copyeditor with the copyedit role?

[NateWr]

Hi @markagregory, we use this GitHub repository for discussion about the development of the software's code. The PKP forum is a better place for questions about how to use it. I've moved your question over there and provided an answer:

https://forum.pkp.sfu.ca/t/copyeditor-cant-access-all-submissions-in-the-copyediting-stage/40146

[NateWr]

:tada: Merged!

There's still one outstanding issue but I thought it best to merge so translators can get to work.

I'll tackle that last issue now.

[asmecher]

:tada: :tada: :tada:!

[ajnyga]

Hi @NateWr
I noticed that the Editoria notes / gossip action is only visible for open review requests at the moment because of this condition (isAuthorBlind): https://github.com/pkp/pkp-lib/blob/master/controllers/grid/users/reviewer/ReviewerGridRow.inc.php#L148

Although the variable name suggest that it checks something about the author, it actually just checks the review method for the current row: https://github.com/pkp/pkp-lib/blob/master/controllers/grid/users/reviewer/ReviewerGridRow.inc.php#L52

I could not figure out why the blind reviews would not have that option available? Maybe that is a mistake or I am just missing something?

[NateWr]

Hi @ajnyga, I haven't yet confirmed the issue, but I think you're right. The conditional check there should _probably_ be:

$canCurrentUserGossip && !($this->_isCurrentUserAssignedAuthor && $isAuthorBlind)

[ajnyga]

Hi,

The $isAuthorBlind variable basically checks if the current review assignment row is a blind review assignment, right? (a better name would perhaps be $isReviewBlind?)

What I do not understand here is why would the Editorial notes action be depended at all on the review method? I mean even if this is trying to hide the editorial notes from an editor who is also the author of the submission, I think that you would want to hide the editorial notes for both open and blind review assignments?

So I believe that the whole $isAuthorBlind should be removed altogether? But as I said, maybe I am not just getting the logic here.

[NateWr]

Editorial notes are attached to users, not review assignments. However, my thinking is that editorial notes are likely to contain information that could disclose identity. For example, we may eventually allow an editor to search for users by editorial notes. In such a case, an editor/author who can access the editorial notes of a blind reviewer could determine the reviewer's identity.

That's the only reason I hide the editorial notes when the user is an author. The additional check on the review type was to make this available for open reviews, since the author will already know the identity of the reviewer.

You could argue that it's easier to just hide the editorial notes whenever the user is an author. But I just know eventually someone is going to ask for it to be visible for some reason. So I thought I'd just stick to limiting it in cases where concealing the reviewer's identity is important.

[ajnyga]

Hi,

Yes hiding the editorial notes from the editor/author combo is understandable and yes, you are probably right that it is best to hide only the necessary things from the editor and editorial notes on open reviews is probably not among those. There is of course the possibility that the other editor dealing with the review stage writes something there regarding the selection of the reviewer that should not be seen by the author/editor. But as you said, the notes are reviewer specific so the author/editor is bound to see the notes anyway. But it might be a good idea to clearly state that notes are about the reviewer and not only the current assignment.

So yes, I was just not getting the logic here :D

(But the _current code_ does have the small bug that you already proposed a fix for above. With the current code the editor (who is not the author) will only see the editorial notes for open reviews)

[NateWr]

:+1: can you raise a PR for that? :)

[ajnyga]

sure! Probably later today.

[ajnyga]

pr to fix the display: https://github.com/pkp/pkp-lib/pull/3564

The label for the editorial notes field now only states that "Notes entered here will only be visible to administrators, journal managers, editors, and subeditors". But as you said above these are notes that are saved for the reviewing user, not just the current review assignment at hand. So it would probably be a good idea to state that on the label text.

[NateWr]

The label for the editorial notes field now only states that "Notes entered here will only be visible to administrators, journal managers, editors, and subeditors". But as you said above these are notes that are saved for the reviewing user, not just the current review assignment at hand. So it would probably be a good idea to state that on the label text.

How about this?

Record notes about this reviewer that you would like to make visible to other administrators, journal managers, editors, and subeditors. Notes will be visible for future review assignments.

(Can you roll this into your PR?)

[ajnyga]

Hi @NateWr
Changed the translation and the remaining isAuthorBlind variables. Do you have a some way of notifying other translators about these kind of changes? Maybe there should be a translator mailing list or similar?

[NateWr]

I believe all of our regular translators receive an email before a release. Marco might be overwhelmed if he had to manage translations for every change.

[ajnyga]

Sure, I was just thinking that cases like these where there is no totally new translation (no new or removed key), the change could go unnoticed.

[asmecher]

On locale keys that change meaning: if a re-translation is needed, I'll typically delete the old translation from all the locale files I can't provide good translations for. That forces the translator to retranslate and could result in a missing locale key if they don't get to it, but that's better than keeping an incorrect translation around.

[ajnyga]

One more thing @NateWr
How does the GDPR demand "People have the right to access any information a company holds on them, and the right to know why that data is being processed, how long it's stored for, and who gets to see it." work with the reviewer ratings and the gossip field?

[NateWr]

That's a good question and I don't know what the implications are for what is effectively internal communication. Am I, for example, permitted to request a copy of any email that my builders may have sent to each other about me? Or do they have a right of privacy for internal communications? I don't know...

[ajnyga]

I guess it comes down to the question whether gdpr applies only to the data that has been collected from the users. This would of course mean that the gossip field, being data that has been created by someone else than the user herself, is not subject of the "right to know" clause.

But definition of personal data just says that"‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number" https://gdpr-info.eu/art-4-gdpr/

Also here https://edps.europa.eu/node/3110#personal_data%C2%A0 it is mentioned that "Other examples of personal data can be found in information on physical disabilities, in medical records and in an employee's evaluation.".

[NateWr]

I wouldn't trust myself to interpret law, but tagging @jmacgreg because he's working through the GDPR stuff now.

[jmacgreg]

I'll include this question in the GDPR policy document draft (to be sent out relatively widely on Friday, @ajnyga you'll receive access to this) for review. The question concerns stuff like reviewer comments, editorial history, etc. I don't have an answer at this time, and will appreciate a larger community perspective here.

[ajnyga]

Sounds good! After reading about GDPR for the past few weeks and talking with some library folks, I am not sure if anyone has all the answers. The clauses are just leave so much for interpretation.

[ajnyga]

A small related issue.

If an editor sends in her own submission as an author, she will still get the "New submission needs an editor to be assigned" notification that contains a link to the editorial workflow of that submission. If the editor clicks that link, she will get an error because she can only access the author workflow.

For a smoother experience the editor, acting as an author in this case, should not receive the notification.

[edit: moved to https://github.com/pkp/pkp-lib/issues/5835]