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.

@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 😁

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

#9549
pkp/ui-library#303
pkp/ojs#4110

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

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!

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

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:

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

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! :-)