Andrzej Wójcik (Tigase) opened 3 months 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.
-
Is the purpose of this to segregate organizational (internal) users from customers? I ask because in a large organization, user X could be "internal" for project A but a "customer" for project B.
If this use case is valid, then we need a notion of adding users to a project: a notion that doesn't exist yet in Sztab (or I think even in OneDev) - because its while admitting a user into a project that admin decides if the user is external to the project.
If we assume a simpler worldview, where we have "internal" users (a@tigase.net, b@tigase.net ...) and "external" users (c1@cisco.com, c2@wal-mart.com, ...), regardless of any project, the design becomes simple: in this case, we use a simple user-level flag: is_external (boolean, default false). An external user is marked external system-wide. Then internal comments are hidden from all external-flagged users across all projects.
Please consider use cases beyond Tigase; Sztab will be applicable beyond Tigase.
-
rk@tigase.net changed state to 'In Progress' 3 weeks ago
Previous Value Current Value Open
In Progress
-
Is the purpose of this to segregate organizational (internal) users from customers? I ask because in a large organization, user X could be "internal" for project A but a "customer" for project B.
If this use case is valid, then we need a notion of adding users to a project: a notion that doesn't exist yet in Sztab (or I think even in OneDev) - because its while admitting a user into a project that admin decides if the user is external to the project.
If we assume a simpler worldview, where we have "internal" users (a@tigase.net, b@tigase.net ...) and "external" users (c1@cisco.com, c2@wal-mart.com, ...), regardless of any project, the design becomes simple: in this case, we use a simple user-level flag: is_external (boolean, default false). An external user is marked external system-wide. Then internal comments are hidden from all external-flagged users across all projects.
Please consider use cases beyond Tigase; Sztab will be applicable beyond Tigase.
I have provisioned the view of internal vs. external users as follows. External users are displayed with a reddish tint providing a distinct visual clue:
Adding a comment to an issue allows user to mark the comment internal (masked from external users):
or external (can bee seen by external users):
Screenshot 2026-02-23 at 10.36.48 PMCommenting on an issue provides user optin to mark the comment internal or external:
Screenshot 2026-02-23 at 10.31.25 PMInternal comments are masked from external users using a watermark as follows:
-
rksuma@Ramakrishnans-MacBook-Pro sztab % git status On branch feature/SZ-53-private-comments Your branch is up to date with 'origin/feature/SZ-53-private-comments'. nothing to commit, working tree clean rksuma@Ramakrishnans-MacBook-Pro sztab % git checkout wolnosc git pull origin wolnosc git merge --no-ff feature/SZ-53-private-comments Switched to branch 'wolnosc' Your branch is up to date with 'origin/wolnosc'. From https://tigase.dev/sztab * branch wolnosc -> FETCH_HEAD Already up to date. Merge made by the 'ort' strategy. backend/src/main/java/com/sztab/Application.java | 2 + backend/src/main/java/com/sztab/controller/IssueController.java | 134 ++++++++++++++---------- backend/src/main/java/com/sztab/controller/PullRequestController.java | 106 ++++++++++++------- backend/src/main/java/com/sztab/dto/UserDto.java | 3 + backend/src/main/java/com/sztab/dto/common/AddCommentDto.java | 7 +- backend/src/main/java/com/sztab/dto/common/AttachedCommentDto.java | 30 +++++- backend/src/main/java/com/sztab/dto/common/CommentVisibilityUpdateDto.java | 9 ++ backend/src/main/java/com/sztab/dto/issue/IssueDto.java | 5 +- backend/src/main/java/com/sztab/dto/pr/PullRequestDetailDto.java | 8 +- backend/src/main/java/com/sztab/dto/pr/PullRequestDto.java | 10 +- backend/src/main/java/com/sztab/dto/user/UserSummaryDto.java | 9 +- backend/src/main/java/com/sztab/exception/ResourceNotFoundException.java | 9 ++ backend/src/main/java/com/sztab/exception/handlers/GlobalExceptionHandler.java | 8 ++ backend/src/main/java/com/sztab/model/Comment.java | 28 ++++- backend/src/main/java/com/sztab/model/User.java | 8 ++ backend/src/main/java/com/sztab/model/enums/CommentVisibility.java | 5 + backend/src/main/java/com/sztab/model/enums/UserType.java | 5 + backend/src/main/java/com/sztab/service/IssueService.java | 7 +- backend/src/main/java/com/sztab/service/PullRequestService.java | 3 +- backend/src/main/java/com/sztab/service/UserService.java | 2 + backend/src/main/java/com/sztab/service/impl/IssueServiceImpl.java | 167 ++++++++++++++++++++++-------- backend/src/main/java/com/sztab/service/impl/PullRequestServiceImpl.java | 5 +- backend/src/main/java/com/sztab/service/impl/UserServiceImpl.java | 12 ++- backend/src/main/resources/db/migration/V07__create_global_issue_sequence.sql | 7 ++ backend/src/test/java/com/sztab/controller/IssueControllerTest.java | 165 ++++++++++++++++++++---------- backend/src/test/java/com/sztab/controller/UserControllerTest.java | 5 +- backend/src/test/java/com/sztab/dto/PullRequestDtoTest.java | 3 +- backend/src/test/java/com/sztab/repository/BranchRepositoryTest.java | 3 +- backend/src/test/java/com/sztab/repository/ProjectRepositoryTest.java | 3 +- backend/src/test/java/com/sztab/service/IssueServiceImplTest.java | 6 +- deploy/docker/docker-compose.yml | 37 +++---- frontend/src/api/issues.ts | 9 +- frontend/src/api/pr.ts | 2 +- frontend/src/components/common/Modal.tsx | 6 +- frontend/src/components/issues/IssueEditModal.tsx | 416 ++++++++++++++++++++++++++++++++++----------------------------------------- frontend/src/components/project/CreateProjectModal.tsx | 7 +- frontend/src/components/users/CreateUserModal.tsx | 119 ++++++++++------------ frontend/src/components/users/EditUserModal.tsx | 6 +- frontend/src/context/AuthContext.tsx | 2 + frontend/src/pages/pr/PrDetailPage.tsx | 2 +- frontend/src/pages/users/UserListPage.tsx | 168 ++++++++++++++++-------------- frontend/src/types/comments.ts | 9 +- frontend/src/types/users.ts | 8 ++ 43 files changed, 944 insertions(+), 621 deletions(-) create mode 100644 backend/src/main/java/com/sztab/dto/common/CommentVisibilityUpdateDto.java create mode 100644 backend/src/main/java/com/sztab/exception/ResourceNotFoundException.java create mode 100644 backend/src/main/java/com/sztab/model/enums/CommentVisibility.java create mode 100644 backend/src/main/java/com/sztab/model/enums/UserType.java create mode 100644 backend/src/main/resources/db/migration/V07__create_global_issue_sequence.sql rksuma@Ramakrishnans-MacBook-Pro sztab % git push origin wolnosc Enumerating objects: 1, done. Counting objects: 100% (1/1), done. Writing objects: 100% (1/1), 250 bytes | 250.00 KiB/s, done. Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) To https://tigase.dev/sztab.git 362587e..75d8a0d wolnosc -> wolnosc rksuma@Ramakrishnans-MacBook-Pro sztab % rksuma@Ramakrishnans-MacBook-Pro sztab % git checkout wolnosc Already on 'wolnosc' Your branch is up to date with 'origin/wolnosc'. rksuma@Ramakrishnans-MacBook-Pro sztab % git branch -d feature/SZ-53-private-comments Deleted branch feature/SZ-53-private-comments (was db4c113). rksuma@Ramakrishnans-MacBook-Pro sztab % git push origin --delete feature/SZ-53-private-comments remote: remote: Create a pull request for 'feature/SZ-53-private-comments' by visiting: remote: https://tigase.dev/sztab/~pulls/new?target=1325:wolnosc&source=1325:feature/SZ-53-private-comments remote: To https://tigase.dev/sztab.git - [deleted] feature/SZ-53-private-comments rksuma@Ramakrishnans-MacBook-Pro sztab % -
Previous Value Current Value In Progress
Closed
| 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.