Null notifications, what are those supposed to be?

I’m getting those notifications when I log in OJS. I’m the journal administrator and manager in 18 journals, as such I don’t know which journal is giving me that, or if all of them is making those pop.

Captura de tela 2020-12-22 084154

Is there anyway to check the notifications that were generated so I can track the cause of that?

When I upgraded to OJS 3.x I had a lot of problems with missing notifications and I had to manually create an entry in the table. I think this problem is related to that. How can I verify that I have all the entries needed in the notification table?

I found those in the notifications table:
image

The best clue is probably in the type column. This corresponds to a constant that should be unique for each type of notification. Here is a quick list of all of those I found in OJS 3.3.0:


    [NOTIFICATION_TYPE_PUBLISHED_ISSUE] => 268435477
    [NOTIFICATION_TYPE_BOOK_REQUESTED] => 50331649
    [NOTIFICATION_TYPE_BOOK_CREATED] => 50331650
    [NOTIFICATION_TYPE_BOOK_UPDATED] => 50331651
    [NOTIFICATION_TYPE_BOOK_DELETED] => 50331652
    [NOTIFICATION_TYPE_BOOK_MAILED] => 50331653
    [NOTIFICATION_TYPE_BOOK_SETTINGS_SAVED] => 50331654
    [NOTIFICATION_TYPE_BOOK_SUBMISSION_ASSIGNED] => 50331655
    [NOTIFICATION_TYPE_BOOK_AUTHOR_ASSIGNED] => 50331656
    [NOTIFICATION_TYPE_BOOK_AUTHOR_DENIED] => 50331657
    [NOTIFICATION_TYPE_BOOK_AUTHOR_REMOVED] => 50331658
    [NOTIFICATION_LEVEL_TRIVIAL] => 1
    [NOTIFICATION_LEVEL_NORMAL] => 2
    [NOTIFICATION_LEVEL_TASK] => 3
    [NOTIFICATION_TYPE_SUCCESS] => 1
    [NOTIFICATION_TYPE_WARNING] => 2
    [NOTIFICATION_TYPE_ERROR] => 3
    [NOTIFICATION_TYPE_FORBIDDEN] => 4
    [NOTIFICATION_TYPE_INFORMATION] => 5
    [NOTIFICATION_TYPE_HELP] => 6
    [NOTIFICATION_TYPE_FORM_ERROR] => 7
    [NOTIFICATION_TYPE_NEW_ANNOUNCEMENT] => 8
    [NOTIFICATION_TYPE_PLUGIN_ENABLED] => 83886081
    [NOTIFICATION_TYPE_PLUGIN_DISABLED] => 83886082
    [NOTIFICATION_TYPE_PLUGIN_BASE] => 100663297
    [NOTIFICATION_TYPE_SUBMISSION_SUBMITTED] => 16777217
    [NOTIFICATION_TYPE_METADATA_MODIFIED] => 16777218
    [NOTIFICATION_TYPE_REVIEWER_COMMENT] => 16777219
    [NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_SUBMISSION] => 16777220
    [NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_INTERNAL_REVIEW] => 16777221
    [NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_EXTERNAL_REVIEW] => 16777222
    [NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_EDITING] => 16777223
    [NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_PRODUCTION] => 16777224
    [NOTIFICATION_TYPE_REVIEW_ASSIGNMENT] => 16777227
    [NOTIFICATION_TYPE_EDITOR_DECISION_INTERNAL_REVIEW] => 16777229
    [NOTIFICATION_TYPE_EDITOR_DECISION_ACCEPT] => 16777230
    [NOTIFICATION_TYPE_EDITOR_DECISION_EXTERNAL_REVIEW] => 16777231
    [NOTIFICATION_TYPE_EDITOR_DECISION_PENDING_REVISIONS] => 16777232
    [NOTIFICATION_TYPE_EDITOR_DECISION_RESUBMIT] => 16777233
    [NOTIFICATION_TYPE_EDITOR_DECISION_NEW_ROUND] => 16777264
    [NOTIFICATION_TYPE_EDITOR_DECISION_DECLINE] => 16777234
    [NOTIFICATION_TYPE_EDITOR_DECISION_SEND_TO_PRODUCTION] => 16777235
    [NOTIFICATION_TYPE_EDITOR_DECISION_REVERT_DECLINE] => 16777248
    [NOTIFICATION_TYPE_REVIEW_ROUND_STATUS] => 16777236
    [NOTIFICATION_TYPE_PENDING_INTERNAL_REVISIONS] => 16777237
    [NOTIFICATION_TYPE_PENDING_EXTERNAL_REVISIONS] => 16777238
    [NOTIFICATION_TYPE_COPYEDIT_ASSIGNMENT] => 16777239
    [NOTIFICATION_TYPE_LAYOUT_ASSIGNMENT] => 16777241
    [NOTIFICATION_TYPE_INDEX_ASSIGNMENT] => 16777242
    [NOTIFICATION_TYPE_APPROVE_SUBMISSION] => 16777243
    [NOTIFICATION_TYPE_CONFIGURE_PAYMENT_METHOD] => 16777244
    [NOTIFICATION_TYPE_FORMAT_NEEDS_APPROVED_SUBMISSION] => 16777245
    [NOTIFICATION_TYPE_VISIT_CATALOG] => 16777246
    [NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_REQUIRED] => 16777247
    [NOTIFICATION_TYPE_NEW_QUERY] => 16777249
    [NOTIFICATION_TYPE_QUERY_ACTIVITY] => 16777250
    [NOTIFICATION_TYPE_ASSIGN_COPYEDITOR] => 16777251
    [NOTIFICATION_TYPE_AWAITING_COPYEDITS] => 16777252
    [NOTIFICATION_TYPE_AWAITING_REPRESENTATIONS] => 16777253
    [NOTIFICATION_TYPE_ASSIGN_PRODUCTIONUSER] => 16777254
    [NOTIFICATION_TYPE_EDITOR_ASSIGN] => 16777255
    [NOTIFICATION_TYPE_PAYMENT_REQUIRED] => 16777256
    [NOTIFICATION_TYPE_REVIEW_ASSIGNMENT_UPDATED] => 16777257
    [NOTIFICATION_TYPE_EDITORIAL_REPORT] => 16777258
    [NOTIFICATION_TYPE_SUBMISSION_NEW_VERSION] => 16777259
    [NOTIFICATION_STYLE_CLASS_WARNING] => notifyWarning
    [NOTIFICATION_STYLE_CLASS_INFORMATION] => notifyInfo
    [NOTIFICATION_STYLE_CLASS_SUCCESS] => notifySuccess
    [NOTIFICATION_STYLE_CLASS_ERROR] => notifyError
    [NOTIFICATION_STYLE_CLASS_FORM_ERROR] => notifyFormError
    [NOTIFICATION_STYLE_CLASS_FORBIDDEN] => notifyForbidden
    [NOTIFICATION_STYLE_CLASS_HELP] => notifyHelp

