Activity log not work

The activity log doesn’t load for all submission.
The php error log:
[23-Dec-2021 08:21:36 UTC] PHP Notice: Undefined index: stageId in /var/www/html/lib/pkp/controllers/grid/eventLog/SubmissionEventLogGridHandler.inc.php on line 111
[23-Dec-2021 08:32:08 UTC] PHP Notice: Undefined index: stageId in /var/www/html/lib/pkp/controllers/grid/eventLog/SubmissionEventLogGridHandler.inc.php on line 111
[23-Dec-2021 08:34:47 UTC] PHP Notice: Undefined index: stageId in /var/www/html/lib/pkp/controllers/grid/eventLog/SubmissionEventLogGridHandler.inc.php on line 111

Y use ojs 3.3.0.8 with php 7.4, debian 9, mysql 5.5
Thank

Hello @patrizia,

This issue was raised when none stageId was sent to the backend, but those are only PHP notices, they aren’t blocking your application to run properly.

Probably this issue is related with another code section.

These are the only messages they were unable to recover. I also tried to edit the lib / pkp / classes / services / PKPSubmissionFileService.inc.php file as suggested by others but the problem still persists. I don’t know how to fix it.

I noticed that the problem occurs when display_error = on in the config.php.ini file. With off value it work.

Yes, because display_error throws any PHP error on browsers output. Should be used only for development.

In production this variable should be set as Off.

We observe the same behavior of an activity log not loading for a submission too. However, after the PHP Notice, we see the following PHP Fatal error in the log:
[18-Mar-2022 15:44:07 Europe/Zurich] PHP Fatal error: Uncaught Error: Call to a member function getStageId() on null in /usr/local/service/www/ojs/lib/pkp/classes/services/PKPSubmissionFileService.inc.php:769

As a hint: The submission was submitted in OJS 3.2, it is now in a second review round in OJS 3.3.0-8 - has something been changed in the database schema so that now it makes problems after the migration?

Also, in the event log table I see that sometimes the stageId is missing for that submission in case of reviewer assignments.

@asmecher - the bug is created by a file that has been deleted during a review round - the submission_file_id is still around in various tables, in our case:

select * from submission_files where submission_file_id=6178\G
*************************** 1. row ***************************
       submission_file_id: 6178
source_submission_file_id: NULL
            submission_id: 2603
               file_stage: 15
                 viewable: 0
               created_at: 2021-12-02 14:14:08
               updated_at: 2021-12-02 14:14:08
                 assoc_id: 0
                 genre_id: 37
       direct_sales_price: NULL
               sales_type: NULL
         uploader_user_id: 18520
               assoc_type: 0
                  file_id: 5247
select * from submission_file_revisions where submission_file_id=6178\G
*************************** 1. row ***************************
       revision_id: 5247
submission_file_id: 6178
           file_id: 5247
select * from submission_file_settings where submission_file_id=6178\G
*************************** 1. row ***************************
submission_file_id: 6178
            locale: en_US
      setting_name: name
     setting_value: Article Text, Full paper_Media quality attitudes_2021 - Revised - Copy.docx
      setting_type: string

However, it is doesn’t exist anymore in the review rounds table:

select * from review_round_files where submission_file_id=6178\G
**Empty set (0.00 sec)**

When a file is deleted in the review round, should then also the corresponding records in tables submission_files, submission_file_revisions and submission_file_settings be deleted?
If yes → something is wrong in the code that executes the deletion
If no → then there is a problem with the value of the file_stage (which is 15 = SUBMISSION_FILE_REVIEW_REVISION), which leads to wrong code execution around line 769 in
lib/pkp/classes/services/PKPSubmissionFileService.inc.php

case SUBMISSION_FILE_INTERNAL_REVIEW_REVISION:
                                $reviewRoundDao = DAORegistry::getDAO('ReviewRoundDAO'); /* @var $reviewRoundDao ReviewRoundDAO */
                                $reviewRound = $reviewRoundDao->getBySubmissionFileId($submissionFile->getId());
                                return $reviewRound->getStageId();

There is no check on that $reviewRound may be null if the file was deleted.
One solution would be to attribute another file_stage so that this code part will be skipped.
Either way, you should open a Github issue.

OJS 3.3.0-8

I’ve added a (temporary) fix on line 769:
return is_null($reviewRound) ? null : $reviewRound->getStageId();
The activity log is now loading in our case.

Hello @mpbraendle ,

We’re on 3.3.0.10 and also experiencing the same problem, apparently.

PHP Notice:  Undefined index: stageId in /var/www/revista.ibict.br/lib/pkp/controllers/grid/eventLog/SubmissionEventLogGridHandler.inc.php on line 111, referer: http://revista.ibict.br/ciinf/workflow/index/5283/4

Will the fix you provided solve our problem?

Submission workflow is sluggish. It’s taking a lot of time to conclude the task of sending the eidtorial decision.

We’ve also experienced sluggishness when changing journal settings, needing to refresh, redo the edit and save a couple of times for it to go fast.

Since OJS 3.3.0.1 we have had sluggishness when sending files for publishing (issue galley, article galley),when files are not being sent on the modal window and we need to restart the process, refreshing the article publishing window and then either replacing or deleting and adding a new PDF, for example.

Are these issues related?

Yes, the fix should solve the PHP Notice: Undefined index: stageId … problem.

With regards to sluggish submission workflow - I can’t help you in this case.

For another journal that has large PDF files, we observe that may take up to one minute until the article is published. This is due to the indexing going on in the background.

In our repository software that I’m also managing (and developing further), lengthy tasks such indexing or compute tasks that may interact with APIs of external sources are sent to a task queue and processed asynchronously. We should have something similar in OJS, but I’m pretty sure this is on the radar by PKP or already being developed for a next version.

Hello @mpbraendle ,

Thanks for your reply!
We’ve noticed that after a recent Chrome upgrade, OJS has become sluggish. Testing with Firefox seems to solve the problem.
Apparently, Chrome is no longer compatible to some W3C standards and it’s breaking OJS.