Block Customer-Facing transition from Agent View

[Mathew Lederman]

I want to have 2 transitions to a Cancelled status

• 1 for customers that is restricted based on current status. The Customer shouldn't be able to cancel a request that's In Progress because the team needs to back-out their work
• 1 for agents that requires a resolution and comment.

Hiding the agent-facing transition from the customer portal is easy. However, hiding the customer-facing transition from the agent-view is proving to be difficult.

I would prefer to not depend on reporter/participants because a number of team members submit tickets for work they've already completed for tracking purposes. While duplicate Cancelled statuses won't prevent their process, it is a point of confusion I'd prefer to avoid.

I do have JMWE and ScriptRunner available if this is not possible with native conditions.

[Trudy Claspill]

Hello @Mathew Lederman 

Do all the customers have something in common that is not also common to Agents?

1. Are the customers all added to the Service Desk Customer project role? And do none of the Agents below to the Service Desk Customer project role?
   1. If this is true you should be able to add a Rule/Condition/Restriction on the transition to make it available to only members of the Service Desk Customer role.
2. Do all the customers belong to a User Group that none of the agents belong to?
   1. If this is true you should be able to add a Rule/Condition/Restriction on the transition to make it available to only members of the user group(s) to which only customers belong.
3. Are all customers assigned to at least one Organization?
4. Do their emails belong to domains that are different from the emails of your agents?

If 2 or 3 are true then something could probably be done with JMWE or Scriptrunner conditions.

[Mathew Lederman]

@Trudy Claspill  appreciate the suggestions, but unfortunately none of them will work for our scenario.

• All agents are also customers.
• All agents belong to one of ~200 groups for assignment requests, but that list is always changing so I can't key on that.
• It's an internal service desk, so all users emails have the same domain.

Even if I can differentiate the users somehow, that doesn't truly resolve the issue because a number of teams submit and resolve their own tickets for tracking work completed.

I believe this can only work properly with a transition property much like servicedesk.customer.transition.active used to be the way to make a transition available on the portal. I need something like servicedesk.agent.transition.active = false

[Trudy Claspill]

@Mathew Lederman Thank you for that additional information.

If I understand correctly then, the restriction can't have anything to do with the user viewing the data, but rather only with how they are viewing it. If they are viewing it through the portal then they should see the button (if the other transition restrictions allow it). If they are viewing it through the internal UI/agent view, then they should not see the transition.

Is that correct?

So far I have not found anything through Google-fu or Gemini about a method to hide the transition from the internal UI only for all users while keeping it visible in the customer portal. There is a "Hide from users" condition, but that would affect the portal also. All other work arounds I've found leverage information about the user that is viewing the information.

I asked Gemini for a solution to hide the transition in the internal UI while showing it in the portal and it provided a solution still that leveraged user information. I then asked it

"Can the solution be implemented in a way that relies only on whether the view is the internal UI or the customer portal, and doesn't rely on information about the user viewing the information?"

It said no, with this explanation:

In Jira Cloud's cloud-first architecture, workflow transitions and their underlying conditions are processed entirely on Atlassian's backend servers, meaning they have no awareness of the frontend UI context or the specific screen the user is looking at

The backend server evaluates whether to display or hide the transition button based on the contextual data it receives, which is why your solution must fall back on information about the user or specific app/system properties executing the request. 

If your core goal is to differentiate the experience purely by entry point without manually maintaining large user lists, you can utilize the following alternative architectural approaches:

It then suggested solutions that still rely on the current user's information, or it proposed Scriptrunner UI Fragments, but that feature doesn't have anything for this specific requirement that applies to Jira Cloud.