We are running 3.3.0-8. I looked at our users’ profile → notifications tab, and it seems that all of them have “Enable these types of notifications” selected by default:
I doubt that our 1000+ users conscientiously selected this option for each type of announcement or that they are aware of it. I wonder whether there is a command I could run to uncheck these “enable” option for all users, so we can then let them know through an announcement on the journal website that they can opt into it if they wish.
Perhaps someone could share which database table stores values for the “Enable this type of notifications” selection? This way I could batch replace the value from 1 to 0, if my idea is correct.
Hi @Lolekbolek
It is unfortunately not that simple. The database has a table called notification_subscription_settings that contains a record for every user who blocks a type of notification. You’d need to create records in this table, one per user id, corresponding to the notification type you want to remove them from. Here’s what the table looks like:
The Notification types (which go in the setting_value column here) are defined as hexadecimal in lib/pkp/classes/notification/PKPNotification.inc.php. You can convert those to decimal to get the integer you’d need to put in this table.
Best
Jason
Thank you, @jnugent.
I looked at the notification_subscription_settings table. If the default “Enable these types of notifications” is selected, and “Do not send me an email for these types of notifications” is not selected in user’s profile, this user doesn’t appear in that table.
I tested two scenarios that make users appear in the table.
- If a user has both boxes selected all 9 options, the table has 9 rows.
- If a user has none of the boxes selected, then the table has 12 rows for them (see both scenarios below with some columns removed to avoid cluttering).
| User1: all boxes checked |
|
|
|
|
|
| setting_name |
setting_value |
context |
setting_type |
hex value in
PKPNotification.inc.php |
definition in
PKPNotification.inc.php |
| blocked_emailed_notification, |
16777217 |
8 |
int, |
0x1000001 |
NOTIFICATION_TYPE_SUBMISSION_SUBMITTED |
| blocked_emailed_notification, |
16777247 |
8 |
int, |
0x100001F |
NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_REQUIRED |
| blocked_emailed_notification, |
16777218 |
8 |
int, |
0x1000002 |
NOTIFICATION_TYPE_METADATA_MODIFIED |
| blocked_emailed_notification, |
16777219 |
8 |
int, |
0x1000003 |
NOTIFICATION_TYPE_REVIEWER_COMMENT |
| blocked_emailed_notification, |
16777249 |
8 |
int, |
0x1000021 |
NOTIFICATION_TYPE_NEW_QUERY |
| blocked_emailed_notification, |
16777250 |
8 |
int, |
0x1000022 |
NOTIFICATION_TYPE_QUERY_ACTIVITY |
| blocked_emailed_notification, |
8 |
8 |
int, |
|
|
| blocked_emailed_notification, |
16777258 |
8 |
int, |
0x100002A |
NOTIFICATION_TYPE_EDITORIAL_REPORT |
| blocked_emailed_notification, |
268435477 |
8 |
int |
|
|
|
|
|
|
|
|
| User2: none of the boxes checked |
|
|
|
|
|
| blocked_notification |
16777247 |
8 |
int |
0x100001F |
NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_REQUIRED |
| blocked_notification |
16777218 |
8 |
int |
0x1000002 |
NOTIFICATION_TYPE_METADATA_MODIFIED |
| blocked_notification |
16777219 |
8 |
int |
0x1000003 |
NOTIFICATION_TYPE_REVIEWER_COMMENT |
| blocked_notification |
16777249 |
8 |
int |
0x1000021 |
NOTIFICATION_TYPE_NEW_QUERY |
| blocked_notification |
16777250 |
8 |
int |
0x1000022 |
NOTIFICATION_TYPE_QUERY_ACTIVITY |
| blocked_notification |
8 |
8 |
int |
|
|
| blocked_notification |
16777258 |
8 |
int |
0x100002A |
NOTIFICATION_TYPE_EDITORIAL_REPORT |
| blocked_notification |
268435477 |
8 |
int |
|
|
| blocked_emailed_notification |
8 |
8 |
int |
|
|
| blocked_emailed_notification |
268435477 |
8 |
int |
|
|
| blocked_emailed_notification |
8 |
8 |
int |
|
|
| blocked_emailed_notification |
268435477 |
8 |
int |
|
|
I added hexadecimal values and descriptions from PKPNotification.inc.php for convenience. Interestingly, in the first scenario, all rows say “blocked_email_notification”, while in the second one, 7 of the same rows say “blocked_notification”, but there are 4 rows that say “blocked_email_notification”. At the same time, while both have the following values listed:
NOTIFICATION_TYPE_EDITOR_ASSIGNMENT_REQUIRED
NOTIFICATION_TYPE_METADATA_MODIFIED
NOTIFICATION_TYPE_REVIEWER_COMMENT
NOTIFICATION_TYPE_NEW_QUERY
NOTIFICATION_TYPE_QUERY_ACTIVITY
NOTIFICATION_TYPE_EDITORIAL_REPORT
the first scenario also has a value “NOTIFICATION_TYPE_SUBMISSION_SUBMITTED”.
Both scenarios, though, also have an “8” and a “268435477” value, which I can’t understand, because those are not in PKPNotification.inc.php.
Now, I believe I could populate the notification_subscription_settings table with 9 rows for each user, which would make them all “unsubscribed”. I just wonder whether it would be OK to insert the 9 rows from the scenario 1 (with its “8” and “268435477”) for each user or I should clean up something somewhere fist?
What do you think?
Hi @Lolekbolek
The 8 is for the new announcement notification (in PKPNotification).
define('NOTIFICATION_TYPE_NEW_ANNOUNCEMENT', 0x0000008);
And there are two types of blocked notifications here. It is is possible to have a blocked notification just for email (blocked_notification_email) but still receive them within OJS, so no blocked_notification. There are a bunch of combinations here.
Some of these notifications, as a user, I would probably want to receive, especially if I was involved in a submission’s workflow. Knowing, for example, that there is a reviewer comment or the metadata has been modified, would be useful. I understand wanting to unsubscribe from emails about announcements or new issues but I personally wouldn’t remove workflow emails since those only affect users involved in the editorial process of your journal.
Best
Jason
Thank you, @jnugent.
So, if “Enable these types of notifications” is selected, and “Do not send me an email for these types of notifications” is not selected in user’s profile, then they won’t receive an email, but they would see a pop-up announcement for whatever option that has the first checkmark?
We only have 70 users out of 1200 who have an entry in this table, so I could leave those users’ entries intact and load the two non-workflow settings for the rest. I could just add two first entries from the table below: “New announcement” = “8” and
“An issue has been published.” = “268435477”? Does it sound reasonable?
| Public Announcements: |
|
| New announcement. |
NEW_ANNOUNCEMENT |
| An issue has been published. |
268435477 |
|
|
| Submission Events: |
|
| A new article, Title, has been submitted. |
SUBMISSION_SUBMITTED |
| A new article has been submitted to which an editor needs to be assigned. |
EDITOR_ASSIGNMENT_REQUIRED |
| Title’s metadata has been modified. |
METADATA_MODIFIED |
| Discussion added. |
NEW_QUERY |
| Discussion activity. |
QUERY_ACTIVITY |
|
|
| Reviewing Events: |
|
| A reviewer has commented on Title. |
REVIEWER_COMMENT |
|
|
| Editors: |
|
| Statistics report summary. |
EDITORIAL_REPORT |
That sounds like a reasonable plan, and yes, if users do not receive emails for notifications they can still get the popup versions inside the application.
Best
Jason
One last thank you to @jnugent! Based on your suggestions, I proceeded like this:
- exported the notification_subscription_settings table
- copy/pasted the user_id column into Excel
- exported the users table
- copy/pasted the user_id column into Excel
- deduplicated the two user_id columns, which removed from the main column those users who had notification settings different from default
- concatenated the resulting user_id column into a csv file looking like this:
blocked_emailed_notification,8,44,8,int
blocked_emailed_notification,268435477,44,8,int
blocked_emailed_notification,8,60,8,int
blocked_emailed_notification,268435477,60,8,int
etc.
- and finally ran the following command in phpMyAdmin:
LOAD DATA INFILE 'rows_to_batch_load.csv'
INTO TABLE notification_subscription_settings
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
(setting_name, setting_value, user_id, context, setting_type)
As the result, we set the setting for 1200 users who have not edited their profiles to “Do not send me an email for these types of notifications” for “New announcement” and “An issue has been published” announcements. We will now be suggesting that they go to their profiles and opt-in if they so wish, which is what we wanted to achieve.
Very glad to hear that this has worked out for you!
Best
Jason