•  
      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
    3828

    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