Resolved date set without ticket being resolved

[Stian Bentsen Sveen]

Hi!

I have a bit of a weird issue.

We are getting automated emails from our HCM system to our service desk regarding new hires / change of position / terminated hires. Ideally I would've liked to use our REST API for this to have much more control of all the fields set etc, but the HCM system is cloud based and our JIRA is on prem and they couldnt seem to figure that out.

So what i've done is have them create 3 different email templates for these kinds of emails, with the subject being static, like: "New Hire: <name of new hire>, Change of Position: <name of employee> etc.

Our service desk maps all incoming emails as incidents, as it should, but these specific emails are requests, so to avoid support having to do a move and change issue type, i've created automations for this using the JIRA Automation add-on.

It basically checks if summary contains either of those static subjects ("New Hire:" etc) then edits issue type, customer request type and a few custom fields.

For some reason this often makes the ticket un-transitionable and our servicedesk needs to move the ticket to another issue type and back to fix it.

I fixed this by changing the automation and instead of editing the issue type (which is not possible to do via normal GUI, you have to move it) it actually clones the original ticket and sets the issue type on the new ticket to "Service Request", then deletes the old one.

But, this created another issue. Seems like the resolved date is set on these tickets as they are created, even though they've never been resolved or entered a resolution state (created date and resolved date is identical).

Why is this and how can I fix this? Ideally a fix to the first issue with not being able to transition the ticket would be the best, but either is ok :)

[Nic Brough -Adaptavist-]

My guess is that the main problem is your "then edits issue type".

You cannot "edit" the issue type, you mostly have to move the issue from one type to another.   If you do not use "move", you can throw the issue into an unusable state because you are not updating the configuration of it.  I say mostly because there is an exception to that - if the old issue type and new issue type are in the same project and have exactly the same configuration, "edit" can be done.

So, my guess is that if you were to look at one of the issues that has lost all ability to transition, it has had it's type changed from one which has different

• field contexts
• field configuration scheme
• workflow

It could be any or all of those, and it does not even matter if the differing thing is an unmodified copy of the one for the old issue type.

First, you need to stop "editing" the issue type in your automation, unless you are 100% sure that the issue types are using the same shared configuration for all three things.

Next, you should be able to fix the untransitionable issues by running the integrity checker - I expect that to throw up lots of "workflow broken" errors, but it can fix them.

[Stian Bentsen Sveen]

@Nic Brough -Adaptavist-  Thanks for the very quick reply!

I suspected as much since as you mentioned, you cannot edit an issue type through normal means. Its in the same project, but there are differences in field contexts and workflows.

Would my second solution be viable? I havent run into any of those issues when cloning the original ticket and then deleting the original ticket afterwards. My issue there is the resolved date being set at the same time as the created date, even though its never reached a status where the resolution is set.

Or, do you have any other ideas how I can solve this? Emails as standard needs to be an incident since its normally used as a last resort for reporting incidents if they dont have access to the portal, but those HCM tickets needs to be registered as service requests and using the REST API is not available for us at the moment since external access to our hosted JIRA instance requires MFA.

Br,

Stian