Editorial history does not work

Software Support
1

Hello!
I am using the git version of OJS (currently 125e2fa468), and the editorial history dialog stopped working for some submissions. When I try to open it, I see the following error in the apache log file:

HP Fatal error:  Uncaught Error: Call to a member function getFullName() on null in /var/www/ojs/lib/pkp/classes/user/PKPUserDAO.inc.php:465
Stack trace:
#0 /var/www/ojs/lib/pkp/classes/log/EmailLogEntry.inc.php(129): PKPUserDAO->getUserFullName('0', true)
#1 /var/www/ojs/lib/pkp/controllers/grid/eventLog/EventLogGridCellProvider.inc.php(96): EmailLogEntry->getSenderFullName()
#2 /var/www/ojs/lib/pkp/classes/controllers/grid/GridCellProvider.inc.php(49): EventLogGridCellProvider->getTemplateVarsFromRowColumn(Object(EventLogGridRow), Object(GridColumn))
#3 /var/www/ojs/lib/pkp/classes/controllers/grid/GridHandler.inc.php(1096): GridCellProvider->render(Object(Request), Object(EventLogGridRow), Object(GridColumn))
#4 /var/www/ojs/lib/pkp/classes/controllers/grid/GridHandler.inc.php(1003): GridHandler->_renderCellInternally(Object(Request), Object(EventLogGridRow), Object(GridColumn))
#5 /var/www/ojs/lib/pkp/classes/controllers/grid/GridHandler.inc.php(980): GridHandler->renderRowInternally(Object(Request), Object(EventLogGridRo in /var/www/ojs/lib/pkp/classes/user/PKPUserDAO.inc.php on line 465

How do I further investigate and resolve this issue?

UPDATE
I’ve pinpointed the line that causes the problem. The file lib/pkp/classes/log/EmailLogEntry.inc.php, function getSenderFullName():

function getSenderFullName() {
$senderFullName =& $this->getData('senderFullName');

if(!isset($senderFullName)) {
    $userDao = DAORegistry::getDAO('UserDAO');
    $senderFullName = $userDao->getUserFullName($this->getSenderId(), true); # This is the line.
}

return ($senderFullName ? $senderFullName : '');
}

If I simply wrap the problematic line in try/catch, everything seems to work fine. Do I need to file a bug report about this?

1 Like
2

Hi @Taomach,

I suspect you have a database inconsistency – an entry in email_log that refers to a non-existent entry in users. Try this query:

SELECT e.sender_id FROM email_log e LEFT JOIN users u ON (e.sender_id = u.user_id) WHERE u.user_id IS NULL;

This will give you a list of entries in email_log that refer to nonexistent senders. These should be reviewed and either updated or removed.

Regards,
Alec Smecher
Public Knowledge Project Team

3

Yes, I do have a bunch of entries in the email_log table where the sender_id is 0. These entries were probably corrupted when I ran the upgrade.php script after migrating from 3.1.1 to the git version of OJS. How do I make sure this does not happen in the future?

4

Hi @Taomach,

OJS should take care of keeping its database integrity intact. I’m not sure where these entries arose from.

Regards,
Alec Smecher
Public Knowledge Project Team

5

Ok, I’ll just hope that it will work from now on, then. I removed the try/catch that I added earlier, fixed those entries, and it seems to have resolved the issue. Thank you for the great work and for your help with this. Have a great day!

1 Like
6

Hi @asmecher,

I have the same issue but only in one manuscript. How can I solve the issue? I try with the query and I found 131 rows, but I don’t know what need to do now…

regards,
Carlos

7

Hi @t4x0n,
I can tell you what I did. In may case the broken entries in the email_log table all had 0 in the sender_id field. So I did this:

SELECT from_address FROM email_log WHERE sender_id=0;

to see who the real senders were, and then for each address I SELECT'ed the user_id from the users table, and run

UPDATE email_log SET sender_id=$USER_ID_HERE WHERE sender_id=0 AND from_address='$FROM_ADDRESS_HERE';

In my case it helped.

8

Hi @asmecher , @Taomach

I have the same problem.