I just checked all of those codes and I also have those 3 that are missing from your list:

notification_id: count (dates)
268435478: 16920 (2010-2012)
369098754: 145 (2018-2021)
369098756: 33 (2018-2021)

The last 2 were created both in version 2.8.x and already at OJS 3.3.

Hi @luizborges @NateWr, how are you? I am experimenting the same problem. I checked the “notifications table” and I found the following type of notification: 369098754 (it doesn´t appear on the list). Do you know where can I find the information about this type?
Thank you!

Hi,

Same problem here, is there some solution already?

Regards,

Tarcisio Pereira

@Tarcisio_Pereira not really. I openned an issue on Github to see if we can track this error down somehow.

Hi @luizborges, bringing our conversation from GitHub back to the forum. There you asked:

Where are those notifications being generated? Can I log what info/db entry they use to generate those? Maybe this way I can track this down. What DB tables are related to this that I can investigate?

I’d recommend starting with PKPLocale::translate(). This is where every locale key (any.locale.key) is converted into a message.

If you add some logging there it’s going to be noisy, because it gets hit with every translated string. But you might be able to detect what is happening by inspecting the key that’s passed, or looking for empty strings returned by the function. If you throw an exception in there when you get an empty string result, you should get some clues about the code that’s calling it.

@NateWr, I don’t believe the issue is related to translation, as the same issue happens in the English interface, where no translation is done.

