•  
     
    story #19275 restrict who can see comments
Summary
Empty
restrict who can see comments

I can share private thoughts with my gang and the customer don't know all the nifty details about his case.

Overview

The feature is called "Private Comments" even if it's not restricted to a private/public permission.

By default a comment is public, that means that as long as someone can view the artifact, they can view the comment.

When the feature is enabled, people can choose a group of people associated to a comment.

Only the member of this group, the tracker admins, the project admins and the site administrator will be able to read the content

Who can write private comments

At tracker level, the administrator can restrict this capability with a global switch "Activate private comments". It's active by default.

Write a private comment

The feature is accessible to all the users who can add a comment if the tracker enables this feature.

Artifact update

The user who write a comment can associate a group to this comment. The user can select one or more groups.

The comment is only visible to the members of the group, tracker admin, project admin and site admin.

If the user is not tracker admin, project admin or site admin, they can only select groups they belongs to (others are not displayed).

Technically speaking, this new permission should be stored outside of global permissions table.

Attachments

Attachments are regular fields update so if someone write a private comment and add an attachment, the attachment might be visible (according to the fields permissions) while the comment will not.

However there is transparent attachment addition when one copy/paste or drag'n drop images in a comment (HTML). In order to avoid leak of informations:

  • When a comment is set to be private, the copy/paste & drag'n drop of images is disabled
  • If the comment already includes copy/pasted or drag'n dropped images, it's not longer possible to set it private.

Email notification

⚠️ If the private comment is associated to changes and the user cannot see the comment, he might still be able to see the changes themselves (if they were done on fields they can see)

Reply by email

Reply by email are always public.

Comment update

When a user updates a comment, they can change the associated group.

If the user is not tracker admin, project admin or site admin, only the group they belongs to are displayed & kept at update (the membership might have changed in between).

Mass change

Tracker admin who do a mass change can associate a permission to the comment.

Artifact copy & move

Nothing to do

REST routes

The route /artifacts/:id/changesets is updated to add groups to last_comment key:

    "last_comment": {
      "body": "",
      "post_processed_body": "",
      "format": "text"
      "groups": [
          ugroup_representation
      ]
    },

groups key is only added if the user who does the call has the right to see this information and only the groups they belongs to are added.

The actual permission

Modals

Modal v1

Nothing to do, there are no comments here.

Modal v2

The ability to comment should be removed from modal v2 (too much to maintain).

Modal v3

Same behaviour than "Artifact update"

Display of private comments

Comments with a group associated to them are visually distinguishable.

A regular user can see:

  • All public comments (ie without any groups associated to them)
  • All comments associated to at least one group they belongs to.

Tracker admin, project admin, site admin see all comments.

⚠️ If the private comment is associated to changes and the user cannot see the comment, he might still be able to see the changes themselves (if they were done on fields they can see)

Search

Permissions must be taken into account in the "comment search" box in tracker reports.

Empty
Matevz Langus (matevy)
Status
Empty
Ready (stalled)
Development
  • [ ] Does it involves User Interface? 
  • [ ] Are there any mockups?
  • [ ] Are permissions checked?
  • [ ] Does it need Javascript development?
  • [ ] Does it need a forge upgrade bucket?
  • [ ] Does it need to execute things in system events?
  • [ ] Does it impact project creation (templates)?
  • [ ] Is it exploratory?
Empty
Details
#19275
Manuel Vacelet (vaceletm)
2022-05-04 13:32
2021-02-08 10:09
3822

References
Referencing story #19275

Git commit

tuleap/tuleap/stable

