Andrzej Wójcik (Tigase) opened 2 weeks ago
-
@kobit I think this feature could be useful. I'm assigning it to you for review and to make decision if that is something we would want.
Also I wonder if we shouldn't have a separate states for "customer" project issues. Some tasks may be ready for internal testing but not for the customer, so those would be "in qa" internally, but still "in progress" for the customer.
I'm making those suggestions based on the recent exchanges with customers.
-
+1 from my side.
Although, I am a bit worried that at some point, someone may forget to click 'private comment' and expose content to customer. So, we would have to think of the best way to implement it. Maybe, when the first comment is marked as private, all subsequent comments could have private by default....
-
Yes, that was my worry as well. I suppose if we reply on comment, reply should have the same visibility as the original comment. Also, I would suggest that "team" should have "private" checked by default and we would need to "uncheck" (it is safer to forget making comment public than making comment private).
-
I'm very much in favour of this because it would make the work easier (one could carry out discussion internally about particular issue without exposing it to wider audience)
Although, I am a bit worried that at some point, someone may forget to click 'private comment' and expose content to customer. So, we would have to think of the best way to implement it. Maybe, when the first comment is marked as private, all subsequent comments could have private by default....
That is my qualm as well and I was kinda worried each time I wanted to use it with YouTrack, however Andrzej's suggestion to be able to have "internal"/"external" visibily is sound, but with added twist: I would make it an option (on a project level?) to have default visibility and it would entail following:
- all issues created are with that default visibility - you have to explicitly opt-in to make it publicly visible.
- if the issue is created by "external" user/role the that issue (and first comment) visibility would have external visibility
- all comments by default have default (internal) visibility
- if the comment is made by role/user with external visibility then visibility of tha comment would be public
- if the comment is made by the role with internal visibility then by default it would have internal visibility and each time it would require manual opt-in to make it public
- quoting internal/private comment should force the comment to have internal visibility as well without a way to override
- it should be possible to switch comment visibility from internal to external but this would require confirmation; it should also generate new notificaiton for the new visibility
Of course internal comments should be marked very visibly (explicitly different background and possibly an icon), possibly something like this watermark:
- all issues created are with that default visibility - you have to explicitly opt-in to make it publicly visible.
| Type |
New Feature
|
| Priority |
Normal
|
| Assignee | |
| Version |
none
|
| Sprints |
n/a
|
| Customer |
n/a
|
Previous project management systems that we used have function to submit private comments (visible only to selected group of users, roles). That allowed us to discuss topics related to the customer related issue internally within the issue but that discussion was not visible to the customer. This feature was very useful as it allowed for internal discussions while at the same time allowed us to have full information exchange in a single issue.
I suppose we could have this in Sztab by setting roles or groups to "internal"/"external" within a project (or even at the user/group level). Then within the issue each comment would have a visibility assigned (internal/external). I would suggest to have "internal" visibility as default (to make sure we would not publish "private" information exchange). Also "reply" button could just copy visibility level of a comment, if we reply on private/internal comment then reply should also be private/internal.