Hi,
as stated in the changelog (Atlassian developer changelog) we are required to update to this new API endpoints to bulk create workflows:
https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-workflows/#api-rest-api-2-workflows-create-post.
The docs define, that all workflows include layout position information and properties on statuses, that we do not know and don’t need to know to create a working workflow. I cannot find more documentation to properties on statuses.
Are some of the fields not really required or could you improve your endpoints API to make layouting of the workflow graph not necessary?
Transitions are defined with IDs. What shape must these IDs have for creating them?
The documentation suggests but does not clearly say, that it is possible to create all required statuses on the fly for all defined workflows. Is this possible? If so, why is statusReference required? What is the statusReference to create the status?
If it would work that way it would be make our implementation a lot easier to provide customers with our required workflows and statuses with out-of-the-box experience.
Ok I found out by myself, that statusReference is a self-defined UUID which is unique across the request. The documentation is not clear to this.
1 Like
This is an old thread, but I’ll flag this with our team.
The idea here is that we want to allow you to create all your necessary statuses dynamically or use existing ones as needed. The statusReference serves as the tool to facilitate this process across this API. New statusReferences are self-defined UUIDs and unique within the request.
To create a new status, you would include a status in the payload with only a statusReference and no id, then reference it within the workflow. If you wished to use an existing status in the workflow, you should first locate it in Jira, add its details to the status list with it’s existing id and a new UUID for it’s statusReference, and then incorporate it into the workflow statuses and transitions.
Then, when updating or creating the workflow, we will first create and update all the statuses, and then integrate those statuses into the workflow. Please note that this approach only applies to statuses referenced in the workflows. We provide more general APIs for managing statuses externally to the workflows.