Pkp-lib: [OPS] Restricted ability for creating new preprint versions

[alexxxmendonca]

Describe the bug
The way OPS is set currently, an author cannot create a new version for a preprint that's been previously accepted and posted, unless they have permission to publish content altogether (for example, via the "Returning Author" plugin).

Permission to publish content varies according to the server editorial policy and a server may make use of different plugins and criteria to decide who can have the ability to post new contents automatically. However, an author should be able to freely create new versions of their previously accepted and posted preprints, regardless of having the permission to post _other_ contents. This ability should be limited to those preprints of their authorship that have been accepted and posted.

Both things shouldn't be tied necessarily. Not to mention that this seems to create a dependency of the "Returning Author" plugin. What if the server doesn't want to use that plugin? Will the ability to create new versions be strictly restricted to moderators? This seems to be unmanageable for servers with high preprints volume.

Still on this matter, while the authors cannot create and post new versions, they are able to edit the galley and replace the PDF file. This should be blocked. Updating the Galley by the author should be strictly tied to creating a new version.

To Reproduce
Steps to reproduce the behavior:

1. Submit a preprint as an author.
2. Approve and post the preprint as a moderator.
3. Login as the author.
4. Notice that the author cannot create a new version, but can change the PDF file in the Galley.

What application are you using?
Open Preprint Systems 3.2.0.1

Additional information
The ability to create versions of posted preprint is one of the main characteristics of a preprint server.

Taking by example _SciELO Preprints_, we are not at a stage where we can grant authors full permission to post other contents. Between manuscript submission and actual preprint posting, there is a lot of work to make sure the metadata are well filled. Just because they had one approved and posted preprint, doesn't mean that all upcoming submissions shall come in an accepted format, allowing them to be posted automatically.

[ajnyga]

Hi,

I have asked Alec to comment this.

Just to note that this issue was fixed some time ago and is available in the latest official release 3.2.0.3.

Still on this matter, while the authors cannot create and post new versions, they are able to edit the galley and replace the PDF file. This should be blocked. Updating the Galley by the author should be strictly tied to creating a new version.

[alexxxmendonca]

@ajnyga hi!

I see, thanks! We have v3.2.0.3 just now but by the time I opened the issue we didn't. I'll check now!

[asmecher]

Hmm, this is definitely an area where we'll need to explore user expectations, and I'm fairly sure it'll look like screening, i.e. no single policy or even pre-defined set of options will be enough.

I'm 75% sure that we should consider "ability to self-publish" as strongly influencing "ability to add a version", i.e. if a user has the ability to self-publish, they will probably want/expect the ability to add a version. If they don't have that permission, they can always create and publish a new submission (which would be a destructive outcome).

Some potential policies I can think of (just for consideration)...

• Users can create new versions for a time window after publication, or...
• Users can always create new versions so long as they are able to meet screening plugin requirements, or...
• Users are given a tool to prep a new version, but need to request that an administrative user approve it, or...
• Users can always create new versions (this would be good to explore for specific downsides)

[alexxxmendonca]

@asmecher the current scenario implies the use of the Returning Author plugin to allow authors create new versions and from my understanding, that is an optional plugin. The way it's currently set, you cannot allow an author to create new versions of an already approved preprint without by extent giving them privileges to post freely other contents, and those two things are not necessarily tied.

I am personally in favor of these two:

• Users can always create new versions so long as they are able to meet screening plugin requirements, or...
• Users are given a tool to prep a new version, but need to request that an administrative user approve it

Even a combination of both would work.

[alexxxmendonca]

Thanks to a plugin that we've been using, authors are now able to create and publish new versions.

Since then, we've had a few cases in which an author mistakenly created 7 versions (probably because they were not sure if the new version was indeed updated) and one where the author sent two PDFs (instead of replacing the existing PDF):

These kinds of situations make me think that it would be important for the Administrator/Moderator to have clear indication that a new version was created for a preprint.

For instance, right now there is no easy method for me, as an Admin, to find out which preprints had new versions posted. I would have to go preprint by preprint if I wanted to obtain such a list and that is not viable.

[asmecher]

@alexxxmendonca, does the plugin resolve the problem regarding the author's ability to create versions? If so, would it be a good addition to the plugin gallery?

[alexxxmendonca]

@asmecher yes it does.
I think it would be a good addition if we're not considering making this an OPS default behavior.

[asmecher]

@alexxxmendonca, is the plugin available on Github?

[diegoabadan]

Hello, Alec.

We are taking care of the implementation of this plugin. It is in our internal gitlab, but we will put it on github so that you can review it. I'll let you know here.

If they consider it relevant, we can make any necessary adjustments so that this plugin can enter the gallery.

[asmecher]

That would be excellent -- thanks, @diegoabadan!

[diegoabadan]

Hi @asmecher ,

Follow the link for the plugin: https://github.com/lepidus/AuthorVersion

Your feedback will be appreciated. :)

Note: we will add the option of unpublishing and editing relations in the coming days.

[asmecher]

@diegoabadan, https://github.com/lepidus/AuthorVersion/blob/master/VersaoDoAutorPlugin.inc.php doesn't look complete to me... maybe an unpushed commit?

[diegoabadan]

@asmecher ,

I'm going to ask our team to confirm.

I know they were not finding the granularity they needed in the OPS permissions to allow the creation of a version without allowing the submission of a new preprint, so they changed the template as an alternative:
https://github.com/lepidus/AuthorVersion/blob/master/templates/authorDashboard/authorDashboard.tpl

[diegoabadan]

Hi @asmecher ,

The return of our developer Ada:

The file you mention is complete. In the templates folder are the files used to grant permission to the author.
Basically, we need to give the user access to make publications with the 'setAuthorCanPublishVersion' method and we deny by the template his permission to make another type of publication.

[asmecher]

Got it! I just saw an unused variable and was confused. (Filed for clean-up, but it doesn't cause any problems.)

This is nice and simple and would be great to get included in the Plugin Gallery for OPS! See https://docs.pkp.sfu.ca/dev/plugin-guide/en/release for details.

@alexxxmendonca, if that resolves this issue for you, can we close this?

[diegoabadan]

@asmecher ,

We will remove the unused variable and prepare the plugin for the gallery.

Thank you!

[alexxxmendonca]

@asmecher yes, this resolves the issue. I'll be closing the it then.

Thanks!