Content
View differences
Updated by Wieland Lindenthal over 1 year ago
The current scope of the EPIC is to allow use cases that are typical for a help desk scenario where a team is dealing with a wider audience.
What is a internal team and what is the wider audience might be different for every project. For example, on community our wider audience is different to a non-public project that we have with our clients. There the clients are the wider audience. Or in a HR project of a certain employee the employee itself might be wider audience while the HR team the internal team.
The internal team needs to
* communicate **internally**,
* sharing **confidential** information that is not meant to be shared with the wider audience.
* The **visibility** of such comments needs to be **restricted**.
In a future scope we also want to add the ability to have **private** communication to an even smaller and maybe selected group of people.
The current help desk feature scope divides all users into two categories, the internal team and the others. While **private** communication has infinite possible groups of people. So with the outlook of restricting the visibility of other parts we might want to look into the future for a moment and consider the naming of stuff.
For example, if I create a **private** Thread and I just want to communicate with one selected person only, then I would invite that person to that chat. Or I would **share** that Thread with that person.
That private Thread probably needs some sort of indication of being **private.** And with whom I have shared it with. Then the Thread's visibility is limited to two people.
A **lock icon** could be applied to private Threads that I have shared but also for internal help desk comments.
* In a private Thread: 🔒Max Mustermann, Steffi Stamm
* In a confidential help desk comment: 🔒Support staff
The problem here with the second case is that "Support staff" can be something different in every project, maybe is it "Support staff", maybe "HR Team".
That indicates into the direction that we share a comment with either multiple people or multiple groups. And the groups are cut differently per project.
**Option 1 "Restricted visibility"**
For the current scope we do not care too much about the private Thread scenario. Simply say
* **Restricted visibility** and the action would be **Restrict visibilit**y
Observation:
* If it is just this feature and will not get more complex, "Confidential" seems to me the better word. And it is shorter. But that is not a big issue.
**Option 2: "Restrict visibility to X(, Y, and Z)"**
"Restrict visibility to: \[some multi-select drop-down\]" and that drop down includes
* Internal team (reflected by permissions gained via project roles)
* Selected people or groups (sharing with direct people and groups)
* Selected project roles (shared with dynamically created groups that are defined by memberships having certain roles)
Observations
* Very flexible
* No clear default
* Complex to build
* Uncertain if we really want that in the future like that.
* Naming of these dynamic groups and differentiating them is also hard.
**Option 3: Differentiate between two different concepts "Confidential" and "Private"**
* Confidential (reflected by permissions gained via project roles)
* Private (shared)
Observations:
* Complex to explain
* But clearer to distinguish
* Seems to be mutually exclusive which seems to be limiting
* Unlikely that we ever want to have private comments IN(!) the Activity. Private things are more likely just attached/pinned to other things.
<br>
What is a internal team and what is the wider audience might be different for every project. For example, on community our wider audience is different to a non-public project that we have with our clients. There the clients are the wider audience. Or in a HR project of a certain employee the employee itself might be wider audience while the HR team the internal team.
The internal team needs to
* communicate **internally**,
* sharing **confidential** information that is not meant to be shared with the wider audience.
* The **visibility** of such comments needs to be **restricted**.
In a future scope we also want to add the ability to have **private** communication to an even smaller and maybe selected group of people.
The current help desk feature scope divides all users into two categories, the internal team and the others. While **private** communication has infinite possible groups of people. So with the outlook of restricting the visibility of other parts we might want to look into the future for a moment and consider the naming of stuff.
For example, if I create a **private** Thread and I just want to communicate with one selected person only, then I would invite that person to that chat. Or I would **share** that Thread with that person.
That private Thread probably needs some sort of indication of being **private.** And with whom I have shared it with. Then the Thread's visibility is limited to two people.
A **lock icon** could be applied to private Threads that I have shared but also for internal help desk comments.
* In a private Thread: 🔒Max Mustermann, Steffi Stamm
* In a confidential help desk comment: 🔒Support staff
The problem here with the second case is that "Support staff" can be something different in every project, maybe is it "Support staff", maybe "HR Team".
That indicates into the direction that we share a comment with either multiple people or multiple groups. And the groups are cut differently per project.
**Option 1 "Restricted visibility"**
For the current scope we do not care too much about the private Thread scenario. Simply say
* **Restricted visibility** and the action would be **Restrict visibilit**y
Observation:
* If it is just this feature and will not get more complex, "Confidential" seems to me the better word. And it is shorter. But that is not a big issue.
**Option 2: "Restrict visibility to X(, Y, and Z)"**
"Restrict visibility to: \[some multi-select drop-down\]" and that drop down includes
* Internal team (reflected by permissions gained via project roles)
* Selected people or groups (sharing with direct people and groups)
* Selected project roles (shared with dynamically created groups that are defined by memberships having certain roles)
Observations
* Very flexible
* No clear default
* Complex to build
* Uncertain if we really want that in the future like that.
* Naming of these dynamic groups and differentiating them is also hard.
**Option 3: Differentiate between two different concepts "Confidential" and "Private"**
* Confidential (reflected by permissions gained via project roles)
* Private (shared)
Observations:
* Complex to explain
* But clearer to distinguish
* Seems to be mutually exclusive which seems to be limiting
* Unlikely that we ever want to have private comments IN(!) the Activity. Private things are more likely just attached/pinned to other things.
<br>