nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

Joe Pitt

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.

Nic Brough -Adaptavist-

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.

All comments

Joe Pitt

Nic Brough -Adaptavist-

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

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!

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

scriptrunner

jira

jira-service-desk

jira-server

transition

workflow