Which basic knowledge should I have before starting with Jira?

Huwen Arnone [Deiser/Devoteam]

I recently got engaged in this conversation started by @Jack Brickey, where he asked, "How did you learn to be a Jira admin?" a conversation that threw inspiring answers; there I made this same question I'm doing here, and I'm repeating it because I would love to have others people perspective.

I must say @Nic Brough -Adaptavist- took the time to answer in a very detailed way, which was enlightening to me. So, I decided to give more exposure to this question because I would love to learn about other perspectives, if any.

Regarding my question, Do you think it is necessary to have a specific career or expertise to become an expert Jira Admin? Which advice do you have for someone who wants to learn more about it? Should I start with coding?

Thanks in advance for your answers! 😎

Joe Pitt

I started working with Jira in early 2007. These are answers to questions that have often come up in this forum by new people. 

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.

 Resolution Field

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.

 Limiting resolution options

Use the jira.field.resolution.include workflow property

for exampl jira.field.resolution.include =1,2,3  where 1,2,3 are the resolution ids

https://confluence.atlassian.com/adminjiraserver071/workflow-properties-802592825.html

 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.

  Notifications

I have found the default notification scheme is overkill everywhere I've setup JIRA. If you haven't setup the default user profile to exclude sending updates they make I suggest you change the default and have all the users modify their profile.  Talk to your users to see what they want. Most reporters want create, close, and maybe one or two other milestones statuses depending on the issue type. You can easily create custom events to put in the transition post functions for those events. If you allow people other than the assignee to work on the issue the assignee may want notification of things they do, especially update and comment. 

 Empty field not showing on detail screen

JIRA only shows fields with values. I had management complain about it and forced me to put a default value, TBD, so the field would show. It was a disaster. Over 50% of closed issues had TBD as the value.  In practice, people don't fill in fields that aren't required and they don't change fields with values.

 Can I have Different Required Fields for Different Issue Types?

Yes, as long as it is a different issue type. Required fields, at creation time are controlled by the field configuration scheme. That scheme is composed of one or more field configurations. Every issue type can have its own field configuration inside the field configuration scheme. If you have 5 issue types and 1 has special needs you create a field configuration for the 4 issue types and another for the 1 issue type. Then you combine them into a field configuration scheme and apply that to the project. When an issue is created, it looks for a field configuration for that issue type and uses it. If it doesn't find one it uses the default in the configuration scheme.  Copy/paste this link for more information. https://confluence.atlassian.com/adminjiracloud/configuring-a-field-configuration-scheme-844500805.html 

 Assigning issue to multiple users

I got this from another post and does an excellent job explaining the issues. First of all, I want to emphasize that this is not a good idea. To assign an issue to multiple users is always a bad idea and you should always avoid it if you can. This is because, it's against the nature of Jira itself and it creates a problem with accountability. If an issue has multiple assignees, than you can't know who is truely responsible and also who did the most work, so it messes up the performance statistics. 

But, if a customer wants something, they want something. All you can do is explain why this is a bad idea and convince them otherwise but still commit to the idea. We got this question from multiple customers so we decided to at least create a solution and this is what we did:

• Firstly, we create different mail groups/distribution lists for different teams. For example; we have a mail group called sales@examplecompany.com and all the people in sales team are in this mail group.
• Second, we create a Jira user using this mail address. Remove the user from the logon groups so it doesn’t count toward your license count.
• Then we create a workflow that assigns certain issues to this user based on something. This something can change according to your workflow, it can be a custom field value or a text parsed from summary or group that the reporter is in. 
• Then we create filters such as : "assignee = sales@examplecompany.com AND status = Not Assigned Yet". At this point we have different filters such as: Sales Issues, Marketing Issues, HR Issues etc. We also create dashboards with gadgets specific to the teams so that they can only be bothered with their own issues. You can also use queues if you use Service Desk.
• We also set the notification scheme to send mail to the assignee when the issue is created.
• Finally, all users look at the related filters or dashboards to their team and the user who first sees the issue assigns it to themselves.

Customers who mostly use this system uses a performance evaluation based on how many issues a user solves. Again, this is not an ideal solution but this is how we solved it.

Hope this helps someone out there struggling with this issue.

Backlog has ‘Done’ issues

There have been several posts about next gen projects showing 'done' without a resolution value. The 'done' status should only have issues with a valid resolution. It may be a problem with how your done column is setup. It should have issues in one or more statuses WITH a valid resolution. In most cases workflows where not setup properly. The workflow should either allow the user to pick a resolution from the transition screen or set the resolution in a post function when moving to a status mapped to 'done.