Content
View differences
Updated by Parimal Satyal almost 4 years ago
**As** a project member
**I want to** see at least one high-level reason for a why I am receiving a notification
**so that** I can evaluate its importance in relation to other notifications.
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/35007/content">
### **Acceptance criteria**
* The current format "x hours ago by {user}" is replaced by a more complete form where at least one activity is specified.
* The reason of the notification is shown in an abbreviated form that is structure like this:
* **Status** changed to **Closed** (and 2 others), 1 hour ago by [Niels Lindenthal](https://community.openproject.org/www.openproject.org).
* **Comment** added (and 1 other), 1 hour ago by [Niels Lindenthal.](https://community.openproject.org/www.openproject.org)
* **Description** changed 1 hour ago by [Niels Lindenthal](https://community.openproject.org/www.openproject.org).
* **Subject** changed (and 4 others), 1 hour ago by [Niels Lindenthal.](https://community.openproject.org/www.openproject.org)
* In case of an aggregated journal entry, the reason to be displayed follows this order of priority (in descending order): order):
* **User is @mentioned in a comment**
* **Date alert** (open, position to be discussion)
* **Assigned to user**
* **Accountable set to user**
* **Removed as assignee**
* **Removed as accountable**
* **Status changed**
* **Date changed**
* **Priority changed**
* Version changed\*
* Subject changed\*
* Description changed\*
* **New comment(s)**
* **Assignee/Accountable changed (but not me)**
* Files added\*
* Custom fields changed\*
* Parent changed\*
* **\[open\]** Activities not in bold and marked an asterisk (\*) above currently do not generate a notification. Should these be added?
* The list of reasons to display is a closed set of events that the user has chosen to be notified about in their user settings. It might not include all of the reasons listed above:
* This means a lower-priority reason might actually be displayed instead of a higher priority one, if the user did not choose to be notified of that higher priority event. _Eg. if the user is has enabled notifications for "all date changes" and the work package has since also had a status change (but the user is not subscribed to these), the reason for notification remains the change of date._
* If the work package is watched, all events are reasons for notification, so the entire list should be considered.
* These settings must take project-level settings into account; _eg. a work package in project A might have a different set of reasons for notification as project B._
* If the notification row aggregates multiple notifications, the change highest up in above's priority list is chosen.
* The details are displayed in the same way within each row of a reminder mail.
### **Detail Strings**
_Notes_
* Brevity is prioritised so additional information is only provided where judged critical
* {time} is expressed relatively, as in "3 hours ago"
* {user} is expressed as a link
* The **parts in bold** are meant to really be in bold
* The additional "(and {n} others)" or "and 1 other") is not included in these examples, but they would be present where relevant.
#### Strings (in order of priority)
* _Comment with @mention_
**Mentioned** {time} by {user}
* _Assigned to me_
**Assigned to you** {time} by {user}
* _Accountable set to me_
**Accountable set to you** {time} by {user}
* _Assignee changed (from me to someone else)_
**Removed as assignee** {time} by {user}
* _Accountable changed (from me to someone else)_
**Removed as accountable** {time} by {user}
* _Status changed_
**Status changed** to {new status} {time} by {user}
* _Priority changed_
**Priority changed** to {new priority} {time} by {user}
* _Version changed_
**Version changed** to {new version} {time} by {user}
* _Date changed_
**Date changed** to {new date} {time} by {user}
* _Subject changed_
**Subject changed** {time} by {user}
* _Description changed_
**Description changed** {time} by {user}
* _New comment_
**New comment** {time} by {user}
* _Assigned changed (but unrelated to me)_
**Assignee changed** to {new user} {time} by {user}
* _Accountable changed (but unrelated to me)_
**Accountable changed** to {new user} {time} by {user}
* _Files added_
**New files added** {time} by {user}
* _Custom fields changed_
**{Custom field} updated** {time} by {user}
* _Parent changed_
**Parent changed** {time} by {user}
### Open questions (to be discussed)
* **\[open\]** Does the proposed priority order make sense (for aggregated journal entries)?
* **\[open\]** Does this syntax and phrasing work in other languages (need to test at least with DE, ES and FR)?
* The "and 2 others" bit is today appended at the end (eg. "_14 hours ago by Marc Alcobé and 2 others"_). However, this is confusing because it is unclear if "2 others" refers to two other users, or two other changes.
* To avoid the confusion, I propose "Status changed to X (and 2 others), 14 hours ago by Marc Alcobé" -- this way, we know that the 2 others refers to two other activities.
* **\[open\]** Is the list of reasons for notification exhaustive? What is missing?
* Missing because it generates a notification today for isn't on the list, or
* Mising because it doesn't curently geneate a notification but it _is_ on the list, or
* Missing because it is neither on this list nor does it currently generate a notification
* **\[open\]** We should surely update the notification card in the emails as well. Should we work on that in a separate ticket?
### **Out of scope**
* Date alerts (start or finish date approaching) remain a work in progress at the moment. We can add it to the list once they are finalised.
* To stay coherent with the syntax described above though, they would take this form:
* **Start date** is in {n} days
* **Finish date** is in {n} days
* ~~Change the details in the daily email (~~_~~described in~~ ~~#38948)~~_
**I want to** see at least one high-level reason for a why I am receiving a notification
**so that** I can evaluate its importance in relation to other notifications.
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/35007/content">
### **Acceptance criteria**
* The current format "x hours ago by {user}" is replaced by a more complete form where at least one activity is specified.
* The reason of the notification is shown in an abbreviated form that is structure like this:
* **Status** changed to **Closed** (and 2 others), 1 hour ago by [Niels Lindenthal](https://community.openproject.org/www.openproject.org).
* **Comment** added (and 1 other), 1 hour ago by [Niels Lindenthal.](https://community.openproject.org/www.openproject.org)
* **Description** changed 1 hour ago by [Niels Lindenthal](https://community.openproject.org/www.openproject.org).
* **Subject** changed (and 4 others), 1 hour ago by [Niels Lindenthal.](https://community.openproject.org/www.openproject.org)
* In case of an aggregated journal entry, the reason to be displayed follows this order of priority (in descending order):
* **User is @mentioned in a comment**
* **Date alert** (open, position to be discussion)
* **Assigned to user**
* **Accountable set to user**
* **Removed as assignee**
* **Removed as accountable**
* **Status changed**
* **Date changed**
* **Priority changed**
* Version changed\*
* Subject changed\*
* Description changed\*
* **New comment(s)**
* **Assignee/Accountable changed (but not me)**
* Files added\*
* Custom fields changed\*
* Parent changed\*
* **\[open\]** Activities not in bold and marked an asterisk (\*) above currently do not generate a notification. Should these be added?
* The list of reasons to display is a closed set of events that the user has chosen to be notified about in their user settings. It might not include all of the reasons listed above:
* This means a lower-priority reason might actually be displayed instead of a higher priority one, if the user did not choose to be notified of that higher priority event. _Eg. if the user is has enabled notifications for "all date changes" and the work package has since also had a status change (but the user is not subscribed to these), the reason for notification remains the change of date._
* If the work package is watched, all events are reasons for notification, so the entire list should be considered.
* These settings must take project-level settings into account; _eg. a work package in project A might have a different set of reasons for notification as project B._
* If the notification row aggregates multiple notifications, the change highest up in above's priority list is chosen.
* The details are displayed in the same way within each row of a reminder mail.
### **Detail Strings**
_Notes_
* Brevity is prioritised so additional information is only provided where judged critical
* {time} is expressed relatively, as in "3 hours ago"
* {user} is expressed as a link
* The **parts in bold** are meant to really be in bold
* The additional "(and {n} others)" or "and 1 other") is not included in these examples, but they would be present where relevant.
#### Strings (in order of priority)
* _Comment with @mention_
**Mentioned** {time} by {user}
* _Assigned to me_
**Assigned to you** {time} by {user}
* _Accountable set to me_
**Accountable set to you** {time} by {user}
* _Assignee changed (from me to someone else)_
**Removed as assignee** {time} by {user}
* _Accountable changed (from me to someone else)_
**Removed as accountable** {time} by {user}
* _Status changed_
**Status changed** to {new status} {time} by {user}
* _Priority changed_
**Priority changed** to {new priority} {time} by {user}
* _Version changed_
**Version changed** to {new version} {time} by {user}
* _Date changed_
**Date changed** to {new date} {time} by {user}
* _Subject changed_
**Subject changed** {time} by {user}
* _Description changed_
**Description changed** {time} by {user}
* _New comment_
**New comment** {time} by {user}
* _Assigned changed (but unrelated to me)_
**Assignee changed** to {new user} {time} by {user}
* _Accountable changed (but unrelated to me)_
**Accountable changed** to {new user} {time} by {user}
* _Files added_
**New files added** {time} by {user}
* _Custom fields changed_
**{Custom field} updated** {time} by {user}
* _Parent changed_
**Parent changed** {time} by {user}
### Open questions (to be discussed)
* **\[open\]** Does the proposed priority order make sense (for aggregated journal entries)?
* **\[open\]** Does this syntax and phrasing work in other languages (need to test at least with DE, ES and FR)?
* The "and 2 others" bit is today appended at the end (eg. "_14 hours ago by Marc Alcobé and 2 others"_). However, this is confusing because it is unclear if "2 others" refers to two other users, or two other changes.
* To avoid the confusion, I propose "Status changed to X (and 2 others), 14 hours ago by Marc Alcobé" -- this way, we know that the 2 others refers to two other activities.
* **\[open\]** Is the list of reasons for notification exhaustive? What is missing?
* Missing because it generates a notification today for isn't on the list, or
* Mising because it doesn't curently geneate a notification but it _is_ on the list, or
* Missing because it is neither on this list nor does it currently generate a notification
* **\[open\]** We should surely update the notification card in the emails as well. Should we work on that in a separate ticket?
### **Out of scope**
* Date alerts (start or finish date approaching) remain a work in progress at the moment. We can add it to the list once they are finalised.
* To stay coherent with the syntax described above though, they would take this form:
* **Start date** is in {n} days
* **Finish date** is in {n} days
* ~~Change the details in the daily email (~~_~~described in~~ ~~#38948)~~_