Filter Mail notifications

[kamil386]

Do you have any plans to support filtering the mail type notifications? We would like to filter which type of mail notifications should be send to the users, i.e only related to password recovery, email dataset contact and at most publish new dataset action. Our documentalists generates hundreds or even thousands of emails per day, which is annoying (Dataverse generates notification for every single operation to all users in Dataverse group).

[pdurbin]

@kamil386 thanks for reporting this issue. These issues seem related:

• Notifications: send only one notification for each "batch" request access Notifications: send only one notification for each "batch" request access #2891
• Notifications: In some cases, users receive more than one notification for a single event, eg. request access. Notifications: In some cases, users receive more than one notification for a single event, eg. request access. #4120

@mheppler made a nice summary of open issues a while back at #1336 (comment)

I'm not aware of any plans to support filtering but it's a good idea. In general, notifications could use some re-tooling.

[meghangoodchild]

We've also received feedback that the number of notifications is quite high for Dataverse collection admins, especially after recently upgrading and turning on the dataset created notification. While some users find it very helpful, others are inundated with emails/UI notifications.

From our perspective, it doesn't seem to make sense to enable or disable these notifications at the installation level. Users should be able to configure which notifications to receive (e.g., submit for review, dataset created, restricted file access, etc) and the type of notifications (i.e., email/UI). Essentially, users should be able to enable or disable in their settings. Hope this is helpful feedback!

[DieuwertjeBloemen]

Hi all,

Eryk and I have been looking at the option to customize your notifications and emails as this is something we would want in our (KU Leuven RDR) installation and it’s something that has been mentioned before by others in the community.

In Eryk’s screenshot in #8530, you can get a first idea of how notifications can be turned on or off by users in our current testing set-up.
We’ve been discussing it a bit more, and we wanted input from others on whether they should be able to truly customize it notification per notification or whether installations should provide users with some basic settings, or maybe even another set-up would be better. Here are some suggestions that we came up with for now:

Scenario 1: Leave it all up to the users. They are able to mute each notification and email separately.

Scenario 2: Only allow users to choose between ‘all notifications’ and ‘essential notifications’ (e.g. access request notifications and API token expiration notifications), with the admin then being able to decide what ‘essential notifications’ are for the dataverse via the admin dashboard or via API.

Scenario 3: The feature is only manageable from the admin level and not up to the users individually. Users don’t have any choice and the admin decides for the entire dataverse what the notifications are that a user receives for datasets in that dataverse.

Please provide us with some input and maybe further suggestions as we continue to work on this feature to make it a bit more user friendly.

Dieuwertje

[jggautier]

Hi @DieuwertjeBloemen. I'm just writing to share a spreadsheet describing the notifications that the Dataverse software sends users.

It's probably missing notifications. I haven't had time to continue updating it since it was started in the summer of 2018. But I'm sharing it just in case it's helpful as you consider the experience different types of users have with all of these automated emails. Thanks!

[eunices]

Adding related issues: #8375 & #8375

[ErykKul]

Hello,

These are the notifications as used by the system (in bundle.propeties):

Set notification.showMuteOptions to false to disable muting options:
notification.showMuteOptions=true

notification.mutedEmails=Muted email notification types
notification.mutedNotifications=Muted notification types

notification.typeDescription.ASSIGNROLE=role is assigned
notification.typeDescription.REVOKEROLE=role is revoked
notification.typeDescription.CREATEDV=dataverse is created
notification.typeDescription.CREATEDS=your dataset is created
notification.typeDescription.CREATEACC=account is created
notification.typeDescription.SUBMITTEDDS=submitted for review
notification.typeDescription.RETURNEDDS=returned from review
notification.typeDescription.PUBLISHEDDS=dataset is published
notification.typeDescription.REQUESTFILEACCESS=access to file is requested
notification.typeDescription.GRANTFILEACCESS=access to file is granted
notification.typeDescription.REJECTFILEACCES=access to file is rejected
notification.typeDescription.FILESYSTEMIMPORT=dataset has been successfully uploaded and verified
notification.typeDescription.CHECKSUMIMPORT=dataset had file checksums added via a batch job
notification.typeDescription.CHECKSUMFAIL=checksum validation failed
It could be counter-productive to mute this one (email could not be verified), it is skipped (not selectable by the user) by leaving the description empty:
notification.typeDescription.CONFIRMEMAIL=
notification.typeDescription.APIGENERATED=API token is generated
notification.typeDescription.INGESTCOMPLETED=ingest is completed
notification.typeDescription.INGESTCOMPLETEDWITHERRORS=ingest completed with errors
notification.typeDescription.PUBLISHFAILED_PIDREG=publish has failed
notification.typeDescription.WORKFLOW_SUCCESS=external workflow run has succeeded
notification.typeDescription.WORKFLOW_FAILURE=external workflow run has failed
notification.typeDescription.STATUSUPDATED=status of dataset has been updated
notification.typeDescription.DATASETCREATED=dataset was created by user

The pull request is in between the scenario 1 and the scenario 2. You can decide for each installations which notifications are essential by leaving the descriptions empty (they become not selectable by users for muting). You can also turn off the feature by setting the corresponding boolean notification.showMuteOptions to false. If the feature is active, the users can turn off all non-essential notifications at once. or pick the ones they want to mute from the list. In-app notifications are separately mutable from the email notifications. This is how it looks like from the user perspective:

Greetings,
Eryk

[DieuwertjeBloemen]

@jggautier, thanks for the spreadsheet. It's a great starting place to get a good view on which notifications or mails we might need to make configurable or take a closer look at.
I think our next step is to gather as much input as possible with use cases and wants/wishes from other intstallations so we can make the system as universal as possible. Because maybe what would work for us isn't enough or ideal for other installations.

[ErykKul]

I have added the support for the third scenario: you can set notification.alwaysMuted in bundle.properties to permanently mute certain notification types, where users cannot unmute them, e.g. notification.alwaysMuted=ASSIGNROLE, REVOKEROLE. This can be used in combination with scenario 1/2 (additional non-essential notifications being controlled by the user where essential notifications are always on) or with notification.showMuteOptions set to false (user cannot mute or unmute any notifications). I think this covers most cases now.