Authors cannot upload submission files

We have moved to a new server and one of our journals is having issues with authors not being able to upload submission files. When trying, we get the message “You are not allowed to add and edit these files”. See attached screenshot. When submitting as a journal editor we are able to upload the submission files.

We are on OJS 3.3.0.17.

We have several other journals running on the same instance and none of them are having the same problem. We cannot see that there are differences in the setup between this journal and the others. The only difference is that this journal has their own domain.

There are no error messages in the server log.

Hi,

I work with this and have tried to debug and follow where this happens, and it looks like it is at this line:

count($stageAssignments[WORKFLOW_STAGE_ID_SUBMISSION]) is 2, and if I implode($stageAssignments[WORKFLOW_STAGE_ID_SUBMISSION]) I get 6553665536, which looks to me like duplicate values.

The other working journals has 1 here.

I don’t know where to debug further, so I would be thankful for any pointers or ideas on where I could go further from here.

Ps, I think we are able to submit as a journal manager since it looks to me like the SubmissionFileStageAccessPolicy.inc.php is skipped/never visited when the journalmanager role is selected. At least I don’t print any debug output from the file, when submitting as a journal manager.

A bit further:

is where the two items are fetched. One item with lots of keys and values, and one with only the value.

Correcting myself on the Ps. statement, SubmissionFileStageAccessPolicy.inc.php handles the case for journal manager earlier in the file.

I think I’ve hunted down the culprit, it looks like we have ghost entries in user_group_stage for some early numbered user_group_ids:

I guess it could be a leftover bug from a previous upgrade? either 2x. → 3 or later.

We are using postgres as database.

select user_group_id , COUNT(DISTINCT context_id) AS context_count from user_group_stage group by user_group_id order by  context_count desc, user_group_id;

user_group_id | context_count
---------------+---------------
             3 |             2
             4 |             2
             5 |             2
             6 |             2
             7 |             2
             8 |             2
             9 |             2
   ...

However when looking in user_groups, there is (correctly?) only one connected context.
from user_groups where user_group_id = 3;

 user_group_id | context_id | role_id | is_default | show_title | permit_self_registration | permit_metadata_edit
---------------+------------+---------+------------+------------+--------------------------+----------------------
             3 |         43 |      16 |          1 |          0 |                        0 |                    1

This didn’t deny an upload for the user group, previously to 3.3.0.14 → 3.3.0.17, but now does.

SELECT * from user_group_stage where user_group_id in (3);
 context_id | user_group_id | stage_id
------------+---------------+----------
         43 |             3 |        1
         43 |             3 |        3
         43 |             3 |        4
         43 |             3 |        5
          1 |             3 |        1
          1 |             3 |        3
          1 |             3 |        4
          1 |             3 |        5

The entries are also present in the database dump prior to the upgrade.

These entries that don’t have a context_id in user_groups, but are present in user_group_stage should be safe to delete? Upload works again after deleting.

E.G given the example output above:

 delete from user_group_stage where user_group_id = 3 and context_id = 1 ;

Just to follow up on this, for reference.

We updated with first checking if the rows that are to be deleted looked sane:

SELECT * FROM user_group_stage AS ugs
WHERE NOT EXISTS (
    SELECT 1
    FROM user_groups AS ug
    WHERE ug.context_id = ugs.context_id AND ug.user_group_id = ugs.user_group_id
) ORDER BY context_id;

and then deleted using

DELETE FROM user_group_stage AS ugs
WHERE NOT EXISTS (
    SELECT 1
    FROM user_groups AS ug
    WHERE ug.context_id = ugs.context_id AND ug.user_group_id = ugs.user_group_id
) ORDER BY context_id;
1 Like