to "archive" JIRA projects before actually deleting them, we assign them to en empty permission scheme so that no one can even browse their issues any more but we're able to get them back online if necessary.
We'd also like to keep workflow schemes clean and remove archived projects from the running active set.
Using the default scheme or even creating an "archived" scheme would force us to migrate all issue statuses to some reduced set. That would cause some confusion if the project is back online.
On the other hand, replicating all possible statuses in the "archived" scheme would make little sense.
Is there any common practice or suggestion to do that ?
You've actually answered your own question!
There's not a lot else you can do here than having an "archive" workflow that contains every status possible (at least it has the blessing that you don't need any transitions in it though!). You would lose no data if you moved issues into a project that used such a workflow or moved a project to using that workflow, and you'd be able to revert back if you changed your mind without needing to think.
Most of the Jira system I've looked after have a single "archive" set of schemes (one notification to send nothing, one permission for admin only, or read-only, one workflow etc), all set up so we could flip out of "archive" if we needed to, without losing any data. It's a mild faff to set up, and you do have to maintain it (getting admins to update the workflow if there are new status, and ensure custom fields are all shared with it and so-on), but it really is the simplest approach, unless you have the upper levels of DC or Cloud that do archiving.
hello @Nic Brough _Adaptavist_ , I have the same question which is raised here.
What is for you an Archive WF ?
Is it a WF with prefix ARCHIVE : <nme of the WF> or is it the fact that WF is Inactive ?
If teh WF appears in the nactive list, it can be potentially deleted by mistake and if we recover the archive project, its associated WF will be gone ?
Thanks for clarification
It's a workflow that contains all possible status, so we don't lose the current status of an issue when we flip a project over to using that workflow (done so we can delete the original workflow that we won't be using any more)
It won't appear in the inactive list, because it is in use by (archived) projects.
You take off whatever it is that marks a project as archived.
In DC and Cloud Premium systems, it's a simple flag. In server and standard Cloud systems, there's no archive function, and people do varying things to "archive" - usually change the permission scheme to one that disallows any change in the project.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events