Editing back issue in OJS

We upgraded successfully OJS 3.0.01. to OJS
We have 4 journals there. In one journal we have strange issue:
If we want to edit metadata of back issue it is not possible to do that by entering Submission/Metadata since we have got message that current role is not allowed to enter this stage of workflow although it does have all privileges.
When we unpublish that issue and go to Back Issue/Edit /Submission we receive again the same message.
If we go to Submission/Archive and find Submission we can enter submission but we get message that there is no Submission file and that stages Copuediting and Production were not initiated.
However, when we go to View Site Submission is there and its metadata and pdf file can be normally accessed.

Please advise

Hi. I have the same problem with some articles of some issues, not all. Stage submission does not contain any information, however, the article can be accessed. Any solution?


You are probably in the author workflow with those submissions. What does the url look like?

But I think that @vvucic has a different problem.

Yes. I think so but if I am in the editor o manager workflow I can not access them. I think I have problems with roles in this version 3.1.1-2.


I see something similar if I would like to access articles which I uploaded via the QuickSubmit plugin in our previous OJS2 install.

  • Back then in OJS2 workflow stages were somewhat different (that’s why Production stage is “not initiated”);
  • you were automatically added as author for articles which you uploaded with QuickSubmit.

You can access the editorial workflow via /index.php/[journal_name]/workflow/access/[submission_id] or in you can toggle the author/editor view from the Submissions / Archives page - use the drop-down arrow in the end of the line of the submission.

My issue is the same as @jcabdel described.

Effectively I can access the editorial workflow via /index.php/[journal_name]/workflow/access/[submission_id]. The second way doesn’t work for me.

If the url mentions “authorDashboard”, then you are in the author workflow and can access the editorial workflow like @czirfusz described. After accessing the editorial workflow, you can just remove your stage assignment as an author from the Stage assingment list and add yourself as editor if needed. After that the url’s the system gives you should point to the right place.

I think this is just a problem with older submission. Withe the latest version of OJS you get to choose between the author role and the editor role if you submit as an editor. Choosing the editor role there will let you to access the editorial workflow later.

As a fix / work around for this, all I’m able to come up with is:

  • PersonPerson has used the Quick Submit or Articles and Issues plugin in the past to upload articles. PersonPerson now needs to edit metadata on one of them.
  • PersonPerson makes a new FakeAccount an registers them to the journal with appropriate permissions to edit metadata.
  • PersonPerson uses the FakeAccount to edit the older metadata.
  • PersonPerson uses the FakeAccount to remove PersonPerson as Author, and eventually but not immediately that takes effect (I had to go in as Site Admin and “Clear Data Cache” for it to take effect).

This is clunky. I don’t know that I could write clear concise instructions, and I suspect it’s going to come up often for me, since I’m working with a long running site that is upgrading to OJS 3 and several journals have a long term staff member or library contact who uses the QuickSubmit Plugin to upload all issues.

I’m seeing things in this thread about accessing the article with an author URL and being able to remove oneself, but I’m not seeing how to do that (how to access an article as author), or instructions for a work around.

Could anyone share instructions for a work around to this problem?

@asmecher: It looks like Quicksubmit does not set the stage_id of the article correctly.

We have observed that we can’t add PDFs to older issues if the metadata had been added via Quicksubmit.

Hi @mpbraendle,

Are you still working with OJS 3.1.1-2, or is this a newer version?

Alec Smecher
Public Knowledge Project Team

Hi Alec, we work with However, the issues of this journal already had been added on a OJS 2.4.8 system that was upgraded to 3.1.2

I’m trying to figure out what is going on. For example, I can set the stage_id to 5 in the database for a single article, which allows to add a galley in the production stage, but we can’t set any license information (button “Schedule for Publication” is missing). In which case is this shown?

Hi @mpbraendle,

OJS 3.1.2-4 is quite old, and the QuickSubmit plugin (not to mention OJS) has undergone some changes since then; is upgrading to the latest release an option?

Alec Smecher
Public Knowledge Project Team

Of course it is an option - however we always do extensive tests on our test platform before we upgrade (we have a multijournal installation) - this is planned for August.
The requirement to add the backfiles is however now.

@asmecher: Does that mean that with OJS 3.2.x, the datastructure of the records that had been added before with Quicksubmit for OJS 3.1.2 will be changed, so that one can add later the PDFs? I’m sceptical.

Hi @mpbraendle,

There’s more than 2 years of changes to review between QuickSubmit for OJS 3.1.1 and QuickSubmit for OJS 3.2.1 – but the most relevant is probably the set of changes that introduce support for versioning, which was added in OJS 3.2.0, and changes the way a publication’s status is represented in the database.

If you’d like to try it out before committing to an upgrade, you might try exploring the OJS test drive installation. It’s currently OJS 3.2.0-1, but it should be upgraded to 3.2.1-1 (the current latest release) within a week or so.

Alec Smecher
Public Knowledge Project Team

1 Like

Well @asmecher , if I knew which fields/tables to amend in the OJS database for the articles in question, I would do this operation. Something in the database data is blocking the article so that the PDF can’t be added retrospectively.

OK, I found a solution by updating our OJS database and will post it here.

Identify the ids of the articles that have a problem because of Quicksubmit (for which a PDF can’t be added retrospectively) → list of ids
Identify an id of an article that has been published normally (i.e. is gone through production stage) → normalid

In the OJS database, identify the associated user_group_id for which the article with normalid has been published ==> groupid

select user_group_id from stage_assignments where submission_id={normalid};

For your list of submissions, do the following:

update submissions set stage_id=5 where submission_id in ( comma-separated list of ids);
update stage_assignments set user_group_id={groupid} where submission_id in ( comma-separated list of ids);

After that, the article(s) added with Quicksubmit should be editable in the production stage and galley can be added.

1 Like