Resolution Reason field mandatory

Question

Hi All,

We need to make the Resolution Reason field mandatory in all Jira projects. Please note the field should be displayed on the screen of Resolved tickets, not Ticket Creation. Current its appearing in Create Issue screen as well. I am new to Jira could anyone show step by step process how to achieve this it would be great to survive in an organisation .

davesoft11 · Answer

Thanks @Joe Pitt . This was extremely helpful:

Resolution Field can't be made optional. DO NOT put the field on any screen except the one presented in the transition where it is to be set. Resolution is a special field in JIRA. It has an initial value of ‘Unresolved’, which means the field is NULL in the database. It is ALWAYS required when it appears on the screen. ONLY display it on the screen during a transition to the status where you want it set. Once it is set the issue ID will appear with as strikethrough. If you re-open an issue the transition from closed to reopen needs to have a post function to CLEAR the resolution field to set it back to Unresolved.

Joe Pitt · Answer

Every setup is different so I can't walk you through the steps. Read the JIRA documentation on workflows and transitions.  You will need to know this and many other things to be a JIRA admin.  Below are some other tips

Do not delete issues. When you delete it is GONE. Hardly a week goes by without someone wanting to restore an issue. Deleting issues will come back and bite you when it is the most inconvenient. I suggest closing with a resolution value of Deleted anything you want to delete. I implement a special transition only the project lead can execute and it requires filling in a reason field from a select list (such as entered in error, OBE, Duplicate, Other) and explanation text.

Deleting issues destroys historical data. Missing issue numbers will eventually cause a question about what it was and why was it deleted even if it was done properly. Missing data always brings in the question of people hiding something that may have looked bad.

The only viable way to restore an issue is to create a new instance of JIRA and restore a backup that has the issues. Then export them to a csv file and import them to your production instance. You will lose the history.

None of my users have delete permission.

If you insist on deleting issues you need the delete issue permission

Do not delete users

Users should be made inactive not deleted. JIRA uses a pointer to the user’s DB entry to display user information. If you delete a user when you open a JIRA issue the user worked on anywhere the user that would be displayed will cause a SQL error. Even if the user never logged on or were assigned a ticket the history of the ticket will get an error when you display it.

Done status showing Unresolved

This is a problem that seems to be cropping up of late. Issues need to have a resolution set. Unresolved means the resolution field is NULL in the database. This means the workflow isn't providing for setting the resolution before going to the status flagged as Done. You need to fix the workflow.

The transition moving to ‘Done’ needs to one of two things; 1. Present a screen where the user sets the resolution or 2. Sets the resolution in a post function.

To correct the existing issues you can add a transition from the done status back to itself with a transition screen to set the resolution or a post function to set it. The other option is to add the resolution field to the edit screen (which you should NEVER do in production), bulk edit the issues to set the field and then REMOVE the resolution field form the edit screen.

Put JIRA under CR

I STRONGLY suggest you treat JIRA like a production system, put it under change control (CR), and track all requests for any updates, especially new projects, new custom fields, changes in any of the schemes, etc. That way at least the reporter will know when the actions happen and you'll have a audit trail. I've worked many similar tools to JIRA and too many times no one knows anything about why they are configured why they are because there is no requirements or CR. Things are just done based on emails that have disappeared and hallway or lunch conversations.

If you don't already have a separate change control tool create a JIRA project. I use a basic workflow with a few custom issue types:

Custom field: with a select list of create, update. The description would be to create a new field or modify a current select list, buttons, etc. of a current one

Create Project: I would have text fields for issue types, custom fields, select list/values, per issue types

New Issue Type: description would include all fields and workflow desired.

Workflow: Select list of Create, update, delete. Description of what needed.

Other: Select list of Notification Scheme, permission scheme, field configuration, other

This should get you started. If you aren't familiar with your CR process there should be a configuration management person to talk to.

The goal is to manage what you do and be able to track who asked for what. For instance, if someone wants a new custom field you want to check to see if there already is one you can use that they don't know about. JIRA will let you have multiple custom fields with the same name, which will just confuse you.

abbas baman · Answer

Hi @Joe Pitt  thanks once again for your support could you please help me step by step guide so I can perform the task because I am totally new to Jira