JIRA doesn't have the functionality. There is a paid for plugin that allows that (project manager I think) but I don't know if you can install it in Cloud.
Neither does any other version of JIRA. Behind the scenes JIRA assigns an id to every component and that is what is uses for everything. So even if you have a field called LastName in two projects they won't have the same ID. So moving a project and all the components JIRA would need to find a way to convert the incoming project to the new project fields if the are named and designed the same and update the database to create all the new fields. Then there would be the issue ID to deal with.
Since you're new her are some tips that trip up many new folks
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
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 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.