When creating a new ticket, sometimes it should be resolved, sometimes open

[Lewis West]

Is there a way to create tickets and choose if it something resolved or open?

I tried adding the Resolution field to the Create Issue screen, but then all issues were created as resolved.

I'd like a way for our team to open a new ticket, and if it's something resolved, be able to easily mark it as resolved.

Thanks for any tips.

[Lewis West · Accepted solution]

The solution I found for this was to create a checkbox field and add it to the Create Issue screen.

Then I created several automations, so that if the new field is checked, it will transition the issue Status to "Resolved" as well as vice versa so that the checkbox and Status are always synced together.

While it isn't as elegant a solution as I was hoping for, it appears to work.

If someone thinks they have a better solution, I'm still open for it.

[Joseph Chung Yin]

@Lewis West -

As long as your solution doesn't expose the Resolution field for editing by users, then it should be OK.  Just remember that Resolution field needs to be controlled by the WF status transition.

If my suggestion also helped you, please click on Answer accepted when you have a chance.

Best, Joseph

[Lewis West]

No worries, our implementation was a bit different from yours, so Resolution is a drop down for us.  Thanks for reaching out, though.

[Joseph Chung Yin]

Great.  Last note - In the WF, the transition can have a pop-up window where resolution can be selected from a list, or it can be set to a resolution value as default.

Hope my information did assisted/helped you.

Best, Joseph

[Joseph Chung Yin]

@Lewis West -

Resolution field and its population are always done in the WF.  It should not be exposed at issue creation screen.  In addition, this field is always set as READ ONLY.  When an issue moves through the WF status, once it reaches to the terminal status (i.e. RESOLVED), then this field will be populated.

Your team needs to move the issue via the WF statuses as this is the proper way to mark the issue as resolved.  If you don't want to go through all the statuses for an issue, then you can always customize the WF with a transition add to allow an issue to go from the initial status to your terminal status.  In the new transition, just make sure that you add a post function to set the resolution field value if needed.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Lewis West]

Thanks for the quick response.

In my setup, the field is not read only.  The Resolution field is a dropdown with options such as "Fixed", "Done", etc.

I'll investigate the WF and transition you mention.  My goal is that if someone is creating a ticket for something already resolved, they can easily mark it as such, and if they aren't it will still have the default status.

[Joseph Chung Yin]

The field should never be editable.  It needs to be handled via the WF.  If you create any new project, you will see that the field is always READ ONLY and it is populated by the WF.

If you want user to choose the different value for the field, then you will need to add a transition screen and expose the field in the screen.  So, when one moves the issue into the terminal status, it will prompt them to select the appropriate value.  Again, this is done via the WF.

By default, the resolution is typically set to "Done" in the out of the box WF.

Best, Joseph

[Lewis West]

Thanks for the feedback.  It sounds like your implementation is a bit different from ours.

I'll continue investigating options for this.