Copyeditor may download some files and some not - don't understand why

Hi there,

we have an OJS 3.1.1.1 instance with one journal and a problem with file access by the copyeditor role.
There is a submission in stage CopyEditing with a list of draft files.
The copyeditor now may access some files and some not (-> “The current role does not have access to this operation.”)
Making some experiments I found that the accessible files have in submission_files.assoc_id the value 494 and the non accessible have 561. When changing the value in DB to 494 the copyeditor has access.

What is the meaning of the assoc_id?
Why is it different?
How can it be set (using the OJS UI)?

Thanks for any help

Gerhard

Hi @ul2c,

What do you see for the assoc_type for those files (both the accessible ones and the inaccessible ones)?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

the assoc_type is always the same: 520
And as I have seen now there are three different values for the assoc_id:

  • 494 → accessible
  • 533 → not accessible
  • 561 → not accessible

thans for your interest

Regards
Gerhard

Hi @ul2c,

The assoc_type and assoc_id values are a pair – the assoc_type tells you what kind of entity is being referred to, and the assoc_id tells you its ID. The assoc_type of 502 is ASSOC_TYPE_NOTE in PHP-land – so the assoc_id (494, 533, and 561 in your examples) is referring to a note_id in the notes table.

Are these files that are uploaded in the “Discussion” area on the workflow page, or somewhere else?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

the files are in the “Draft Files” list on the workflow page in state “copyediting”.

I now had a look at the notes table and it’s quite funny or crazy.
The accessible files have an assoc_id that does not exist in the notes table.
The non accessible files have an assoc_id that does exist in the notes table.

I would have understood if it was just the opposite but so …

Regards
Gerhard

Hi @asmecher

I am seeing this as well in 3.1.1.4.

Scenario is that an editor has uploaded a “Draft file” and then has assigned a copyeditor. However, the copyeditor does not have a permission to download the file. Like above, the file with the problem has assoc_type 520. In most cases such files seem to have assoc_type null and those files the copyeditor can download without a problem. Not 100% sure how a file with that assoc_type ends up there, since the editor was unsure. But 100% sure that this is a bug.

Hi all,

Hmm, are either of you able to replicate the scenario from scratch? i.e. a repeatable process to cause the error?

Thanks,
Alec Smecher
Public Knowledge Project Team

A new similar case, again with assoc type 520. This time files were uploaded to the discussion and when they were added to the “copyedited files” grid, layout manager could not open them (he has access to copyedit stage).

I will try to reproduce this in a clean install when I have the time.

Hi all,

I have the same problem. File with assoc_type=520 could not be accessed by copyeditor. from the “Copyedited” panel. I downloaded the file (as JM) and uploaded it again than it worked. The file, that did not work, was a file attached to a discussion in the copyediting phase and send by editor to the Copyedited panel.
I have copied below the (slightly edited) database entries for the two files - the one, which could not be downloaded by the copyeditor (id=14035) and the one which could be downloaded by copyeditor (id=14091) . Perhaps this helps.

Best
Armin

+---------+----------+----------------+-----------------+---------------+--------------------+-----------+------------------------------------------------+------------+----------+---------------------+---------------------+----------+----------+--------------------+------------+------------------+------------+

| file_id | revision | source_file_id | source_revision | submission_id | file_type | file_size | original_file_name | file_stage | viewable | date_uploaded | date_modified | assoc_id | genre_id | direct_sales_price | sales_type | uploader_user_id | assoc_type |
±--------±---------±---------------±----------------±--------------±-------------------±----------±-----------------------------------------------±-----------±---------±--------------------±--------------------±---------±---------±-------------------±-----------±-----------------±-----------+
| 14035 | 1 | 14031 | 1 | 2667 | application/msword | 442880 | 1234-Main Article File-13853-1-18-20200127.doc | 9 | 1 | 2020-01-30 01:57:34 | 2020-01-30 01:58:58 | 15305 | 173 | NULL | NULL | 5678 | 520 |
| 14091 | 1 | NULL | NULL | 2667 | application/msword | 442880 | 1234-Main Article File-14035-1-9-20200130.doc | 9 | 0 | 2020-01-31 00:11:17 | 2020-01-31 00:11:17 | NULL | 173 | NULL | NULL | 99 | NULL |
±--------±---------±---------------±----------------±--------------±-------------------±----------±-----------------------------------------------±-----------±---------±--------------------±--------------------±---------±---------±-------------------±-----------±-----------------±-----------+

Hello everybody,

I have also encountered this bug (see here), in two different production stages:
In some cases our typesetter (OJS role “designer”) has no rights to download files in the “Production Ready Files” section. This error occurs when I (OJS role “journal manager”) forward a file from an attached discussion from Copyediting to Production stage. If I download the file in Copyediting stage and then upload it to Production stage, the typesetter is able to download it.

The second time this bug appeared has been in copyediting stage. The editor could not download a file that was attached to a discussion in the “Pre-Review Discussions” and was then forwarded to the copyediting stage.

I checked the “assoc_type” values in the “submission_files” table in our database. The files that could be downloaded have an empty “assoc_type” value (“NULL”). The files that could not be downloaded have an assoc_type of “520”.

So it is obviously exactly the same bug as @aguen described before.

All the best,
MIchael

We are currently in the process of publishing our current issue and the error keeps coming up. Hence my question: Is there any news about how to fix this bug?

Thanks and all the best