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; } } }

Want to show only relevant ticket to assignee

Riki YAMASHITA_as584h

I would like to know the possibility of showing the ticket that is only relevant to assigned user.
For example:
condition:
> Assignee-A is L1 support
> Assignee-B is L2 support

1) Assignee-A is taking care of a ticket as L1 support.
2) Assignee-A escalate the ticket to L2, that is Assignee-B, by changing "assignee".
3) Assignee-B only see a ticket which has been escalated from L1, that is Assignee-A.
4) Assignee-A are able to see all the tickets that is for L1 and L2.

Accepted answers

Ste Wright

Hi @Riki YAMASHITA

Can I confirm if it is...

Assignee A/B can see all tickets, but their queue limits which ones are visible to them as a priority, or...
Assignee A sees all tickets, but Assignee B only sees escalated tickets. IE if a ticket is in L1, Assignee B would not be able to view it even if they wanted to.

---

For (1), custom queues should work - for example....

assignee = Assignee B - this would show Assignee B's issues only
assignee = currentUser() - this would show issues assigned to a user dynamically based on who is logged in
assignee was currentUser() and assignee = Assignee B - this could show issues which were Assigned to Assignee A are now assigned to Assignee B. You could change currentUser() for Assignee A, or reference multiple Assignees using "IN"

---

For (2), you'll need an Issue Security Scheme - check out this help page as a good starting point.

You could use Automation to change the Security Level based on an escalation field being updated.

---

Let us know if you need more specific instructions

Ste

All comments

Joseph Chung Yin

@Riki YAMASHITA -

Can you provide more details on how issues are escalated? What else is used to tag the issues between L1 and L2?

If it is simply an assignee change (i.e. assigned to Assignee-B on issues) that change the issue from L1 to L2, then you can just create custom queues in your JSM project using the following JQL filter -

Assignee-B queue will use something like "project = xyz and assignee = assignee b's account id". Afterward, just tell Assignee-B to access the issues using the new queue in the project UI.

On the other hand, can Assignee-B be able to access L1 issues at all?

Please advise with more information, so we can assist you better.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Technology Applications Team

Viasat Inc.

Riki YAMASHITA_as584h

Hi Joseph, thanks for a quick reply.

It is just a simple assignee change.
I want Assginee-A to see all issues, but Assignee-B to see only the issues that he / she is taking care of (both on-going and done).

I think what you have mentioned seems to be the solution:
Assignee-B queue will use something like "project = xyz and assignee = assignee b's account id". Afterward, just tell Assignee-B to access the issues using the new queue in the project UI.

Custom queue is a URL that ends something like this right?: /custom/45

Best regards,
Riki

Ste Wright

Hi @Riki YAMASHITA

Can I confirm if it is...

Assignee A/B can see all tickets, but their queue limits which ones are visible to them as a priority, or...
Assignee A sees all tickets, but Assignee B only sees escalated tickets. IE if a ticket is in L1, Assignee B would not be able to view it even if they wanted to.

---

For (1), custom queues should work - for example....

assignee = Assignee B - this would show Assignee B's issues only
assignee = currentUser() - this would show issues assigned to a user dynamically based on who is logged in
assignee was currentUser() and assignee = Assignee B - this could show issues which were Assigned to Assignee A are now assigned to Assignee B. You could change currentUser() for Assignee A, or reference multiple Assignees using "IN"

---

For (2), you'll need an Issue Security Scheme - check out this help page as a good starting point.

You could use Automation to change the Security Level based on an escalation field being updated.

---

Let us know if you need more specific instructions

Ste

Riki YAMASHITA_as584h

@Ste Wright , thanks for your comment.

Your understanding "2" is correct.

Let me see about Security Scheme and the link if it fits my need.

Thanks again and will get back to you.
Best regards,

Riki

Joseph Chung Yin

@Riki YAMASHITA -

Yes... It should be something like - "servicedesk/projects/<projectkey>/queues/custom/##"

Hope this helps, if so, please click on "Accept answer" when you have a chance.

Best, Joseph

Ste Wright

Thanks for confirming @Riki YAMASHITA

If you need help setting up an "Issue Security Scheme", let us know

Ste

Riki YAMASHITA_as584h

@Ste Wright , thank you for the follow up. I went through the doc but I have a feeling that I need to setup something else before. My rought idea is to:
1) Create project role (something like Service Desk Team, Service Desk Customers)
2) Associate user
3) Set Issue Security

If I am talking totally different, it is grateful if you can provide me a rough step guidance.

Thank you so much for your support.
Best regards,
Riki

Joseph Chung Yin

@Riki YAMASHITA -

Hi Riki:

Your understanding of issue security is correct at a high-level.

A few note that you need to make sure to always setup your security level to grant and call out for project Administors role members + the as always include the "reporter", so project admin and the reporter will not be locked out from accessing the tagged issues.

Hope this is also helps.

Best, Joseph

Riki YAMASHITA_as584h

Thanks to all, i was able to run it as expected! Both Stephen and Joseph were super helpful but decided to give accept answer to Stephen as he was the first person to give me a reply!

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management