Decision email log not shown to author

Software Support
1

I am using OJS 3.1.2 and for some reason the email logs with editorial decisions do not show up on the author’s Dashboard after a submission has been declined. The editorial decision was recorded correctly, the email was sent and received. But when the author checks the ‘Review’ tab there is nothing under “Round 1 Status: Submission Declined”, as shown in the screenshot below.

Note that this was not an initial decline: there was one external reviewer who accepted the task, submitted the review and had his work acknowledged before the submission was declined.

Digging at the code I noted that its is expected that records at the email_logs table have a corresponding record at the email_log_users table. But whereas the first table has the the correct record for the editorial decision email, the second table is empty. And indeed, if I add the missing record manually to the email_log_users table, the log pops up in the author dashboard.

Could you provide me any clue to what may be causing this issue?

I may also add that the we do not use any review forms, and that the reviewer did not upload any files. Also, the text that was typed by the reviewer in the default review boxes was not added to the email, although I clicked on the button to add the review to the email.

Best regards,
Vladimir Vieira

screenshot

2

Hi @vladv,

Can you show me the relevant entries from email_logs?

Thanks,
Alec Smecher
Public Knowledge Project Team

3

Hi @asmecher,

thank you for your prompt answer. The relevant records from email_logs are shown below. I have removed the body of the email messages to make it easier to read, but I can assure you those fields have exactly what they are supposed to have. Those are all the records pertaining to the submission in question (because we use OJS in Portuguese, which you probably won’t be able to read, I have added a header identifying which step of the editorial process corresponds to which record):

log_id, assoc_type, assoc_id, sender_id, date_sent, ip_address, event_type, from_address, recipients, cc_recipients, bcc_recipients, subject, body

submission received
‘10’, ‘1048585’, ‘9’, ‘6’, ‘2019-09-03 03:25:27’, ‘::1’, NULL, ‘“Vladimir Vieira” vlad.m.vieira@gmail.com’, ‘vlad.m.vieira@gmail.com’, NULL, NULL, ‘[Viso] Submissão recebida’, ‘email content’

request for external review
‘11’, ‘1048585’, ‘9’, ‘2’, ‘2019-09-03 03:33:09’, ‘::1’, NULL, ‘“Vladimir Vieira” vladv@monocromo.com.br’, ‘vladimir.m.vieira@gmail.com’, NULL, NULL, ‘[Viso] Solicitação de avaliação’, ‘email content’

external reviewer confirmed
‘12’, ‘1048585’, ‘9’, ‘7’, ‘2019-09-03 03:34:36’, ‘::1’, ‘1073741829’, ‘“Vladimir Vieira” vladimir.m.vieira@gmail.com’, ‘vladv@monocromo.com.br’, NULL, NULL, ‘[Viso] Disponível para realizar avaliação’, ‘email content’

review acknowledged (Thanks the reviewer)
‘13’, ‘1048585’, ‘9’, ‘2’, ‘2019-09-03 03:47:40’, ‘::1’, NULL, ‘“Vladimir Vieira” vladv@monocromo.com.br’, ‘vladimir.m.vieira@gmail.com’, NULL, NULL, ‘[Viso] Agradecimento pela avaliação’, ‘email content’

editorial decision: decline
‘14’, ‘1048585’, ‘9’, ‘2’, ‘2019-09-03 03:48:24’, ‘::1’, ‘805306369’, ‘“Vladimir Vieira” vladv@monocromo.com.br’, ‘vlad.m.vieira@gmail.com’, NULL, NULL, ‘[Viso] Avaliação concluída’, ‘email content’

Submission Id is 9, and author User Id is 6 (vlad.m.vieira@gmail.com).

As I mentioned before, email_log_users was empty and the decision email log was missing from the author’s panel. After I manually added the record below, the log showed up.

email_log_id, user_id
‘14’, ‘6’

EDIT: Tonight I did manage to get the reviews into the email body, seems like TinyMCE plugin was not enabled on my journal. But I repeated the test and the problem with empty email_log_users table remains. I didn’t expect those two issues to be linked, but I thought it best to let you know anyway.

Best regards,
Vladimir Vieira

4

Hi @vladv,

Hmm, I’m having trouble replicating this; are the emails being received? Is anything relevant appearing in the PHP error logs? Do you have any Authors listed in the “Participants” grid on the right-hand side of the workflow page?

Regards,
Alec Smecher
Public Knowledge Project Team

5

Hi @asmecher,

Thank you for taking the time to look into this. The emails are being received with no issues, and both author and editor are listed in the right side of the Workflow page. I repeated the whole process one more time but nothing shows up in the PHP error log.

I suppose there must something preventing records being written to table email_log_users. Is there any condition that has to be met for this to happen? I understand this is probably difficult to replicate, so maybe I can try later digging a bit into the code if you can you point out to me where exactly this operation is performed.

Best regards,
Vladimir Vieira

