Content
View differences
Updated by Attila Dombi over 1 year ago
**As** a user
**I want to** receive separate notifications for **"mention"** and **"accountable"** statuses within the same aggregation window when:
* I am **accountable**, and something changes on the work package,
**AND**
* I am also **mentioned** in a comment on the same work package.
**so that** I don't miss important notifications about changes to the work package even if I’m also mentioned in a comment during the same time frame.
### **Acceptance criteria**
1. **Multiple Notifications within the same Aggregation Window**
The system should allow multiple notifications for the same work package within the same aggregation window.
2. **No Duplicate Notifications**
Notifications should be created **1** **per notification event**, ensuring that users won't get flooded with notifications. ie: If the user is **accountable** and also being mentioned in a work package, only a **mentioned** notification should be created without the extra **accountable** notification.
3. **Priority of Notification Reasons to avoid Duplicates**
In step 2, when creating a notification and avoiding duplicates, the system should choose the notification reason based on the existing priority list:
1. **Mentioned** (Highest)
2. **Assignee**
3. **Accountable**
4. **Watcher** (Lowest)
4. **Additional change triggers separate Notification**
If any additional change happens on the work package (e.g., description is updated) during the same aggregation window, a separate notification should be created, if the type of notification does not already exist.
ie: The user is an **assignee** that has a **mentioned** notification from step 2. If the work package description is changed, now the user also receives an **assignee** notification too, while keeping the **mentioned** notification intact.
5. **Marking Notifications read per Reason**
In step 4, when both a **mentioned** and **assignee** notification are present, marking one of them as read should leave the other notification unread. This ensures that no important update is dismissed unintentionally.
6. **Overwriting Notifications within the same Aggregation Window**
If a user receives an a **mentioned** or **assignee** notification, subsequent notifications of the same reason (within the aggregation window) should **overwrite** the existing notification rather than create a new one.
The only exception about this rule is the **mentioned** notification, each mention has to generate a notification, not overwriting any previous mentions.
### Examples/Scenarios
* **Scenario 1: User is Mentioned and Accountable**
* **Initial event**: User is mentioned in a comment on the work package while also being accountable.
* **Result**: Only a **mention** notification is created, not an **accountable** notification.
* **Scenario 2: Additional Change to Work Package**
* **Subsequent event**: The work package’s description is changed within the same aggregation window.
* **Result**: An **assigned** notification is created, distinct from the prior **mentioned** notification.
* **Scenario 3: Additional User mentioning happens**
* **Subsequent event:** The user is mentioned in another comment on the same work package, same aggregation window.
* **Result:** The initial mentioned notification is being replaced by the **new** mentioned notification.
The proposed idea of changing the notification behaviour stems from ##58015 .
**I want to** receive separate notifications for **"mention"** and **"accountable"** statuses within the same aggregation window when:
* I am **accountable**, and something changes on the work package,
**AND**
* I am also **mentioned** in a comment on the same work package.
**so that** I don't miss important notifications about changes to the work package even if I’m also mentioned in a comment during the same time frame.
### **Acceptance criteria**
1. **Multiple Notifications within the same Aggregation Window**
The system should allow multiple notifications for the same work package within the same aggregation window.
2. **No Duplicate Notifications**
Notifications should be created **1** **per notification event**, ensuring that users won't get flooded with notifications. ie: If the user is **accountable** and also being mentioned in a work package, only a **mentioned** notification should be created without the extra **accountable** notification.
3. **Priority of Notification Reasons to avoid Duplicates**
In step 2, when creating a notification and avoiding duplicates, the system should choose the notification reason based on the existing priority list:
1. **Mentioned** (Highest)
2. **Assignee**
3. **Accountable**
4. **Watcher** (Lowest)
4. **Additional change triggers separate Notification**
If any additional change happens on the work package (e.g., description is updated) during the same aggregation window, a separate notification should be created, if the type of notification does not already exist.
ie: The user is an **assignee** that has a **mentioned** notification from step 2. If the work package description is changed, now the user also receives an **assignee** notification too, while keeping the **mentioned** notification intact.
5. **Marking Notifications read per Reason**
In step 4, when both a **mentioned** and **assignee** notification are present, marking one of them as read should leave the other notification unread. This ensures that no important update is dismissed unintentionally.
6. **Overwriting Notifications within the same Aggregation Window**
If a user receives an
The only exception about this rule is the **mentioned** notification, each mention has to generate a notification, not overwriting any previous mentions.
### Examples/Scenarios
* **Scenario 1: User is Mentioned and Accountable**
* **Initial event**: User is mentioned in a comment on the work package while also being accountable.
* **Result**: Only a **mention** notification is created, not an **accountable** notification.
* **Scenario 2: Additional Change to Work Package**
* **Subsequent event**: The work package’s description is changed within the same aggregation window.
* **Result**: An **assigned** notification is created, distinct from the prior **mentioned** notification.
* **Scenario 3: Additional User mentioning happens**
* **Subsequent event:** The user is mentioned in another comment on the same work package, same aggregation window.
* **Result:** The initial mentioned notification is being replaced by the **new** mentioned notification.
The proposed idea of changing the notification behaviour stems from ##58015 .