Collection on Submission

[ajrbyers]

Editors may want authors to submit articles for a collection so we should:

• [ ] Add a date range to control when a special issue is open for submissions
• [ ] Add a setting to control if the field appears or not
• [ ] List available collections for the author to submit to on the Submissions page via a SubmissionItem
• [ ] Display this in the "View Metadata" popup and unassigned page
• [ ] Allow auto-assignment options for editors/section editors similar to what we do with sections.

[yakky]

@ajrbyers this is a proposal to fulfil the above requirements. We (at sissa medialab) we are already working on something along the lines of what is outlined below and we can take care of the implementation

Changes to support special issues / Collections

The goal of this change is to enrich the basic Issue model in order to implement more flexibility in the submission process in order to create issues with "special" policies / automation which might be useful for some journals, but are at the same time broad and flexible enough to cover a lot of different use cases.

Enabled features

• Allow users to select an issue to submit to during the submission process based on some restrictions defined for each issue (available section / open-close submission dates, people allowed to post article on the issue)
• Automatically assign articles for review to a number of editors
• Provide richer content for such issues, which add more content / context to render them using customised templates

Model changes

Model changes are necessary to store additional information to implement special issues / collection advanced behaviour.

• Update Issue to add:
  • short_name: Name for internal usage, in manager listings etc
  • description = models.TextField: special issue may have requirements for a presentation / introduction to be used in listings or elsewhere
  • open_date = models.DateTimeField: Use to determine when submission to this special issue is allowed or not
  • close_date = models.DateTimeField
  • invitees = models.ManyToManyField(Account) one may want to restrict submission to the special issue to a subset of authors. This many to many can be used to restrict the lists of available special issues in the submission process (if empty all users will be allowed to submit to the issue); restriction only applies to currently logged-in (submitting) author; co-authors will not be subject to such restriction; This is useful for example for conference proceedings
  • allowed_sections = models.ManyToManyField(Section): special issues may have a subset of sections attached, this will restrict selectable sections on submission
  • editors = models.ManyToManyField(Account) used to automate assigned of submitted articles
  • documents (m2m to core.File) to accommodate files needed for administrative or internal uses
  • expected articles: to check if the submitted articles is aligned with expectations and postpone deadline
  • internal notes

Changes to Submission process

• The issue selection must be made an extra step in the submission wizard to allow
  • checking the current date against open / close date
  • checking the current user against the Issue.invitees section
  • If no issue remain after this filtering, the view will redirect to the current submit_info view to proceed with the submission process
  • If at least one issue passes the tests above the user will be presented a form to select the issue and the user selected issue will be assigned as Article.primary_issue
  • this extra step is subject to a submission configuration setting. If disabled, the view will redirect unconditionally to submit_info
• The preliminary step is required because ArticleInfo.section field values depend on the user selection of the issue: instead of providing all the journal sections we may have to filter depending on the sections provided in Issue.allowed_sections. If Issue.allowed_sections is empty, all journal sections will be available for selection.
• In submit_review we can assign editors based on Issue.editors: for ease of configuration, we can implement this by attaching a function to ON_ARTICLE_SUBMITTED event. Behaviour is subject to a global submission configuration ("Enable auto editor assignment") and a per-issue configuration: auto assignment is enabled only if Issue.editors is populated, otherwise auto assignment will be skipped even if submission configuration is enabled

Changes to manager pages

• Add related items in "Submission Configurator"
  • Enable auto editor assignment: enables auto assigning editors based on Issue.editors value
  • Enable issue selection step: allow users to select the issue to submit to; possible values:
    • "All issues": All normal issues and Collections which respect filtering criteria (open / close dates, invitees list) will be made available for selection
    • "Collection only": only Collections which respect filtering criteria (open / close dates, invitees list) will be made available for selection; the empty value will allow the use to proceed by skipping the step (the actual UX for this is still to be defined)
    • "Disabled": the step will be hidden and it will redirect to submit_info
  • Enforce rules for edit metadata manager: one may want to allow editors / section editors to bypass Issue rules / configurations: they can assign articles to special issue on any section (disregarding section preferences) at any moment (disregarding open/close dates)
• Add additional fields to Edit Issue modal in the manager
• Update Edit metadata form accordingly
  • Depending on Enforce rules for edit metadata manager code will:
    • enforce additional fields in Edit metadata: staff editing the article will be subject to the same restrictions as submitting users (eg: they will not be able to change correspondence authors if outside Issue.invitees or they will not be able to select a section outside the ones configured in Issue.sections)
    • ignore restrictions when staff edits the articles to allow for manual override

[joemull]

Hi @yakky and @gamboz, thanks for this. I can see how this feature would allow editors to more carefully curate issues. It seems like it would work well from the author perspective as well, as long as they receive some kind of notification that they have been invited, so they know what email address to use to log in and see the special issue during submission.

In terms of reservations, I am a bit unsure about restricting the Edit Metadata page to users who are in invitees. Our permission system is already a bit stretched, with its current structure, both in terms of maintainability / reasoning and in terms of usability. One of the persistent usability problems we have is that users sometimes do not know whether they have permission to do something, and why that is the case. If they have been told by someone with permission that they should be able to take a certain action on a given page, and then they do not see that option (because they have different permissions), they can get confused and stuck.

So, my vote would be not to restrict the view in this way until we can have a more robust permission system that is composable (maybe via #https://github.com/BirkbeckCTP/janeway/issues/944 or even Django groups) and that is more visible to users (visibility of system status, recognition rather than recall). But if you have other ideas about this or important use cases, happy to consider those.

[ajrbyers]

Hi @yakky and @gamboz, thanks for this. I can see how this feature would allow editors to more carefully curate issues. It seems like it would work well from the author perspective as well, as long as they receive some kind of notification that they have been invited, so they know what email address to use to log in and see the special issue during submission.

In terms of reservations, I am a bit unsure about restricting the Edit Metadata page to users who are in invitees. Our permission system is already a bit stretched, with its current structure, both in terms of maintainability / reasoning and in terms of usability. One of the persistent usability problems we have is that users sometimes do not know whether they have permission to do something, and why that is the case. If they have been told by someone with permission that they should be able to take a certain action on a given page, and then they do not see that option (because they have different permissions), they can get confused and stuck.

So, my vote would be not to restrict the view in this way until we can have a more robust permission system that is composable (maybe via ##944 or even Django groups) and that is more visible to users (visibility of system status, recognition rather than recall). But if you have other ideas about this or important use cases, happy to consider those.

We have had a similar issue (though flipped the other way, with additional sections being shown to editors when they were marked as closed for public submission). Could this be mitigated on the Edit Metadata page through the use of explanitory text?

[yakky]

Thanks @joemull @ajrbyers for your feedback

Restrictions on the editor / staff side is something that we have not analysed in details

Would it be okay for you if we provide a PR with model and submission changes to allow to run some live testing and decide the best path forward for editor side "edit metadata" section.

Changes are mostly independent so I think it's a safe path for action