versio | comment |
|---|---|
11/24/2021 | Added this tracking table |
06/15/2020 | Created |
Use cases: Annual Renewal
JIRA:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
Introduce two new fields in a ManagedACTAccessRequirement model object:
datasetName (String): Optional filed that will be used as a friendly label when sending notifications, and could be used when showing the AR
renewalDetailsUrl (String → parsed as a URL): An optional URL with additional instructions for the renewal notifications
Include in the AccessorGroup model object the information about the notifications through a new field:
notifications: A list of notifications sent for the accessor group, the model of each item in the list would contain information about the notification that are scheduled/sent.
Notification:
field | type | description |
|---|---|---|
accessRequirementId | String | The id of the AR |
submitterId | String | The id of the submitter |
recipientId | String | The id of the user where the notification was sent to |
type | enum<NotificationType> | The type of notification: RENEWAL_NOTIFICATION, REVOKE_NOTIFICATION |
status | enum<NotificationStatus> | The status of the notification: SCHEDULED, SENT |
Note that the AccessorGroup is an object computed from a grouping by AR and Submitter, the notifications will be computed and included accordingly.
...
DATA_ACCESS_NOTIFICATIONS (omits std fields, id etag, created_on etc)
field | description |
|---|---|
ACCESS_REQUIREMENT_ID | The id of the AR |
SUBMITTER_ID | The id of the submitter |
STATUS | The status of the notification: SCHEDULED/SENT |
TYPE | The type of the notification: RENEWAL_NOTIFICATION/REVOKE_NOTIFICATION |
TIMESTAMP | The time when the notification should be sent |
RECIPIENT_ID | The id of the user that is the target of the notification (this is the same as the submitter for renewals, while the accessor id for revocations) |
With this table in place we can introduce a worker that process the scheduled renewals notifications. Note that we cannot reuse the change message machinery since there is no object type that actually changes (and for an AccessorGroup a notification applies to a dynamic group that is defined by the submitter/ar tuple).
...
Since the messages need to be delivered despite the user notification settings we need a way to override this behavior, for example adding a new column in the MESSAGE_TO_USER table:
field | description |
|---|---|
OVERRIDE_NOTIFICATION_SETTING | A flag that defines if the message should be sent despite the notification setting of the recipient. |
To build the email body itself we will reuse the current velocity templating engine and the content will be built according to the configuration of the AR with an end result that should resemble the canned language used in this document: Renewal Process and Canned Language.
...