Dangerous? Changing workflow for project using JIRA onDemand.

[Thaddaeus Brophy]

Hello,

Anyone have any advice on the following?

1. Does the specific situation outlined below even warrants a backup? If so, how is this known?
2. If a backup prior to the assignment of a new workflow for a JIRA onDemand project is not warranted–to be safe–does there exist a default backup time for onDemand accounts? Note; Atlassian documentation states there is a default 2AM backup on installed systems as well as there is a "every 24hr point-in-time backup for onDemand instances, but does not state at what time.

The specific situation seems simple...

• A new workflow scheme has been created with a newly created workflow.
• The newly created workflow was created by copying the default Jira workflow.
• No states or transitions from the original Jira workflow have been removed.
• Only two states and corresponding local (i.e. not global), transitions were added.

The above questions were inspired by the following...

A notification appearing on the Select Workflow Scheme page in a Project Site Administrative Section.

Note: It is recommended to backup JIRA data before proceeding with the workflow association. You may want to contact a System Administrator to create an XML backup.

A note indicating onDemand backups cannot be used for instance recovery in the event of a bad project workflow assignment???

https://confluence.atlassian.com/display/AOD/About+Your+Data

Point in time backups for your instance are taken every 24 hours for purposes of recovery from application failure. Backups are stored at a location separate from the data center. Use of backup data to roll back changes to application data is not supported. Backups are retained for seven days, and then deleted. All backups are encrypted before being taken offsite.

Any help will be much appreciated.

mr.T

[JamieA]

It's not dangerous, it's an everyday occurrence. The main danger is if you have munged your workflow for example deleting all the outbound actions from Open. If that's the case you just fix it and publish a new one.

The lawyer probably insisted they put that text up.

[Nic Brough -Adaptavist-]

You can always "rescue" a workflow, or even hack one back into shape. The only thing that warrents a lot of care and a backup is removing status from a workflow. If you are removing status, then you'll have to migrate issues with the dying status to a new one, and that could be difficult to undo. There are a handful of things that could "damage" your workflow (as Jamie says, deleting all the outbound actions from Open is a bit of a pain). Hacking around the transistions, tweaking labels and so-on - absolute doddle to rescue, especially if you've kept a copy to refer back to.

[Thaddaeus Brophy]

Jamie, Nic; Thanks for the answers!

It is as you havev stated; either a circumstance of repair involves doodling or is a bit intensive depending on the degree of change to the workflow–esp. in the case of removing legacy states or legacy transitions.

If anyhow, if anyone at JIRA is trolling this thread for requirements, I suggest a User Story that goes something like;

A documentation link is displayed next to the button starting the workflow migration process when the user hovers their mouse near the 'start' button. When the User clicks on the link, a pop-in displays with a small slide deck showing what the process looks like in terms of nr. of screens. Each screen has a caption explaining what the screeen shot represents. Just below each screen shot caption, there is a link to 'more documentation' which is tailored exclusively for onDemand instances.

Again, thanks for the assistance.

mr.T