Add pre-publication checks to enforce publishing standards

[NateWr]

Describe the problem you would like to solve 3.2 introduced a validation step when publishing a submission, which can be used to implement pre-publication checks. These can be used to ensure all required metadata is entered before publishing, or to perform other checks necessary to publish. So far these are not used, but there is an opportunity here to build plugins or encourage our community to build them.

Describe the solution you'd like The hook exists and can be used by generic plugins already. However, during the Pittsburgh sprint, @withanage and I did some brainstorming around this and felt there would be some associated features:

• The ability to enable/disable pre-publication checks for sections (eg - Articles / Reviews may have different metadata requirements).
• The ability to enable/disable pre-publication checks for certain users (OPS may allow/disallow user publishing without oversight).
• The ability to identify particular standards (like DOAJ, Crossref, etc) and build plugins specifically around these requirements.

With that in mind, we thought it would be a good idea to have a central registry of pre-publication checks and the ability to store whether they are enabled/disabled for a particular section. We settled on a plugin category, which might make it easier for people to discover and adopt plugins for the standards they want to keep.

Who is asking for this feature? Those concerned with metadata quality control. For example, the Author Requirements plugin might be more usefully conceived as a pre-publication check -- setting requirements on the metadata before publication, but not necessarily during earlier parts of the workflow, where the data may not be available.

Additional information A fair amount of work was done on this during the Pittsburgh sprint and the results can be found in the sprint document: https://docs.google.com/document/d/1Pa7fF7eRoQ5jJV8qBVqL38AuB9lQ9dSnFlSv9qxhGTw/edit#heading=h.bmm0rowhuh66

I've also put out a call for the community to contribute ideas: https://forum.pkp.sfu.ca/t/what-pre-publication-checks-would-you-like-to-see/59163

[NateWr]

@asmecher I'm curious what you think about the possibility of a new plugin category? Also, the bulk of the work for this was done in Pittsburgh. How would you feel about me adding this into 3.2.1 if we get some solid community feedback that could be worked into one or two plugins?

[asmecher]

@NateWr, could we keep these as generic plugins, at least for now? I'm worried about fragmenting plugins off into very narrow categories. There would probably only be one of these installed and active per installation, so I don't think there's going to be a measurable performance hit by having it loaded on every request (the only real downside to the generic category).

[asmecher]

I think 3.2.1 is a decent target, but do you mean to include/ship them with OJS? I'd rather lean more on the Plugin Gallery and try to decrease the number of plugins that come with the software.

[ajnyga]

Just my two cents that I could not use this plugin category as a basis for OPS screening plugins, because I think it did not consider situations where rules are only applied to certain user groups, in this case just the authors. Also I think there were a couple of other issues there.

But if we are going with a new category, I am happy to port the existing screening plugins to that standard, but the OPS requirements will have to be filled of course.

[NateWr]

@NateWr, could we keep these as generic plugins, at least for now?

Yep!

I think 3.2.1 is a decent target, but do you mean to include/ship them with OJS?

I was thinking 3.2.1 if we needed support for a plugin category, but yeah the checks themselves would just go into the plugin gallery. (Except maybe in cases like OPS where certain checks are a core part of the platform, in which case they should probably just go into PublicationService::validatePublish().)

For 3.2.1, it's really just making sure we have core support for things like enabling/disabling checks for different sections.

it did not consider situations where rules are only applied to certain user groups

Interesting! I hadn't thought of that use-case but it's obviously important to OPS. Presumably you could always get the current user from Application::get()->getRequest()->getUser() to evaluate that in a check, yeah? I've added this to the requirements above.

[ajnyga]

Yes I do that kind of checking here: https://github.com/ajnyga/returningAuthorScreening

I do not recall the details anymore but something prevented me from using the plugin concept you and Dulip had coded last summer and it was somehow connected to the user groups...