Allowing user private editorial notes in OJS

[pilasou]

As an editor of a journal in a multi-journals OJS instance, I want to be able to add editorial notes on a user only available to my journal staff.

OJS only offer one type of note (Editorial notes) that are shared among all journals on the instance.

We improve this feature by adding a new type of notes “Private editorial notes” for notes specific to a journal and note share among others. Exiting Editorial note are renamed “Public editorial notes”, as shown below:

This editorial note appears in the reviewer list when inviting a reviewer (read only) and once a reviewer invited, in the Editorial notes menu (read and edit). The new private editorial note appears the same way.

Both private and public editorial notes can be added in 2 ways:

1. If the user is only in one journal: To add user notes, edit a user, in the window a new text box will be displayed as illustrated below:
2. If the user is in more than one journal: the notes can be edited once a reviewer as been added to a submission.

PRs

https://github.com/pkp/pkp-lib/pull/9549 https://github.com/pkp/ui-library/pull/303 https://github.com/pkp/ojs/pull/4110

How to test?

This test can only be done if the OJS instance has multiple journals on it.

1. Ensure the user on which notes will be used is at least associated to 2 journals.
2. As an editor In journal A: add the reviewer to a submission, then clic on Editorial notes in the reviewer menu. Add both a public and private notes
3. As an editor in journal B: add the same reviewer to a submission. In the add user window, display all information about the reviewer: only the public editorial note add by Editor of journal A is displayed.
4. Clic on Editorial notes in the reviewer menu. Add a private note.
5. As an editor In journal A, add the same reviewer to a new submission, in the add reviewer window, display reviewer details, you should see the private notes of Journal A, not the one from Journal B.

[kristinmhoffmann]

Adding a comment in support of this. We host a multi-journal instance of OJS and several of our journals have reviewers in common. Editors assume that they see information for their journal only.

[jonasraoni]

@nibou230 I see there are commits against a bunch of repositories, once you create all the PRs, please drop a link to them as a comment, then someone will take a look 😁

[nibou230]

Hello @asmecher and @jonasraoni, you can find the PR links below:

https://github.com/pkp/pkp-lib/pull/9549 https://github.com/pkp/ui-library/pull/303 https://github.com/pkp/ojs/pull/4110

[asmecher]

@Devika008, a question for you about this. Currently we have an "Editorial Notes" field associated with each user, which any editor/manager can use to keep notes. The issue is that the field is shared between journals, which can be unexpected.

The proposed feature adds a second field, "Private Editorial Notes", which is specific to the journal. The old "Editorial Notes" field is renamed to "Public Editorial Notes".

I'm not sure "Public" is the right name for the old field -- these are still private to editors -- and uncertain whether adding a second field is the right approach. This might be one of those cases where some installations expect the field to be shared (e.g. small publishers with shared editorial teams between journals) and others don't (commercial service providers sharing an install for several journals). I think there are similar issues that hosting has raise (@pmangahis / @mfelczak) and it might be worth considering them as a group rather than one at a time.

[nibou230]

Hi @asmecher and @Devika008,

I'm not sure "Public" is the right name for the old field -- these are still private to editors

Yes, maybe Shared would be a better term, let me know and I will take a look in january.

and uncertain whether adding a second field is the right approach.

I did go this route to avoid breaking everything else and to let the editors the opportunity to still have a gossip shared accross all contexts, but also a private note restricted to the current context. Maybe it's not required, I will let you figure this out.

Until then, Happy Holidays!

[asmecher]

Happy holidays, @nibou230! We'll hopefully have a bit more guidance here by the time you're back.

[Devika008]

Hello @asmecher @nibou230

I went through the competitive research I had conducted last year and I know alot of other platforms are also doing this i.e. bifurcating who can view the notes. However some do it for submissions and the other for users. Some just have private notes which are only visible tot he person putting it whilst "Notes visible to all" are visible to all participants in the submission. Despite being on the same trail of thought our requirements are very different and I took inspiration from a tool our users use the most to work i.e. google docs. Some users during the interview for submission lists had mentioned they liked the share feature of the google doc. And I agree with Alec that having two separate boxes is not the ideal way forward. It feels like a feature load. Hence taking cue from google doc, I created this rough mock-up. I am not sure the kind of visibility options we want but I think we should keep at most 3 and not load it or make it complicated. This could get a little difficult in coding and will not be straightforward but with respect to scalability in the future its our best bet. Let me know how you feel.

Here's the zoomed in version:

[asmecher]

Thanks, @Devika008. This is more complex than the original proposal, but does have much better clarity on who can view what. The 4 options for "Who can view" are:

• All editors of all journals in this install
• Only editors of this journal
• Visible only to me
• Visible only to participants of submission

While at first glance it might look like we need several new tables to store these combinations, I think we can make it much simpler by using the notes table (implementation in lib/pkp/classes/note and lib/pkp/classes/migration/install/NotesMigration.php). There are several existing uses of this table to add notes to discussions (queries), submission files, and submissions; it can be extended to accommodate this use case as well:

• Add a symbolic column to the notes table, as we will want to distinguish between different uses of data. Add it to the notes_assoc unique index. This will be used for PHP constants that indicate which of the use cases for this table we're talking about.
• On upgrade, when the column is added, update existing values (substituting PHP constants as appropriate):
  • UPDATE notes SET symbolic='query_note' WHERE assoc_type = PKPApplication::ASSOC_TYPE_QUERY
  • UPDATE notes SET symbolic='information_center' WHERE assoc_type = PKPApplication::ASSOC_TYPE_SUBMISSION OR assoc_type = PKPApplication::ASSOC_TYPE_SUBMISSION_FILE
• Now, store these comments in the notes table using the NoteDAO as follows, with symbolic = editorial_notes:
  • All editors of all journals in this install:
  • assoc_type: PKPApplication::getContextAssocType()
  • assoc_id: PKPApplication::CONTEXT_SITE
  • Only editors of this journal:
  • assoc_type: PKPApplication::getContextAssocType()
  • assoc_id: journal ID
  • Visible only to me
  • assoc_type: PKPApplication::ASSOC_TYPE_USER
  • assoc_id: user ID
  • Visible only to participants of submission
  • assoc_type: PKPApplication::ASSOC_TYPE_SUBMISSION
  • assoc_id: submission ID

(If you haven't run into assoc_type / assoc_id combinations in PKP software, it's basically the same as a Laravel polymorphic relationship.)

[nibou230]

Hi @Devika008, @asmecher,

Thanks for the detailled feedbacks and comments on how this feature should be implemented.

Unfortunately I won't have time to get involved in this development in the coming weeks. If I get some free time and no one has taken over, I can look into making the necessary changes.

Have a nice day! :-)