How could I mass update Sonarqube account notifications? - notifications

Question

I installed a Sonarqube webapp to control code quality in my company.
I use LDAP plugin to authenticate users and everything works fine.
Moreover, we use another plugin (Issue assign plugin) which assign issues to their SCM authors and send emails to them so that they can correct the code.
However, when a new user logs in, notifications are off.
We'd like to create a batch which would turn notifications on for all users (using mass update whatsoever) but we can not locate where user account's notifications are stored ...
I didn't find it in the database.
Have you an idea of where this setting is stored ? (We use Sonarqube 4.5.6 for compatibility issues).

Answer 1

You cannot subscribe someone else to SonarQube spam notifications.
(This should be one of the things you see Bart Simpson writing on the blackboard.)
You must convince them to subscribe themselves.
SonarQube is a tool first and foremost for developers. Shove something down a developer's throat/inbox and you it will quickly be filtered to the trash.
This is your opportunity to train new developers on how SonarQube helps them be better at their jobs and show them why they should be interested enough to subscribe on their own.

Answer 2

We back our instance with an Oracle database, and found the following sql to do exactly what you're asking:
Note: You'll probably want to update the created_at value to something else, but I don't think it'll make a functional difference.
INSERT INTO properties (id, user_id, prop_key, text_value, is_empty, created_at)
SELECT
PROPERTIES_SEQ.nextval,
users.id,
'notification.SQ-MyNewIssues.EmailNotificationChannel',
'true',
0,
1505275000000
FROM
users
WHERE
users.id NOT IN (
SELECT user_id
FROM properties
WHERE prop_key = 'notification.SQ-MyNewIssues.EmailNotificationChannel');
INSERT INTO properties (id, user_id, prop_key, text_value, is_empty, created_at)
SELECT
PROPERTIES_SEQ.nextval,
users.id,
'notification.ChangesOnMyIssue.EmailNotificationChannel',
'true',
0,
1505275000000
FROM
users
WHERE
users.id NOT IN (
SELECT user_id
FROM properties
WHERE prop_key = 'notification.ChangesOnMyIssue.EmailNotificationChannel');
I tried to combine the two at some point, but the sql got too complicated. Easy enough to just copy-paste.
G. Ann is correct in that users will create email filters because of the sheer bulk of notifications, especially if you turn them all on. However, sometimes managers want a unilateral solution, and if the product doesn't directly support it, you end up having to hack something together anyway.
I reckon that the incentive to filter emails would be a lot less if the information were consolidated into a rate-limited summary. I've got another stackoverflow post up about that specific scenario here: Can SonarQube notification email quantity be reduced via batching?