Hi all,
In JSD, I have a screen that must be used when an agent is clicking on 'In Progress'.
The transition will auto-assign the issue to the agent, but the screen that I display is required to fill some information.
The problem is that sometimes the agents are using the 'assignee' field to assign it to themselves and that bypasses the screen that I want to display.
Is there a way to remove permission for that field only for the agents or 'jira service desk team' role?
Hi Gil,
We used to suffer from the same problem of our agents simply using the assign button vs the "accept issue" or in your case "in progress".
What I did was added a property to the step (in your case waiting for support). Add this property in the property key:
jira.permission.assign.denied
Leave the property value blank. Works wonders....
@Susan Hauth _Jira Queen_ that looks like a great solution.
Will that also disables any automation or workflow post-function or site-admin (me) to edit this if needed?
UPDATE: It didn't work. Agents can still edit the assignee without using the workflow button.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Do you add the jira.permission.assign.denied to the 'waiting for support' status? or a transition?
Do I need to assign it to every status and transition?
Also, how do you apply the same for the 'Resolution' field? I have the same issue when agents edit the issue directly by clicking on the resolution field instead of using the Resolve Issue button.
is it jira.permission.resolution.denied? Do I need to add this to every transition and status?
Will agents still be able to set resolution via 'Resolve Issue' button?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Gil,
ON the "waiting for support" status property add the jira.permission.assign.denied.
You only need to do it for the statuses that you want to remain unassigned.
For Resolution take the field off the edit screen then it can't be edited.
If the resolve issue brings up the resolution field then yes they can set it there. Make sure it's validated as a required field.
Susan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, that's great. Thank you!
I have another challenge then.
Is seems that this property value doesn't allow customers to resolve an issue if this property is set.
Is there a way to make this only valid for agents but be bypassed by customers?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Gil,
When the customers are resolving the issue, check that workflow transition. If it's assigning the issue to the reporter or the agent, then yes that will be a problem as that goes against the setting.
For properties there is no way to make them conditional or bypassed.
Susan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
after some testing, it appears that the jira.permission.assignee.denied is, in fact, restricting the customer from resolving the issue.
I had to remove this restriction to allow customers to resolve an issue.
But it's great to know that I can apply these restrictions with the property.key fields.
Luckily, we are a small team so it is a bit easier to enforce the agents to not use the assignee field directly.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.