Help! Question about workaround for SLA-related bug JSDCLOUD-7546

[Monica Morris]

I recently learned about this bug that causes Jira to miscalculate the first response and/or resolution time on a service desk ticket where a service desk agent is also listed as a request participant. The workaround is described as "Remove the agent from the Request participants field or the organization."

It's not possible for me to remove the agent from the organization, so to avoid this bug going forward, I'll need to remove the agent from the Request participants field. I'd like to automate this process, using native Jira functionality if possible (ideally no plugins).

Before I set up any automation, I'd like to know exactly when in the service desk ticket lifecycle the agent needs to be removed from the Request participants field in order to avoid the miscalculation bug. Does the agent need to be removed before the first comment is made? Before the first response SLA is breached? Would removing the agent from the field upon ticket resolution avoid the bug?

Thank you in advance for any answers, and please vote for the bug fix if it would help your team too!

[Joseph Chung Yin]

@Monica Morris -

You will need to ask why the agent is added as requested participant in the first place in your project.  An agent should only play the role of an Agent (one who is assigned to the issue) and not playing both role of Agent and Customer.

If this not avoidable, you should just remove the agent from the Requested Participant assignment after the issue is created in your JSM project via Automation for Jira rule.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Monica Morris]

Hi Joseph, what exactly do you mean when you say "after the issue is created"? I'd like to clarify if there is any specific point in the process (before the first comment is made, before the first response SLA is breached, upon ticket resolution, etc.) where the agent must be removed from the Request participant field in order to avoid the miscalculation bug.

My goal is to make sure this bug doesn't affect any of my team's tickets, without any of my agents having to manually check and update the Request participant field.

It doesn't seem like there's a way to create a rule that only removes specific users from the Request participant field - this is my ideal; a rule that checks whether any of the agents on my team are listed as a Request participant, automatically removes them from the field if they are, and doesn't affect any customers listed as Request participants. 

So since it doesn't seem like my ideal is possible (please correct me if I'm wrong about that!) I'm thinking of creating a rule that automatically clears the Request participant field when the Resolution is set.

But before I create that rule, I'd like to know if clearing the Request participants field upon ticket resolution would actually avoid the miscalculation bug, or if the agent would need to be removed somewhere earlier in the ticket lifecycle.

[Joseph Chung Yin]

@Monica Morris -

Please advise the reason why agent is added in the Requested Participants field in the first place.  Again, An agent should not need to be added into the Requested Participants field in the first place.

Best, Joseph

[Monica Morris]

Hi @Joseph Chung Yin , I totally appreciate that agents don't need to be added into the Request Participants field since there are several other ways of bringing agents' attention to a ticket (ex. Watchers, internal comments, etc.)

The challenge is that many of our customers send their service desk requests via email, and they're in the habit of copying the tech support team members they usually work with on these emails, in addition to their business team colleagues. The CC line of an email to our service desk automatically populates the Request Participant field when a Jira ticket is created.

It's not politically feasible for me to demand that our business customers change their behavior by remembering to avoid copying anyone from the tech team on their support emails, especially when it's because of a bug that Atlassian could fix.

We also work with external vendors who use the CC line to alert our internal tech team to support emails because they don't have access to our service desk portal. There are several of these vendors and it's not feasible for me to try and change all of their behavior when they need to communicate with our internal tech team about an issue - again, especially because this is a bug that Atlassian can and should fix.

These are the reasons I'm looking for an automated workaround that removes the members of my support teams from the Request Participant field, and why I want to know where in the process the support team members would need to be removed to avoid the miscalculation bug.

[Joseph Chung Yin]

@Monica Morris - 

Thanks for your updates.  One of the possible solutions (NOTE - I have not test it out, so it is just an idea) -

1) Since agents are associated with each JSM project's "ServiceDesk Team" project role, you may want to create a rule that is triggered when an issue created to remove agent as Requested Participants.  

The key which I have not tested is to see if there is a way for configure the rule to check the requested participants entry if he/she are associated to the "ServiceDesk Team" project role.  If so, then remove the his/her entry only from the requested participants field.

Hope this give you some ideas.

Best, Joseph

[Monica Morris]

Thanks @Joseph Chung Yin , that was my first idea! It doesn't look like it's possible to set up an automation rule that removes any values from the Request Participant field through the service desk project automation UI, but it might be possible through the Jira REST API. I'll have to dig into it a bit more. 

In the meantime I'll probably create a post-function for the project workflow that clears the field value for the Request Participant field upon ticket Resolution and see if that works. Thanks for your ideas!