Can I add a step prior to "create" in a workflow

[StephanieC]

Can I add a step prior to "create" in a workflow that would essentially serve as a request to create a ticket? 

The user story is that we need a way to request a release ticket and fix version that can be tracked with the project it pertains to, but restrict release ticket creation to a group. 

We do have several plugins including scriptrunner, JMCF, and JSU Automation Suite., as well as JSD

Suggestions? 

[Joe Pitt · Accepted solution]

No. The issue number is the primary key in the DB, so until the issue is created there is no way for the database to track it. I suggest you have a workflow step out of the Open status to close the ticket if not needed. Don't delete it. 

[StephanieC]

Thanks Joe ~

I realize that the ticket is created either way, we just need a way to keep the release from progressing if it is not a good fit or has conflicts with other releases. Its more about renaming transitions and statuses in this case. 

Thanks! 

[Nic Brough -Adaptavist- · Accepted solution]

Yes, and no.

Yes, because you can have any status you want as the landing point for "create"

But, no, because once you create the issue, you have a created issue.  There's no "request to think about maybe creating something".  You've created it.

A lot of places do do workflows that have:

• Create -> "We think we need" -> "Open"
• Create -> "We think we need" -> "No you don't, closed"

But you can't work on an issue that isn't there.

[StephanieC]

Thanks Nic~

I get that the issue is actually created, and in 99% of cases, the ticket would deploy - so I like your suggestion of having the option to reject after creation. We do this for most other tickets (bc we do not delete tickets), though the reasoning is different. 

So I could make only the key fields available to the requestor on the create screen for that issue type, call the first Transition "Request Release", then auto-assign to release team at that transition (we have several AD groups as assignees) . A release engineer could pick the ticket, assign it to themselves, and either continue with the release creation process or reject it if the requested release is not viable or has too many conflicts. 

If the release request is rejected, the requestor could reopen it with a new set of dates and it would repeat the process. The next transition (our folks call them "buttons") would be "release approved", which could notify the requestor to associate dev tickets with the release, and then it would progress as usual

Thanks again, I think this will work!

[StephanieC]

Well technically its the second transition, "Create" being the first. :-) 

[Nic Brough -Adaptavist-]

Yes, this will work.  I over-simplified, missing out

"open" -> rest of desired workflow

"No you don't, closed" should have an option to push it back to "we think we need", ideally with some way to qualify or justify why it should be don.

[Stefan Forstmoser _beecom_]

You could also solve your requirement by having a separate issue for the Request in another project (where everybody has access).

When the Request issue is approved, a new Release issue is created. To achieve this you can use the 'Create A Linked Issue (JSU)' post function in the Approve transition of the Request.

You can find the documentation of that post function here:

https://confluence-apps.beecom.ch/display/JSU/Create+a+Linked+Issue

And some similar use cases:

https://confluence-apps.beecom.ch/display/JSU/Testing+and+Fixing+Bugs

https://confluence-apps.beecom.ch/display/JSU/Management+Approval