I did taomach’s solution, but nothing.

I have an Editorial history with sender_id = 0.

But i have another Editorial history with sender_id = 0 and it’s work ?¿?¿?¿

some suggestion? Thanks.

error.log:
Call to a member function getStageId() on null in /ojs/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 762, referer: https://xxxxxxxxxxxx/ojs/index.php/ramd/workflow/index/549/3

9

Hi @asmecher .

More information

Screenshot_2019-01-28%20phpmyadmin%20ctd%20junta-andalucia%20es%20mysql%20ctd%20junta-andalucia%20es%20ojs%20review_rounds%20phpMyAdmin%204%204%2015%2010 %5D

10

Hi @juanito,

What version of OJS are you using? (Please include this with your posts.)

Regards,
Alec Smecher
Public Knowledge Project Team

11

Hi @asmecher
OJS 3.1.1.4.
Thank you very much

13

Hi @juanito,

This looks like a data error. Apparently you have an entry in notes with assoc_type = 1048586 (ASSOC_TYPE_QUERY) and an assoc_id that refers to a non-existent query_id in the queries table.

Regards,
Alec Smecher
Public Knowledge Project Team

14

Thanks @asmecher , can i delete this entry in notes?

15 
MariaDB [ojs]> SELECT * FROM notes WHERE assoc_id=549 \G
*************************** 1. row ***************************
      note_id: 639
   assoc_type: 1048586
     assoc_id: 549
      user_id: 10
 date_created: 2018-09-13 12:59:13
date_modified: 2018-09-13 13:02:14
        title: xxxxxxxxxxxxx
     contents: xxxxxxxxxxxxxxx
1 row in set (0.00 sec)

MariaDB [ojs]>
16 
MariaDB [ojs]> SELECT * FROM queries WHERE assoc_id=549 \G
*************************** 1. row ***************************
     query_id: 617
   assoc_type: 1048585
     assoc_id: 549
     stage_id: 1
          seq: 1
  date_posted: NULL
date_modified: NULL
       closed: 1
*************************** 2. row ***************************
     query_id: 633
   assoc_type: 1048585
     assoc_id: 549
     stage_id: 1
          seq: 2
  date_posted: NULL
date_modified: NULL
       closed: 0
*************************** 3. row ***************************
     query_id: 634
   assoc_type: 1048585
     assoc_id: 549
     stage_id: 1
          seq: 3
  date_posted: NULL
date_modified: NULL
       closed: 0
*************************** 4. row ***************************
     query_id: 635
   assoc_type: 1048585
     assoc_id: 549
     stage_id: 1
          seq: 4
  date_posted: NULL
date_modified: NULL
       closed: 0
*************************** 5. row ***************************
     query_id: 791
   assoc_type: 1048585
     assoc_id: 549
     stage_id: 3
          seq: 5
  date_posted: NULL
date_modified: NULL
       closed: 0
5 rows in set (0.03 sec)
17

Hi @juanito,

You don’t want to match the assoc_id of the entry in notes with the assoc_id of the entry in queries – these are different things.

You’ll want to look for entries in notes with assoc_type = 1048586 (ASSOC_TYPE_QUERY) that don’t match any query_id in queries.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
18

How does they relate notes and queries? Thanks

19

i tested

SELECT * FROM notes WHERE assoc_type = 1048586 AND assoc_id NOT IN (SELECT query_id FROM queries)

100 rows, result.

i don’t understand. Thanks and sorry for messages.

20

Hi @asmecher
Then, can i delete the 100 rows? Thanks.

21

Hi @juanito,

Hm, that’s quite a few. Essentially when you create a new discussion (“query” in code terms), it also creates a note that contains its subject and contents. (Further comments are added as new notes.) The assoc_type/assoc_id combination in the notes table indicates that the notes are attached to queries (assoc_type=1048586) and the assoc_id indicates which query (referring to the query_id in the queries table).

I’m not sure how you would end up with 100 notes that refer to non-existent queries. Do you know if there was some manual intervention in the database? Are you able to replicate this behavior e.g. by somehow creating a 101st case?

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like