You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, administrators are notified by email when certain events in the system occur.
The setting EMAIL_ADMIN_LIST defines a list of admin emails, which in practice tends to be used when requests are created by users (e.g., a new project request has been created, a new cluster account request has been created, etc.).
Additionally, there are two settings defining lists of admins to notify when requests are processed. These are special cases, as admins are typically the ones doing the processing and would not therefore need to be notified:
REQUEST_APPROVAL_CC_LIST: a list of admin emails to CC on the email received by users when a new project request or allowance renewal request is approved, denied, or processed, though the name does not make this clear
PROJECT_USER_REMOVAL_REQUEST_PROCESSED_EMAIL_ADMIN_LIST: a list of admin emails to notify when a ProjectUser has been removed from a project (this is being added in a PR at the time of this writing)
Two issues:
Not all admins may necessarily wish to be notified of all events that currently reference EMAIL_ADMIN_LIST.
As the number of events grow, the number of settings for special cases (like the two above) may also grow, along with associated code.
Describe the solution you'd like
Ideally, admin A should be able to choose (not necessarily from the front end) what set of events they are interested in being notified about, and admin B should be able to choose a different set.
There'd be a list of events, and a dynamic mapping from event type to the set of admins subscribed to that event type. This mapping would live in the database(?) as opposed to static configuration. When an event E occurs, only those subscribed to E are notified.
The settings above would be retired.
Describe alternatives you've considered (Optional)
Additional context (Optional)
Consider whether this subscription functionality is relevant to users. What notifications might we want to let them unsubscribe from, if any?
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, administrators are notified by email when certain events in the system occur.
The setting
EMAIL_ADMIN_LIST
defines a list of admin emails, which in practice tends to be used when requests are created by users (e.g., a new project request has been created, a new cluster account request has been created, etc.).Additionally, there are two settings defining lists of admins to notify when requests are processed. These are special cases, as admins are typically the ones doing the processing and would not therefore need to be notified:
REQUEST_APPROVAL_CC_LIST
: a list of admin emails to CC on the email received by users when a new project request or allowance renewal request is approved, denied, or processed, though the name does not make this clearPROJECT_USER_REMOVAL_REQUEST_PROCESSED_EMAIL_ADMIN_LIST
: a list of admin emails to notify when aProjectUser
has been removed from a project (this is being added in a PR at the time of this writing)Two issues:
EMAIL_ADMIN_LIST
.Describe the solution you'd like
Ideally, admin A should be able to choose (not necessarily from the front end) what set of events they are interested in being notified about, and admin B should be able to choose a different set.
There'd be a list of events, and a dynamic mapping from event type to the set of admins subscribed to that event type. This mapping would live in the database(?) as opposed to static configuration. When an event
E
occurs, only those subscribed toE
are notified.The settings above would be retired.
Describe alternatives you've considered (Optional)
django-activity-stream
: https://github.com/justquick/django-activity-streamdjango-notifications
: https://github.com/django-notifications/django-notificationsAdditional context (Optional)
Consider whether this subscription functionality is relevant to users. What notifications might we want to let them unsubscribe from, if any?
The text was updated successfully, but these errors were encountered: