Restriction on comments

[Umar Maroof]

Hi everyone. 

hope everyone doing well.

Actually, I have two sections for a project. 

For example, in a task in two status the discussion is in between project leader and stackholder (staus1 = to be confirmed status 2=to be discussed) 

Now After these 2 statuses the issue is assignee to new role (status 3= In progress)

So, I want to hide all the discussion comments from the new role like the discussion occur in 2 statuses I don't want to show to the new role the issue is assignee also after the discussion held onward status 3, I don't want to show the comments to the stackholder holders.

How can I achieve this?

[Ste Wright]

Hi @Umar Maroof 

You can mostly do this, using Comment Visibility settings, and Automation.

There are some things to note though with this approach, see Notes below. I've also listed some Alternatives to consider.

---

Comment Restrictions

Comments can be restricted manually using the lock icon (below the comment box on the right-hand side) to either a Group or a Project Role (not Assignee though).

You do need to activate this on your instance - to do this:

1. Go to Settings (cog icon in top right) > System
2. Select General Configuration from the left-hand menu
3. Press the Edit Settings button in the top-right corner
4. Change the Comment Visibility option to either Group & Project Roles, or just Roles (depending on what works for you below)

---

Automation

You can then use Automation to set the comment restrictions depending on the Status.

Prerequisite:

• You need to decide how to identify the Users - either via a Project Role or a Group. It can only a single Role/Group per comment
• To modify the comment's visibility, you also need to be a member of the Role or Group
• For example, one option might be...
  • Create two Project Roles, one for Stockholders, one for Internal Members
  • Ensure the Project Lead is in both roles

Automation Rule:

The rule might then look something like this:

• Trigger: Issue Commented
  • Condition: If/Else Block
    • IF...
      • Sub-Condition: Issue Fields Condition
        • Field = Status
        • Condition = is one of
        • Value = To Be Confirmed, To Be Discussed
      • Action: Edit Comment
        • Comment to Edit = Trigger Comment
        • Comment Visibility = <Project Role/Group>
    • ELSE-IF...
      • Sub-Condition: Issue Fields Condition
        • Field = Status
        • Condition = is not one of
        • Value = To Be Confirmed, To Be Discussed
      • Action: Edit Comment
        • Comment to Edit = Trigger Comment
        • Comment Visibility = <Project Role/Group>

Note: The Actor needs to be a user with access to the relevant Role/Group. See below under Notes > Comment Security for more information.

---

Notes

Trigger

• Automation Rules run after the trigger action has happened, not during it. This means the comment is technically visible for a very short amount of time.
• If you have a Notification Scheme, and the notification Issue Commented sends updates to users - everyone could see the comment in an email before the rule hides it.
• I would recommend...
  • Remove all user types from the notification Issue Commented 
  • Experiment with sending the Issue Commented notification as part of the Automation Rule, after the comment restriction Actions

Comment Security

• The Automation Rule just sets the Comment's visibility - it does not stop a user from manually changing it by editing the comment.
• Because you also need to be in the Role/Group to set the comment visibility, you need to modify the Actor to be a human user, with access to the Role/Group
• If this is of concern, I would recommend...
  • Provide the Permissions Edit All Comments and Edit Own Comments to users who will see all the comments
  • Remove these Permissions from any user who should not see all the comments
  • Set the Actor for the Rule in Rule Details to be one of the users who has access to all comments - and can now edit them via the permission, Edit All Comments

Note: I would still test these suggestions within your instance, prior to setting any rules live.

---

Alternatives

There are several alternatives I would recommend - although both require hiding the whole Issue from the Stockholder / Other Users.

• Separate Projects: Create two Projects - one for the initial Statuses, and the second for Status 3 onwards.
  • You can then use Permission Schemes to limit who can see which Projects
  • You could still use Automation, to clone the Issue from one Project to another once the initial work is completed with the Stockholder
• Issue Security Schemes: Use Issue Security to show/hide the Issue within the same Project, depending on the Status. 
  • This could also be set using Automation
  • It does still require some modifications to Notifications and Permissions, but might be less onerous than limiting the Edit Own Comments permission because Set Issue Security has its own independent permission
  • Issue Security can also be set to a wider span of user types, including Assignee, Project Lead, etc

---

Lots to digest here! Let us know your thoughts, and if you need advice or further information about the recommendations/alternatives.

Ste

[Umar Maroof]

@Ste Wright 

Thanks for your response I will try this 

I have a question can we automatically clone the issue when the status is transition to ( to be approved) ?

[Ste Wright]

Hi @Umar Maroof 

Yes, in either of the alternatives you could automate the action - either...

• 2 Projects - Clone Issue
• Issue Security - Edit Issue > Modify Issue Security

For issue cloning, the rule might look something like this:

• Trigger: Issue Transitioned
  • To Status = To Be Approved
• Action: Clone Issue
  • Project = <Project Here>
  • Issue Type = <Issue Type Here>
  • ...etc

Ste

[Umar Maroof]

@Ste Wright I want to change the status of clone issue that is in other project depend on the issue cloned by which is in other project but this error com

[Ste Wright]

Hi @Umar Maroof 

A few things to check:

• Is this a Multi-Project/Global rule? It would need to be one if you are building a rule which spans two separate Projects
• Is the Status within the Action on KI-6...
  • Available in the Workflow for this Issue Type?
  • Possible to transition directly to?

Ste

[Umar Maroof]

@Ste Wright Ok I resolved this actually the status that I want to transit was not in my workflow now it's working fine 

[Sambhav Swain]

Can we apply this comment security on existing comments.

[Vivien Anayian]

That would be great

[Fabio Racobaldo _Herzum_]

Hi @Umar Maroof ,

you can't hide comments in JIRA based on a specific status. What you can do is to restrict comments when users perform them (https://confluence.atlassian.com/jirakb/add-restricted-comments-on-jira-962353957.html)

Keep in mind that, based on the restrictions, comments will be not shown in each status of your workflow. 

Hope this helps,

Fabio

[Umar Maroof]

@Fabio Racobaldo _Herzum_ 

Thanks for your response 

But can we have different issue view screen for different users ?

Any add on for this ? I am using jira cloud