Looking over our previous conversation: old notification type codes could definitely be the problem here. The backtrace from an exception in PKPLocale::translate() will hopefully help track those down. But it may take some investigative work going back to OJS 2.x to figure out what types the old codes referred to, and whether they need to be migrated to new types.

How would I go about throwing an error that isn’t fatal (meaning it doesn’t show up for the user) but is still logged in httpd-error.log?

One of those codes still happens today as I mentioned on github. I tried to search for it both in decimal and in hex, but couldn’t find it on the source code: 369098754. I strongly suspect this is the culprit.

I’d strongly recommend getting a dev clone of this site going where you can reproduce these problems. If that’s not possible, you can try this:

try {
    throw new Exception();
} catch(Exception $e) {
    error_log($e->getTraceAsString());
}

One of those codes still happens today

I checked for that myself but it doesn’t look like it’s in 3.3. Maybe it’s related to a plugin? I don’t have OJS 2.x to look back at, but I’ll see if one of my colleagues can find the three constants mentioned in this post.

The idea that this could be related to a plugin is an interesting one. I made a list of all plugins enabled in one journal or another in my installation:

Block Plugins

  • Browse Block
  • “Developed By” Block
  • Information Block
  • Keyword Cloud Block
  • Language Toogle Block

Gateway Plugins

  • Resolver Plugin

Generic Plugins

  • Announcement Feed Plugin
  • Authors History
  • Citation Style Plugin
  • Custom Block Manager
  • Default Translation Plugin
  • DRIVER
  • Dublin Core Indexing Plugin
  • Google Analytics Plugin
  • Google Scholar Indexing Plugin
  • eLife Lens Article Viewer
  • ORCID Profile Plugin
  • OpenAIRE
  • PDF.JS PDF Viewer
  • Matomo Plugin
  • PKP PN Plugin
  • Recommend Articles by Author
  • Recommend Similar Articles
  • Static Pages Plugin
  • Text Editor Extras
  • Web Feed Plugin

Public Identifier Plugins

  • DOI

Theme Plugins

  • Default Theme

Not sure if any of those could be responsable.

I added a throw at the end of the code before it return the possible null/empty $value at the end, like you suggested, lets hope it sheds some light in the matter.

I think 369098754 and 369098756 are from the PKP PN plugin, specifically NOTIFICATION_TYPE_PLUGIN_BASE ( 0x6000001)

plus (!?!?) 0x10000000 as PLN_PLUGIN_NOTIFICATION_TYPE_PLUGIN_BASE;
and plus 0x0000001 as PLN_PLUGIN_NOTIFICATION_TYPE_TERMS_UPDATED:

or plus 0x0000003 as PLN_PLUGIN_NOTIFICATION_TYPE_HTTP_ERROR:

This crime against HEX is still present in master.

1 Like

Shallow sampling for 268435478, or 0x10000016, disappears for us around the time of upgrades from 2.3.8 to 2.4.5, so this value may be from the 2.3 era.

I think @ctgraham cracked the case. Indeed this seems could be the case…

I think the one I’m still getting (0x16000002) is probably

  • PLN_PLUGIN_NOTIFICATION_TYPE_ISSN_MISSING

But is there a way to know which journal is missing the ISSN, and why I get this notification so sporadically (I think it is around once or twice a week, but sometimes much longer without a notification or many more in a shorter interval)?

PS: Great detective work deconstructing this hex crime as you said.

If I am reading the code right, then 0x16000002 is actually:

0x6000001 (plugin base) + 0x10000000 (pln base) + 0x0000001 (terms updated)

Indeed you are correct. What terms were updated, and why the notification string doesn’t show up neither in portuguese or english is another mystery :smiley: