Admin gets a “You don’t currently have access to that stage of the workflow.” error when unpublishing an article

Software Support
1

Describe the issue or problem

When I admin user tries to unpublish an article, I get a “You don’t currently have access to that stage of the workflow.” error.

Context

  • I’m running a 3.3.0-16 dockerized OJS.
  • I upgraded the site with the following path: 2.4.0 > 3.2.1 > 3.3.0-16.
  • Admin user was assigned with all the possible roles.
  • Modules mod_rewrite or mod_security are disabled.
  • allowed_hosts include all the server’s possible urls and IPs (and base_url refer the main domain).
  • It’s a multilang site (where not all metadata is filled).
  • Articles were probably summited via QuickSubmit with the admin user.

Steps I took leading up to the issue

  1. Login as admin
  2. Go to the article’s publishing tab.
  3. Click on unpublish.
  4. Confirm that you really like to unpublish.
  5. See the “You don’t currently have access to that stage of the workflow.” error message.

What application are you using?
OJS 3.3.0-16 (official)

Additional information

Error is only shown in frontend (no useful info in the server’s logs).
In the frontend console show the following:

XHRPOST
https://foo.org/index.php/journalContext/api/v1/submissions/749/publications/673/unpublish
[HTTP/1.1 403 Forbidden 171ms]

If I visit direclty the URL that fails the JSON returned shows the following error:
error api.404.endpointNotFound
errorMessage The requested URL was not recognized.

In this post a very similar issue was described (in my case it’s Admin can do anything except unpublishing):

In the thread a user suggest the following workaround that works but it’s not a general solution for the issue (admin user should never be blocked):

I solved it by assigning my journal editor user the various jobs to copy edit, in that way it no longer gives this error.

Once I assign admin as a participant (for example) in the production stage, I can go to the Publication tab and unpublish the article.

Additinal tests

During first testing, thinking it could be related with the related with allowed_hosts variable, I tried to add ALL the possible domain names and IPs to this var in my config.inic.php so now it looks like this:

allowed_hosts = '["www.foo.org", "foo.org", "99.99.99.99", "localhost", "127.0.0.1", "192.168.1.1"]'

But it didn’t help at all. :frowning:

The workaround suggests it’s an issue related with the upgrade process and the admin user permissions.
Maybe quicksubmit (not sure if they publish all articles via this plugin) is also related?