Missing Galley Links in some Issues

Software Support
1

Greetings,

We recently updated to Ojs 3.1.0 and detected that one of our journals have a problem with some issues. Some of them are not showing the galley links (PDF/HTML) in the issue view page (/index.php/journal/issue/view/XXX). The articles are shown in order but the links are missing. If I access to the article view the links are also missing.

Also, in other journal the issue view is not showing the links, but if I access to the article view It is showing the link there.

I checked the issue details and galley files from the control panel for this issues and articles and everything seems to be Ok. From the control panel thereā€™s the production galley and the file is downloading Ok. Is not happening with all the issues so Iā€™m not sure what can be the problem. Iā€™m also checking the error logs but is not showing any problem.

I appreciate any insight you can give to me.

Thanks in advance

2

Greetings,

I think we found the root problem but need some insight to know how to solve it (probably the field and table to be updated).

Messing around a little bit, we identify that a custom component in Control Panel > WorkFlow ā†’ Article Component might be related because it follows the behaviour we are having. You can reproduce this behaviour following the next steps:
Option 1:

  1. Create a custom component in Control Panel > WorkFlow ā†’ Article Components
  2. Create/assign a galley file to the new component
  3. Check the issue/article view page and check that the link is there (it is)
  4. Delete the new custom component from Control Panel > WorkFlow ā†’ Article Components (No warnings for related articles)
  5. Check the issue/article view page and check that the link is there (it is not)
  6. Create the custom component again
  7. Check the issue/article view page and check that the link is there (it is not. Probably because the new component is assigned with a new id)

Option 2:

  1. Create/assign a galley file to the a default component
  2. Check the issue/article view page and check that the link is there (it is)
  3. Delete the default component from Control Panel > WorkFlow ā†’ Article Components (No warnings for related articles)
  4. Check the issue/article view page and check that the link is there (it is not)
  5. Restore default components
  6. Check the issue/article view page and check that the link is there (it is there. Probably because the default component is assigned with the same id)

The second option for us, identify another issue. I canā€™t restore the default components for one of the two journals. Probably because is an old journal with custom components that are using the same id of one of the default components, and when it tries to restore them it clash with the id of the custom and canā€™t do the job.

Can you please try to reproduce the problem to confirm the issue? If is true, can you point me out which table is related to the Journal Article Components, and which table has the relation [galley id] <-> [article component id]? Knowing this, I can update the relation to an existing journal component and solve the problem.

If this is the problem, it would be nice to put a warning/restriction if somebody tries to follow this steps (sometimes, the journal managers are too creative).

Thanks in advance

3

Hi @hekutoru2kx,

This is the genres table (referred to from the genre_id in the submission_files table).

I agree that there should be a warning about deleting active components/genres ā€“ Iā€™ve filed this for attention at Prevent deletion of active genres/components Ā· Issue #3899 Ā· pkp/pkp-lib Ā· GitHub.

Regards,
Alec Smecher
Public Knowledge Project Team

4

Hi @asmecher,

After updating the missing genres_id to defaults one, the link shows up but the file is not being loaded. The error is not giving enough information so I follow some tips from other post to show more:
I edited
lib/pkp/controllers/grid/notifications/NotificationsGridCellProvider.inc.php and find line 150
after the line
assert(is_a($submission, ā€˜Submissionā€™));
and added
error_log('Assoc type: ā€™ . $notification->getAssocType() . ā€™ Assoc ID: ā€™ . $notification->getAssocId());

The new error points out that the file of the submission is not found. Checking the reason is because the filename is composed by submission_id-genre_id-etc or something like that. So changing the database is not enough because the filename has to be changed also. This means that Iā€™m facing a new problem right now with the filename.

This journal was originated from a really old version and Iā€™m checking that some submissions are associated to genres_id that is duplicated with one from a different journal (context). I had some issues fully associated with this and reassigned in the database to the default generated genre_id and deleted the ā€œduplicatedā€ workflow section (genre), but now with the file match problem I tryed to reassign but due to table primary key restriction I canā€™t.

Is there some procedure/routine to identify this missing association and rename massively the filenames? let me know, and thanks again. Iā€™m renaming for now the last issues, but still need to check and update the older missing ones.

Thank you

5

I solved the problem but still had to do a heavy job to guarantee that nothing was missing. For those who may have this issue follow this steps for each journal:

  1. Identify the existing genres ids in the databse

  2. Identify the used genres in the submission files in the database

  3. Create the new genre(s) in the database and modify the id of the new genre to match the id of the missing genre(s) of the submission files in step 2
    Additional Steps if step 3 doesnā€™t work because a different genre already exists with the same id

  4. Update the genre_id in the submission files table from the missing genre(s) to the new genre(s) created

  5. Do a massive filename update of the files that match the filename structure with the genre (learn the filename structure that ojs use)
    Example (Old Genre Id: 37, New Genre Id: 73)

    $ find . -regextype posix-extended -iregex '.*/[0-9]+-37(-[0-9]*){4}\..*' -exec rename -v -- '-37-' '-73-' {} \; > updateresults.txt

Step 5 is really critical and had to be done with really great care. Check the results after doing the job to guarantee that the changes done were according to the change needed.

Cheers

1 Like