Hi,
I am using REST API https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-workflows/#api-rest-api-3-workflows-post to get workflows with WorkflowStatusLayout (x & y position for statuses on a layout).
Almost for all cases it works perfectly fine. However I have made some tests and figured out it returns null WorkflowStatusLayout property for each status when workflow has been never edited, I mean when workflow.versionNumber = 0.
Whenever I publish a new version of the workflow, even with no changes (just click edit & publish) in Jira the version is incremented to 1. After that WorkflowStatusLayout is returned properly by the REST API.
I wonder why WorkflowStatusLayout property is missing for workflows with version = 0?
Seems to me like a some sort of a bug.
I would appreciate any help
Regards
11 Likes
@ibuchanan are you by any chance able to help on behalf of Atlassian? 
@KatarzynaSzumilas and @mklempka,
I think the reason has to do with incremental roll-out and making safe database changes. We use a technique that we call “fast five”:
- Stage 1—the software is running as-is.
- Stage 2—we deploy a version of the software that at least has code to handle data in the current and next state.
- Stage 3—we update the data. It’s more than likely the task to do that is part of the code deployed in stage 2. We just trigger that task at a suitable time. This allows us to not leak data changes all the way through to the behavior layers.
- Stage 4—we alter the code that exhibits external behavior. It’s also quite likely this code was already present in the deployment at stage 2 but was disabled behind a feature flag.
- Stage 5—the new functionality has been fully deployed and all users are engaged with it. We can now delete the obsolete code in a future deployment. Finalizing database refactoring (e.g. deleting columns that are no longer used) would be part of a subsequent cycle of this sequence.
One of the specific ways to implement Stage 3 & Stage 4 is “change on write”. That way, if the feature hasn’t been deployed, the feature doesn’t get data it doesn’t expect. Only the new feature can generate the extra data, which isn’t there if the new feature has not been activated. So, it’s not a bug; it’s the intended behavior in the context of features that require database changes.
Technically, I don’t know this is the reason 100% but I inferred it from past experience. While the question was “wonder why”, I suspect there’s more to that question. Could you help me understand more from the app or client perspective what is problem with handling missing keys (or null values)?
@ibuchanan
In our app we have custom implementation of displaying Jira workflow diagrams to the users.
We want it to be as close as possible to the Jira view on path:
JIRA_URL/secure/admin/workflows/ViewWorkflowSteps.jspa?workflowMode=live&workflowName=WORKFLOW_NAME
Basically we need position (x, y) for each workflow status on the layout.
To fetch workflow data we use https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-workflows/#api-rest-api-3-workflows-post
which according to the documentation returns response including the layout property for each status:
We use the layout properties to set statuses positions in our frame.
The problem we observed is that this property is included only for edited workflows - with “versionNumber” > 0.
So for example, when I create a brand new workflow. The API mentioned earlier won’t give me the layout properties. Even if the workflow is properly displayed in Jira admin section.
To summarize, we noticed that the API method bahaves differently depending on whether the workflow was ever edited or not.
