nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Adding Restrictions on Jira 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?

Accepted answers

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:

Go to Settings (cog icon in top right) > System
Select General Configuration from the left-hand menu
Press the Edit Settings button in the top-right corner
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

All comments

Fabio Racobaldo

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 _Catworkx_

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

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:

Go to Settings (cog icon in top right) > System
Select General Configuration from the left-hand menu
Press the Edit Settings button in the top-right corner
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 clone issue.png

Sambhav Swain

Can we apply this comment security on existing comments.

Vivien Anayian_qu3ei3

That would be great

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

atl-bobross