Block user comments on statusses "Resolved" and "Closed"

[dennis.decoster]

Hello,

I am not managing to block comments on 1 status, while it worked for another. The same exact transition permission was used  => jira.permission.comment.user

Your help would be appreciated in figuring this out

The context

In my company, we do not want users to reopen an issue through a comment, as too often they accidentally reopen tickets by adding a comment to say thanks.

Instead they have to use a transition on the customer portal. However being endusers, they will forget and add comments to try to reopen an issue.

If an issue is considered resolved from ICT pov (JIRA resolution field is set), the issue no longer shows up in our teams their Queue, as there's no more followup to be done. This means the statuses "Resolved" and "Closed".

From "Resolved", a user can either reopen or close the issue using the transitions on the customer portal. If reopened the issue returns to "In Progress". If closed the issue is set to status "Closed".

To avoid user frustration from them trying to reopen a ticket, and us not being aware & ignoring their comments, the idea is to block user comments in the statuses "Resolved" and "Closed". 

Maybe add a transition screen on top of the transition to reopen an issue.

The problem

I've managed to use block comments on issues with the Status "Closed" through the transition permission jira.permission.comment.user = denied

However, the exact same thing is not working for the status "Resolved".

The internet has failed me in helping to find the cause and a solution.

[Rodrigo Martinez · Accepted solution]

Hi Dennis!

Hope you're doing great!

I have reached a slightly different property: jira.permission.comment=denied, as per:

https://www.j-tricks.com/tutorials/permissions-based-on-workflow-status

jira.permission.comment.user = denied would allow the username "denied" to comment on the issue while in that status. Perhaps the Closed status is forbidding comments due to some other config?

On a different approach, perhaps the reopening is being made by JSD Automation Rules. If that's the case, you may also remove the Automation Rule (per Project) that reopens the issue upon commenting. This way you'd keep allowing users to comment but the issues wouldn't be reopened automatically.

Please come back to share with us either the success or if we shall keep working on it!

Cheers

[dennis.decoster]

@Rodrigo Martinez 

Thanks for your feedback, I have removed the property "jira.permission.comment.user = denied" now that I better understand it's effect. 

Also thank you for removing the "spam" tag from this question.

However in the meantime I had already opened a new question to which I got a satisfactory answer

=> https://community.atlassian.com/t5/Jira-Service-Desk-questions/Block-user-comments-on-statusses-quot-Resolved-quot-and-quot/qaq-p/1135927?

[Rodrigo Martinez]

Hi @dennis.decoster!

I'm glad you had it worked out either way!

Though I'd still suggest you take a look on Service Desk Automation. From the context you described, there might be an automation like "Reopen on customer comment".

Disabling/removing that automation from the desired Projects is usually better than tampering with workflow status properties (and would even unclutter the application log with INFO messages about overriden permissions).

Here's a starting documentation page you may find useful: https://confluence.atlassian.com/servicedeskserver040/automating-your-service-desk-967332201.html

Thanks for getting back to the Community with your feedback!

Cheers

[dennis.decoster]

Additional question.

How can I restrict this to only customer portal users and not service desk agents? I know  the project role needs to be added somewhere...

Looked at https://www.j-tricks.com/tutorials/permissions-based-on-workflow-status

I can only think of something like

jira.permission.comment.servicedeskcustomers.denied1 = true

That feels too easy though

[Rodrigo Martinez]

Hi Dennis!

Sorry for getting back to you after sooo long.

If still on the workflow permission scope, I'd try something like jira.permission.comment.projectrole=99999

With 99999 being the role id in your instance. You can view them by hovering the mouse over each of them in <your-jira>/secure/project/ViewProjectRoles.jspa as Admin.

But then again - and sorry if I sound insistent here :-) - Service Desk bundled Automation has this neat functionality. Check this quick doc and the "User Type" filter that can be set to either "Agent" or "Customer":

Automating Your Servicedesk

Best wishes!

[dennis.decoster]

Thanks @Rodrigo Martinez ,

No luck getting the Project Role ID on the page you referenced, neither in Chrome nor in IE. There was nothing being displayed on hover.

So instead I tried using  jira.permission.comment.projectrole = Service Desk Team on the Resolved status which resulted in messages stating "The issue doesn't exist" when I tried to view any resolved issue in the project.

Any thoughts?

[Rodrigo Martinez]

Hi Dennis!

Hope you had a great weekend!

I'm sorry, I said mouse hover but failed to make it clear where would the id appear. See if this screenshot helps you:

On hovering the mouse over the edit link, for example, the address will appear somewhere on the browser. The screenshot os from Chrome on MacOS. The id here is 10200 for the SD Customer role.

Cheers