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

System auto-transitions the issue to RESOLVED without any user intervention.

Roshen Antony

We've encountered an issue where tickets created by one of our clients in the JSM project are automatically transitioning to RESOLVED from IN PROGRESS, despite our workflow indicating that it should be a manual process. We have a Resolution screen attached to the RESOLVED status, which should prompt users to choose the appropriate resolution code and submit, resulting in the status changing to RESOLVED. However, for some tickets, this transition is occurring automatically by the System. Is this a known issue, or could it be a bug? Additionally, is there a possibility of this happening again in the future?"

Accepted answers

All comments

Sreenivasaraju P

HI @Roshen Antony ,

Please check whether you have some automation rules, which move ticket to Resolved from In Progress.

Regarding screen, have you add validation to make resolution field as mandatory ? If you don't have any validations them system can execute the transition without update the fields of the screen.

Roshen Antony

Hi @Sreenivasaraju P ,

Thanks for replying.

No, I don't. Only a rule which send out mail to the reporter once the issue transitions from IN PROGRESS to RESOLVED.

I'm not entirely certain about that. It was this same resolution screen with a bunch of resolution codes attached to the custom resolution field that appeared to function correctly across all projects without any validation issues. However, I encountered this issue with a specific project which resulted in auto-transition for only 2 tickets. The rest of the tickets followed the workflow as expected.

So I hope the validation is not mandatory in this case.

Please correct me if I'm wrong!

Sreenivasaraju P

You can add validation in the workflow.

Some thing similar as below and make resolution code field mandatory

Roshen Antony

Sure, thanks for the information. Will add the validation in the workflow.

As an alternative method, I was running a rule to transition the issue back to IN PROGRESS and send out a mail to the Admin or the PM if the transition isn't initiated by any of the support engineers.

Thanks @Sreenivasaraju P

Nic Brough -Adaptavist-

Hi Roshen,

You say "However, for some tickets, this transition is occurring automatically by the System."

This is not something Jira does. If a transition is happening, a human has either:

Chosen to make the transition

Set up an Automation, Script, or Listener, that will do it automatically in certain cases

You will need to work out what has been automated. Start with a look at the issue history - every transition will be logged with a change of status, showing the user account that performed it, and date and time. If the user doing it is a human, ask them. If it is an automation or script account, then you know where to look.

Roshen Antony

Hi Nic,

Thank you for your insight.

I completely understand and I agree that typically, transitions in Jira are initiated by human actions only, through some automated processes.

I've provided all the details of the case, It's indeed puzzling that the system appears to be triggering these transitions automatically. coz the workflow we configured is in such a way that the user (support engineers) will be the one who transitions the issue manually to Resolved. And No rule is being set up to do the transition.

I couldn't figure out what went wrong in these specific cases.

As a preventive measure, I am running a rule to revert the issue status back to "In Progress" if the transition isn't initiated by any support engineers. This mitigates the recurrence of the same issue from occurring in the future.

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