Content
View differences
Updated by Parimal Satyal over 1 year ago
**As a** project member
**I want to** add internal/confidential comments to work packages
**So that I** can add context information that I only share with certain people (and that I know that it remains internal)
### **Acceptance criteria**
* Administration: there are new role permissions:
* View confidential note comments
* Write confidential note comments
* Edit own confidential notes comments
* Edit others' confidential notes comments (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 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 and the label "confidential" should be clearly present
* Quoting is possible. However, when quoting a confidential note, that note must also be confidential (the toggle/checkbox is on and deactivated).
* The "Show everything" view filter on the top right has two additional options:
* "Confidential notes only"
* "Hide confidential notes" or "Show public activity only"
* 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 dropdown needs to exclude users without the requisite permissions)
<br>
### 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 visbility 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\] New project settings:
* New entry: "Communications"?
* Private notes enabled by default for private projects/disabled for public ones
### Out of scope
* The ability to specify a custom scope per confidential note (eg. selecting individual users or groups)
### Phrasing and translation
Preferred term in English: **Confidential**. **Confidential**.
Unlike "private", which can imply something personal and thus could potentially be understood as something personal and possibly even unrelated to work, "confidential" implies that the subject matter is not to be disclosed outside of a certain context.
(Other alternatives that were considered: Private, Internal, Restricted)
<figure class="table op-uc-figure_align-center op-uc-figure" style="height:47.9948px;width:100%;"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">English (source)</p></th><th class="op-uc-table--cell op-uc-table--cell_head" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">German</p></th><th class="op-uc-table--cell op-uc-table--cell_head" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">French</p></th><th class="op-uc-table--cell op-uc-table--cell_head" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">Spanish</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Comments</p></th></tr></thead><tbody><tr class="op-uc-p">Spanish</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">Confidential note</p></td><td class="op-uc-table--cell" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p"><br></p></td><td class="op-uc-table--cell" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">Note confidentielle</p></td><td class="op-uc-table--cell" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p"><br></p></td><td class="op-uc-table--cell"><p class="op-uc-p">More distinguishing from "comment" (as a verb, especially). Not bad, potential option. </p><p class="op-uc-p">Also have to think about it from the larger POV of a larger idea of notes we can attach to other things.</p></td></tr><tr class="op-uc-p"><br></p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell" style="width:19.8263%;"><p class="op-uc-p">Confidential comment</p></td><td class="op-uc-table--cell" style="width:19.8263%;"><p class="op-uc-p"><br></p></td><td class="op-uc-table--cell" style="width:19.8263%;"><p class="op-uc-p">Commentaire confidentiel </p></td><td class="op-uc-table--cell" style="width:19.8263%;"><p class="op-uc-p"><br></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Continuity, variation of comment (of a different kind)</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><br></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br></p></td><td class="op-uc-table--cell"><p class="op-uc-p"><br></p></td></tr></tbody></table></figure>
###
### **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 internal/confidential comments to work packages
**So that I** can add context information that I only share with certain 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
* 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 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
* Quoting is possible. However, when quoting a confidential note, that note must also be confidential (the toggle/checkbox is on and deactivated).
* The "Show everything" view filter on the top right has two additional options:
* "Confidential notes only"
* "Hide confidential notes" or "Show public activity only"
* 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 dropdown needs to exclude users without the requisite permissions)
<br>
### 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 visbility 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\] New project settings:
* New entry: "Communications"?
* Private notes enabled by default for private projects/disabled for public ones
* The ability to specify a custom scope per confidential note (eg. selecting individual users or groups)
### Phrasing and translation
Preferred term in English: **Confidential**.
Unlike "private", which can imply something personal and thus could potentially be understood as something personal and possibly even unrelated to work, "confidential" implies that the subject matter is not to be disclosed outside of a certain context.
(Other alternatives that were considered: Private, Internal, Restricted)
<figure class="table op-uc-figure_align-center op-uc-figure" style="height:47.9948px;width:100%;"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">English (source)</p></th><th class="op-uc-table--cell op-uc-table--cell_head" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">German</p></th><th class="op-uc-table--cell op-uc-table--cell_head" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">French</p></th><th class="op-uc-table--cell op-uc-table--cell_head" style="height:23.9974px;width:19.8263%;"><p class="op-uc-p">Spanish</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Comments</p></th></tr></thead><tbody><tr
* A client or partner should have access to a work package to collaborate closely. However this partner should not have access to all information.