Content
View differences
Updated by Niels Lindenthal over 1 year ago
**As a** project member
**I want to** add internal/confidential comments to work package comments with restricted visibility packages
**So that I** can add context information that I only share with a subgroup of certain people. So the information is not shared with all project member and non members. people (and that I know that it remains internal)
### **Acceptance criteria**
* Administration: there are new role permissions:
* View confidential note
* Write confidential note
* Edit own confidential notes
* Edit others' confidential notes (for moderation)
* When I write a comment, I can choose to make it confidential
* When I make my comment confidential (via a checkbox, for example), show a note that makes it clear what this means (i.e, that its visibility is limited to users with the requisite permissions)
* There is a link that lets the user view _who_ can view these restricted comments.
* This will take the user to the Members page of that project with the 'View confidential note' permission filter enabled. (This feature does not yet exist, we'll create a ticket for it).
* There should be a strong visual code that reassures me that my comment _will_ in fact be confidential, to avoid any chance that I accidentally write a confidential comment publicly.
* If a note is confidential, it is easily distinguishable from other comments (that are public) so I can be reassured that a comment is indeed confidential
* The comment should appear in a different background colour
* There should be a lock icon
* Hovering on the lock icon (on non-mobile screens) should display a tooltip: "Only visible to certain members. Click for more info."
* Clicking on this lock icon will take the user to the Members page of that project with the 'View confidential note' permission filter enabled.
* Quoting is possible. However, when quoting a confidential note, that note must also be confidential (the toggle/checkbox is on and disabled)
* The "Show everything" view filter on the top right has two additional options:
* "Confidential notes only"
* "Show everything publicly visible"
* Notifications: Confidential notes will also appear in the notification center just like comments if I have access to them
* Same with email notifications
* It should not be possible to @mention users who will not be able to view the confidential note (i.e, the drop-down needs to exclude users without the requisite permissions)
* There is no visible numbering of activity comments anymore, even for non-restricted comments.
* Ideally, old links with `#activity-<comment-number>` still work.
* Copying the URL of a comment will have a new URL scheme including a real, persistent ID and not a generated number anymore so that it stays the same even when other comments are added or removed from the activity, e.g. #comment-<journal-id>
* When that URL is opened the browser will auto-scroll to have the comment in the visible viewport.
* When there is not Enterprise token, or the token does not allow this feature:
* We still show the permissions in the role administration and leave them editable.
* We don't show the toggle/checkbox to make a new comment a restricted comment.
* We show a banner at the project setting for enabling the feature.
* Confidential notes can be enabed/disabled at a project level
* \[Project settings to be determined\]
### Open questions
* ~~\[open\] We remove IDs on comments so we don't have to deal with parallel set of numbers for comments and confidential notes.~~
* ~~The idea is to do it a bit like how GitHub does it, which is a cleaner interface~~
* ~~Need to figure out how to link to existing comments~~
* \[open\] Data model: confidential notes are both like comments (in structure) but have special permissions and visibility attached to them
* ~~\[open\] Do we provide additional hints about who can see the message?~~
* ~~Can we produce a list of all members (in the project) who have a certain permission (via their roles)? The idea would be to be able to display who exactly can see the confidential comment.~~
* \[open\] There is a project setting to enable or disable confidential notes.
* Eg. public projects can have it enabled by default, private projects can have them disabled by default.
* Migration: what if a work package is moved from a project that has confidential notes enabled to one that has it disabled?
* Proposition: Information cannot be lost, perhaps display existing but not allow the creation of new until feature is enabled in project?
* ~~\[open\] There is a role permission group "Confidential notes" that, when enabled, enables all confidential features (read/write/edit).~~
* \[open\] In what Enterprise plan will this feature be included?
* \[open\] <mention class="mention" data-id="72513" data-type="user" data-text="@Parimal Satyal">@Parimal Satyal</mention>, we need to define the upsale banners.
* \[open\] How do Out of scope
* The ability to specify a custom scope per confidential note (eg. selecting individual users or groups)
### Naming
Please see open point: ###60852
<br>
### **Example use case:**
* A client or partner should have access to a work package to collaborate closely. However this partner should not have access to all information.
**I want to** add
**So that I** can add context information that I only share with a subgroup of certain people. So the information is not shared with all project member and non members.
### **Acceptance criteria**
* Administration: there are new role permissions:
* View confidential note
* Write confidential note
* Edit own confidential notes
* Edit others' confidential notes (for moderation)
* When I write a comment, I can choose to make it confidential
* When I make my comment confidential (via a checkbox, for example), show a note that makes it clear what this means (i.e, that its visibility is limited to users with the requisite permissions)
* There is a link that lets the user view _who_ can view these restricted comments.
* This will take the user to the Members page of that project with the 'View confidential note' permission filter enabled. (This feature does not yet exist, we'll create a ticket for it).
* There should be a strong visual code that reassures me that my comment _will_ in fact be confidential, to avoid any chance that I accidentally write a confidential comment publicly.
* If a note is confidential, it is easily distinguishable from other comments (that are public) so I can be reassured that a comment is indeed confidential
* The comment should appear in a different background colour
* There should be a lock icon
* Hovering on the lock icon (on non-mobile screens) should display a tooltip: "Only visible to certain members. Click for more info."
* Clicking on this lock icon will take the user to the Members page of that project with the 'View confidential note' permission filter enabled.
* Quoting is possible. However, when quoting a confidential note, that note must also be confidential (the toggle/checkbox is on and disabled)
* The "Show everything" view filter on the top right has two additional options:
* "Confidential notes only"
* "Show everything publicly visible"
* Notifications: Confidential notes will also appear in the notification center just like comments if I have access to them
* Same with email notifications
* It should not be possible to @mention users who will not be able to view the confidential note (i.e, the drop-down needs to exclude users without the requisite permissions)
* There is no visible numbering of activity comments anymore, even for non-restricted comments.
* Ideally, old links with `#activity-<comment-number>` still work.
* Copying the URL of a comment will have a new URL scheme including a real, persistent ID and not a generated number anymore so that it stays the same even when other comments are added or removed from the activity, e.g. #comment-<journal-id>
* When that URL is opened the browser will auto-scroll to have the comment in the visible viewport.
* When there is not Enterprise token, or the token does not allow this feature:
* We still show the permissions in the role administration and leave them editable.
* We don't show the toggle/checkbox to make a new comment a restricted comment.
* We show a banner at the project setting for enabling the feature.
* Confidential notes can be enabed/disabled at a project level
* \[Project settings to be determined\]
### Open questions
* ~~\[open\] We remove IDs on comments so we don't have to deal with parallel set of numbers for comments and confidential notes.~~
* ~~The idea is to do it a bit like how GitHub does it, which is a cleaner interface~~
* ~~Need to figure out how to link to existing comments~~
* \[open\] Data model: confidential notes are both like comments (in structure) but have special permissions and visibility attached to them
* ~~\[open\] Do we provide additional hints about who can see the message?~~
* ~~Can we produce a list of all members (in the project) who have a certain permission (via their roles)? The idea would be to be able to display who exactly can see the confidential comment.~~
* \[open\] There is a project setting to enable or disable confidential notes.
* Eg. public projects can have it enabled by default, private projects can have them disabled by default.
* Migration: what if a work package is moved from a project that has confidential notes enabled to one that has it disabled?
* Proposition: Information cannot be lost, perhaps display existing but not allow the creation of new until feature is enabled in project?
* ~~\[open\] There is a role permission group "Confidential notes" that, when enabled, enables all confidential features (read/write/edit).~~
* \[open\] In what Enterprise plan will this feature be included?
* \[open\] <mention class="mention" data-id="72513" data-type="user" data-text="@Parimal Satyal">@Parimal Satyal</mention>, we need to define the upsale banners.
* \[open\] How do Out of scope
* The ability to specify a custom scope per confidential note (eg. selecting individual users or groups)
### Naming
Please see open point: ###60852
<br>
### **Example use case:**
* A client or partner should have access to a work package to collaborate closely. However this partner should not have access to all information.