Add tables "plugin_tracker_private_comment_disabled_tracker" and "plugin_tracker_private_comment_permission" aa75fa9189
Hide private comment in artifact/$id/chengeset REST route d2161d9c9e
Enable private comment in tracker during XML import 47815cea25
Refacto: UGroups that can see a private comment must be in the comment object 820b8b8785
Export private comment ugroups in XML 89278993a8
Display ugroups in private comment in artifact/$id/changeset REST route 1d9a6edeb7
Hide comments that user can't see 8a7a9df159
Don't search on private comment in tracker reports 6326740a4c
Refactoring: isPrivateCommentForUser() is more understandable than userCanSeeComment() 0f517055a2
Delete ugroups from plugin_tracker_private_comment_permissions when ugroup is deleting 54670a530f
Tracker report comment filter takes into account private permission cdd2049292
Empty followups are not displayed in Artifact View 4e90b6bfdb
Fix empty_followup E2E tests to avoid "eslint-disable-line" 12b67d7c45
Empty followups are not displayed in Modale V2 0edf674753
Don't show empty changeset in GET Rest route 824b8c6f94
Memoize calls made to TrackerPrivateCommentUGroupEnabledDao::isTrackerEnabledPrivateComment 2b98d91f06

Follow-ups

User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
  • Status changed from On going to Ready (stalled)
  • Category set to
User avatar
Matevz Langus (matevy)2021-03-06 07:52
Hi,

Is the current implementation good for testing already?

Regards,
Matevz
User avatar

yes, you are correct. This is becoming too complicated because of the concept you have chosen for private comment permissions.

Indeed, it's easier with the "private/public" strategy. However 100% of the time this strategy was chosen, 100% of time there were requests for something more flexible (just look at the madness of project visibility for instance).

Plus, we target to import from Jira that supports groups.

User avatar
Matevz Langus (matevy)2021-02-10 11:22
yes, you are correct. This is becoming too complicated because of the concept you have chosen for private comment permissions.

we made per traffic default permission for private comments and user is able to just enable/disable private status of the commit. Email going out was equipped with PRIVATE in subject so that also email receivers knew it is private and upon reply to that email server based on PRIVATE keyword marked the comment as private. A bit stupid & simple, but works.
User avatar

If private reply by email is needed it should be done on top of this story in a dedicated one. There are far too many things to take into account and it's beyond the current need. Issues already identified:

  • Clearly identify the changeset one is replying to
  • Deal with the "by pass permissions" of the email notifications
    • That means one could reply to a comment they are not allowed to see and therefore they should not see their own comments

  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
Matevz Langus (matevy)2021-02-10 09:50

You won't select a comment as "private" and then select groups. You will select groups directly, no 2 steps. Having a default set of groups is beyond the scope of this implementation.

Not as good as I was hoping for, but still perfectly fine.

  • private attachments :-)

Already mentioned as beyond the scope of this implementation ;)

OK, will throw away our current implementation and wait for yours for comments and then create the same way you did for comments for attachments. Maybe that implementation will be acceptable for you.

 

 

User avatar
  • it would be good to have a quick way to enable comment as private by just single click action (not selecting groups for each comment which needs to be made private). Ideally there is a default set of permissions for private comments configured for tracker and once user selects comment as private it inherits the default value. Only by additional clicks groups can be changed. Based on our past experience it can quickly lead to incorrectly configuring permissions when people are in hurry and therefore information leak

You won't select a comment as "private" and then select groups. You will select groups directly, no 2 steps. Having a default set of groups is beyond the scope of this implementation.

  • indication (by probably different colour of the comment) that specific comment is private (or visibility of before mentioned check box)

That's covered here (mock-up to come)

  • if mail is replied to the comment that was private, the new comment should be made private as well

That's a good point, we need to think about it

  • private attachments :-)

Already mentioned as beyond the scope of this implementation ;)

User avatar
Matevz Langus (matevy)2021-02-09 20:48
Hi,

I would like to propose the following:

- it would be good to have a quick way to enable comment as private by just single click action (not selecting groups for each comment which needs to be made private). Ideally there is a default set of permissions for private comments configured for tracker and once user selects comment as private it inherits the default value. Only by additional clicks groups can be changed. Based on our past experience it can quickly lead to incorrectly configuring permissions when people are in hurry and therefore information leak
- indication (by probably different colour of the comment) that specific comment is private (or visibility of before mentioned check box)
- if mail is replied to the comment that was private, the new comment should be made private as well
- private attachments :-)
User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes