Support user notification preferences

[KrishnaIyer]

Summary

Support user notification preferences. Replaces https://github.com/TheThingsIndustries/lorawan-stack/issues/3280

Current Situation

Currently users receive emails for all notification types except collaborator_changed. We want to allow users to choose what kind of emails they receive.
All notifications are displayed in the console. So some users prefer to not receive emails

Why do we need this? Who uses it, and when?

We want to allow users to choose what kind of emails they receive.

Proposed Implementation

Backend

• Introduce a new Enum for NotificationType in the API. Currently we use hardcoded strings like user_requested or collaborator_changed in pkg/email/templates and when we use the CreateNotificationRequest message.
  • We need to do a replacement in all the places where this is used and also test that email templates are not affected by this.
• Introduce a NotificationPreferences message inside the User message.
  • This contains a single message repeated NotificationType email_notification_types. This is a list of NotificationType for which we would send emails.
  • This can be updated by the User based to select which notifications they want emails for. We need some validation to filter out duplicates.
  • There are special admin emails user_requested and client_requested, both of which require admin actions. These emails are very infrequent and should not be skipped. So the API should either ignore these enums or return a validation error.
• Add DB entries and migrations.
• Change the lookupNotificationReceivers function to return a second emailReceiverIDs argument. This is a filtered list of receiver IDs.
  • A receiver is placed in this list if the email notification type in req is allowed for the user in their preferences.
• In CreateNotification, call is.SendNotificationEmailToUserIDs only emailReceiverIDs is not empty.
• Deprecate the email field of the Notification message. We should instead get this from the user preferences
• Lots of unit and production testing

The backend needs to target the v3.33 branch since this requires a database migration.

UX

• Edit the /console/user-settings/profile view and rename it to Account or Preferences, whichever makes sense.
• Add a new "Email Notifications" section.
  • This contains a list of checkboxes, similar to choosing Rights on API keys. Example below
    
  • The options are the NotificationType enums.
  • We also somehow have an option to choose All or None.
  • Let's document here that emails that require admin actions such as approving users or OAuth clients cannot be skipped.
• Plug this page into the API above and test.

Contributing

• I can help by doing more research.
• I can help by implementing the feature after the proposal above is approved.
• I can help by testing the feature before it's released.

Validation

• The feature is tested in a staging environment.
• The feature is documented in The Things Stack Documentation

Code of Conduct

• I agree to follow TTN's Community Code of Conduct.

[KrishnaIyer]

@nicholaspcr: Please let me know if the backend part makes sense?

@pierrephz: Can you think of a draft wireframes for the UX? Please ping me if you have doubts.

[nicholaspcr]

@nicholaspcr: Please let me know if the backend part makes sense?

Looks pretty good to me but I do have a question, would it be more efficient to have a NotificationsFilters instead of NotificationsPreferences? That way what we are storing on the user are only the notification types which have to be filtered.

Additionally I believe its easier for users to set what they don't want rather than the opposite.

[KrishnaIyer]

Looks pretty good to me but I do have a question, would it be more efficient to have a NotificationsFilters instead of NotificationsPreferences? That way what we are storing on the user are only the notification types which have to be filtered.

The question here is the difference of what the default behavior is,
a. Do users receive all emails by default and they choose what not to receive? (OR)
b. Do users receive no emails by default and they can enable it for certain ones?

User experience-wise, (b) is better since all notifications are available in the Console by default.

[ryaplots]

@KrishnaIyer @nicholaspcr @pierrephz Considering that user_requested and client_requested require admin actions, they should be selected by default and the de-selection should be disabled in the UI. There should also be a message there saying that these require user action and that they are infrequent, so they cannot be opted out of. What do you think?
For the backend, I am not sure if it's best to ignore these or return an error. I would say error. In case one of these gets through, then it's nice to have some kind of feedback. Have them as "not allowed" options.

[KrishnaIyer]

Considering that user_requested and client_requested require admin actions, they should be selected by default and the de-selection should be disabled in the UI.

I would say let's show it in a non-editable state in the console for admins only. For the API, I think we should just ignore this if it's set in the filters.