6

Hi @asmecher,

So, I look a little further and found out why nothing is being written to email_log_users. Emails logs are processed by the insertObject method of EmailLogDAO class, which by its turn calls the _insertLogUserIds of the same class. This method expects recipients to be identified by email and name, something like User name <user_name@domain.com>. So it does a preg_match to extract the emails:

preg_match_all($pattern, $recipients, $matches);

If nothing is found it exits:

if (!isset($matches[0])) return;

But, as you can see from the records in email_logs table, the recipient of the emails sent to the author are not formatted like that. They contain just the plain email (“vlad.m.vieira@gmail.com”). This is true for all the messages being sent out, so nothing ends up written to email_log_users.

I tried digging a little deeper to understand why the recipients are being set like this but the Identity/Author classes are a trifle more complex. Can you help me at this point? Any suggestion would be highly appreciated.

Best regards,
Vladimir Vieira

7

Hi @vladv,

Hmm, good spotting. I wonder if this is because localized user names aren’t available in the language you’re using, or similar – does this ring a bell? (For example, the submission is in Russian but you’re using the site in English, and author information isn’t available in English. There ought to be a fallback on the submission’s primary language, but I’m wondering if that’s not working.)

I think you’ll find the recipient additions for the message you’re working with in lib/pkp/controllers/modals/editorDecision/form/EditorDecisionWithEmailForm.inc.php – look for addRecipient. I suspect this is being called without a screen name being set, just an email address.

I think a good solution would be to add support in the regular expression for emails that don’t contain screen names, but it would also be nice to know why a screen name isn’t being passed along.

Thanks,
Alec Smecher
Public Knowledge Project Team

8

Hi @asmecher ,

Thanks once more for the info. I finally managed to find out the culprit, but I’d still appreciate some feedback from you so I can decide what’s the best way to fix it. It turns out that the emails are being sent out correctly with name and email (User name <email@domain.com>). I’ve confirmed this by checking the email inbox.

The problem happens later in the logging. Method log of class SubmissionMailTemplate does not send the recipients array directly to EmailLogDAO, but rather a plain string version of it obtained by calling method getAddressArrayString (via getRecipientString).

getAddressArrayString receives the correct array ("name"=>"User name", "email" => "email@domain.com"), but does not return what it should (User name <email@domain.com>), just the email (email@domain.com). This gets passed on to the insertObject method of EmailLogDAO class, and so the record never gets written to email_log_users for the reasons I mentioned earlier.

Looking at the code, it seems it does that on purpose on Windows systems:

if (Core::isWindows() || empty($address['name']) || !$includeNames) {
$addressString .= $address['email'];
} else {
$addressString .= self::encodeDisplayName($address['name'], $send) . ' <'.$address['email'].'>';
}

So my guess is that it will never work on Windows systems (that’s what I’m using by the way). Although I cannot imagine why, I suppose this restriction is set for a reason, so removing Core::isWindows() from the if conditions would not be an option. I can think of two possible solutions:

A. Enclose the email in <>, changing the second line to

$addressString .= ‘<’ . $address[‘email’] . ‘>’;

This would make the email pass the preg_match in _insertLogUserIds, allowing records to be written to email_log_users. I don’t know if there is any impact in recording it like this in email_logs but I’m guessing not, since it expects something even more cluttered. I also do not know if this could cause any impact on calls made to this method at other points of the code.

B. Changing, as you suggested, the preg_match in _insertLogUserIds so that plain emails also pass.

I am leaning more towards the first option because it’s simpler, but I would really appreciate if you could share your opinion on this.

On a side note, I think this should probably go down as a bug to be fixed in future releases because, so far as I can see, it will never work if Core::isWindows() returns true, or whenever there is no name in the recipients list (which may happen, as you indicated, if the user leaves the name fields empty in a different locale and suddenly decides to make a submission using that locale - it’s far-fetched, I know, but users have a knack for doing far-fetched things!).

Best regards,
Vladimir Vieira

9

Hi @vladv,

I think the basis of the different Windows behavior is this note in the PHP documentation:

The Windows implementation of mail() differs in many ways from the Unix implementation. First, it doesn’t use a local binary for composing messages but only operates on direct sockets which means a MTA is needed listening on a network socket (which can either on the localhost or a remote machine).

Second, the custom headers like From: , Cc: , Bcc: and Date: are not interpreted by the MTA in the first place, but are parsed by PHP.

As such, the to parameter should not be an address in the form of “Something someone@example.com”. The mail command may not parse this properly while talking with the MTA.

The good news is that we’re now using the PHPMailer library both for SMTP and Sendmail-style mail sending, so that caveat no longer applies. I’ve filed this at Submission email logs not always presented on Windows systems · Issue #5056 · pkp/pkp-lib · GitHub and will remove the Windows test and different behavior.

Thanks for helping to track this down!

Regards,
Alec Smecher
Public Knowledge Project Team