To restore from a backup you will over write the current data losing any updates you've made since then. this includes all issues, screens, workflows, etc. As you expand JIRA use you'll find the default schemes have much more than your project needs. I suggest creating your own schemes to use in projects and not use the defaults. Since you're new below are some things new users off have issues with and seek advice:
JIRA permissions
First, by default JIRA has a horrible permission scheme that violates security best practices by allowing everyone that can logon to do just about everything.
JIRA works by GRANTING access. You can't restrict access. By default, it grants access to the group used to logon (see Global permissions to see the "can use" groups and admin groups). This is where users are getting the access from.
- The FIRST thing you need to do to get control is to remove any groups with logon privileges from the permission scheme. unless you absolutely want everyone to have that permission.
- Then I suggest you setup Project Roles for the various functions like, tester, QA, Browse Only, etc.
- By using roles one permission scheme will cover all projects. The project admin controls project role membership
- If the project leads want everyone that can logon access to the project they can add the logon group to a project role with the desired permissions.
This may be a big effort, but it will pay off down the road by making it easy to control access.
Most of the 'old timers' use project roles. It meets the best practice for security and gives complete control to the project lead for access to their project. JIRA comes with many project roles, but you can add more if you have a special need.
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.
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.
Put JIRA under CR
I STRONGLY suggest you treat JIRA like a production system and 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.
Approvals
You want several groups to approve an issue before proceeding. It requires a bit of work on the workflow, but simple stuff. I use project roles for user permissions.
Create a select list for each area with N/A, Yes, No options
Create a transition from the status where you want them to approve for each group with the condition of only users in 'that' project role can execute it and the related select list must be empty. Each group will only see their transition and it isn't set. Have the transition go back to the initial status.
As each group completes the goes through their transition to approve or deny the transitions will disappear.
Now you need to decide how to proceed if there is a No selected by any group. I usually open a transition to a status of something like Rework Needed, or More Information Needed. and then go through the approving status again. If all options are Yes of N/A I make a transition to the next status available.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.