Allow editors and editorial assistants to preview an article before it is published

[NateWr]

Describe the problem you would like to solve
It would be nice if an article could be previewed before it is published. This provides a useful last-stage check to make sure things "look" like they are supposed to.

Describe the solution you'd like
3.2 had a preview button in the workflow, where the View button is now, which would appear before a submission was published. This had to be revoked at the last minute due to some permissions issues (#5563). This should be restored.

[asmecher]

@NateWr Some code for this got removed right before the 3.2.0 release, correct? Could you link to that?

[NateWr]

PRs here: #5563 (comment)

I think there used to be a PublishedSubmissionPolicy or something like that which was removed in the clear out of PublishedSubmission stuff. I think, in order for this to work, we probably just need a policy that checks if a submission is published. If it is, let everyone access. If it's not, apply SubmissionAccessPolicy to see if they have access. But when I took a quick look at that it didn't look so easy, I think because the policy expects to find the ID in the submissionId query parameter, and because of urlPaths the submission ID can be diverse.

[NateWr]

@asmecher here's some work in progress on the article preview access: NateWr/ojs@381a046. Here's an overview of how it works and the challenges in getting this right.

The main challenge is re-using the existing authorization policies to determine when a user should have access to a preview. These policies require query params like ?submissionId=1&stageId=5. So I worked around this by requiring a preview to pass those params in the URL and applying distinct policies (and role assignments) if the params exist: NateWr/ojs@381a046#diff-fb472ff00e77018e59dc4279d1917e96R59-R81

This works in the most basic sense. However, the preview isn't really functional. The user can not click to preview the PDF or other galleys. And in cases where the user may be previewing a second or third version, they don't see a correct list of versions.

[NateWr]

Something to think about for the future: when we start migrating submission files, review assignments and other workflow concerns over to the REST API, we're going to run into a similar mismatch between information in the URL and what the authorization policies require.

Some of the REST API URLs will look like:

• /api/v1/submissions/1/files/2
• /api/v1/submissions/1/discussions/2
• /api/v1/submissions/1/reviewAssignments/2

[majaroenne]

PRs here: #5563 (comment)

I think there used to be a PublishedSubmissionPolicy or something like that which was removed in the clear out of PublishedSubmission stuff. I think, in order for this to work, we probably just need a policy that checks if a submission is published. If it is, let everyone access. If it's not, apply SubmissionAccessPolicy to see if they have access. But when I took a quick look at that it didn't look so easy, I think because the policy expects to find the ID in the submissionId query parameter, and because of urlPaths the submission ID can be diverse.

@asmecher here's some work in progress on the article preview access: NateWr/ojs@381a046. Here's an overview of how it works and the challenges in getting this right.

The main challenge is re-using the existing authorization policies to determine when a user should have access to a preview. These policies require query params like ?submissionId=1&stageId=5. So I worked around this by requiring a preview to pass those params in the URL and applying distinct policies (and role assignments) if the params exist: NateWr/ojs@381a046#diff-fb472ff00e77018e59dc4279d1917e96R59-R81

This works in the most basic sense. However, the preview isn't really functional. The user can not click to preview the PDF or other galleys. And in cases where the user may be previewing a second or third version, they don't see a correct list of versions.

Hi @NateWr
We (The Royal Danish Library) are
very interested in those changes, do you have any plans of when the changes are ready for OJS ?
Regards,
Maja Rønne

[NateWr]

Unfortunately, not at this time. The plan was to have it for 3.3, but that is looking less likely because there are so many things to tackle for that release.

The good news is that there appears to already be a method, IssueAction::allowedPrePublicationAccess, which was used in previous versions to control access to previews. That will be much less complicated than trying to reuse the existing access policies as I was trying to do before.

[majaroenne]

Unfortunately, not at this time. The plan was to have it for 3.3, but that is looking less likely because there are so many things to tackle for that release.

The good news is that there appears to already be a method, IssueAction::allowedPrePublicationAccess, which was used in previous versions to control access to previews. That will be much less complicated than trying to reuse the existing access policies as I was trying to do before.

thank you very much for your answer
Do you mean something like this
pkp/ojs@stable-3_2_1...majaroenne:fix-preview-404 ?

[NateWr]

It might! I can't confirm without looking into it further, but that may do the trick. Have you tested this out to see if it allows/prevents access at the right times?

[majaroenne]

It might! I can't confirm without looking into it further, but that may do the trick. Have you tested this out to see if it allows/prevents access at the right times?

I have tested, but my knowledge about OJS is very poor -
unfortunately -
so I have send the change to test in our ojs-team
who know more about ojs and its functionalities
Thank you for your help

[Vitaliy-1]

Hi all,

Sorry for the late response. Thanks, @majaroenne! I'll take a look at it soon.

[Vitaliy-1]

Yes, it grants access to the article/galley page to users with correspondent roles, tested with a manager and author role. Access is prevented for other users (checked with logged out users and logged in as authors not associated with the submission). The access is granted starting from the submission stage. @NateWr, is the idea to show article preview only on the production stage?

If an article isn't assigned to an issue, the Citation Style Language Plugin throws a fatal error preventing the preview:

PHP Fatal error:  Uncaught Error: Call to a member function getData() on null in /home/doc/OJS/development/e-med/ojs/plugins/generic/citationStyleLanguage/CitationStyleLanguagePlugin.inc.php:327

According to annotation of IssueAction::allowedPrePublicationAccess, it expects Journal object instead of a Context as a first parameter.

Otherwise looks good!

[NateWr]

Thanks @Vitaliy-1! Could you also test with a subeditor and an assistant? These are often the most challenging user permissions to get right.

is the idea to show article preview only on the production stage?

I think it's ok to have the preview earlier. My thinking is that the best thing to do is to add a preview button in the publication tab, for any publication that is not published:

@majaroenne would you be able to open a pull request with your changes so we can do a full code review? Would you be able to add the Preview button in the example above? You'll need to add it to templates/workflow.tpl. If not, just let us know and we can take it from here.

@Vitaliy-1 it looks like CitationStyleLanguagePlugin just needs a conditional around use of the issue. Can you take care of that?

[NateWr]

Yeah that's correct. You will probably want this to be in state, because the status of a publication will change and so the preview button will need to be shown/hidden as that changes.

[Vitaliy-1]

PRs:
OJS master branch: pkp/ojs#2892
Citation Style Language plugin master branch: pkp/citationStyleLanguage#76

[NateWr]

This looks great Vitaliy. I played around with it and there are just two small things left:

1. The preview buttons in the workflow appear even when a submission has not reached the copyediting stage.
2. In the Publication tab, can you put the Preview button so that it appears left of the Schedule for Publication button? This will keep the Schedule for Publication button anchored at the top right of the panel, in the most prominent position.

[NateWr]

All merged, thanks @Vitaliy-1 and @majaroenne! This will go out with 3.2.1-2 and 3.3.

@asmecher the preview feature has been merged to stable-3_2_1.

@amandastevens and @kaitlinnewson this may impact docs for OJS. It adds a "Preview" button to two places in the editorial workflow when a submission has reached the copyediting stage.

[asifdev124]

Is there any solution to create html galley on the fly?
like
https://forum.pkp.sfu.ca/uploads/default/original/3X/f/7/f77095a925c62d4ad1bfaad5d02c994648bd3268.png

[asmecher]

@asifdev124, your last comment appears to be cross-posted on the support forum (https://forum.pkp.sfu.ca/t/ojs-3-2-1-html-galleys-for-article-previews/62443/9) -- that's the best place to discuss this.