JIRA Version 7.5.0
This morning, it was brought to my attention that a key component of our workflow was no longer functioning. I have not yet been able to uncover why. Our workflow is configured so that when an issue is created, it goes into "Open" status, which is our backlog status. Optionally, when creating an issue, our users can update a custom field (radio button) on the create screen titled "Backlog Override", changing the value from Backlog to Ready for Development. Doing this triggers a post-function to transition the newly created status from Open to Selected for Development. This feature worked successfully until this morning. We had not yet updated from 2.2.42 to 2.2.43 at the time we discovered this. The problem did not go away after updating the plugin either.
While investigating, I uncovered another part of the workflow no longer functioning as intended, which is also related to writing statuses or executing transitions with a post-function. In this case, our subtask workflow is configured in such a way that when transitioned to Peer Review, a linked Peer Review subtask is automatically created. In the event that the assignee of the original subtask decides to preemptively reopen their issue (in case they discover they messed something up before their peer discovered it), it triggers two separate post-functions, the first of which moves the peer review subtask into "In Progress", and the second which moves the same peer review subtask now into "Closed" status with "Rejected" resolution. Thought this feature worked successfully previously, it now only fires the first post-function to move the peer review into progress. Alternatively, if the peer review is already in progress, it will then fire the second post-function to move the peer review into closed with rejected resolution. Essentially, the workflow seems to no longer want to change the status of the same subtask twice within a single post-function. I wouldn't have thought much of it except for the fact that it used to work.
The second issue isn't a big deal to me. I can easily remedy that by making a hidden transition from open to closed statuses on peer review subtasks which is fired when the original subtask is manually reopened. But I did bring it up because it IS a function that no longer seems to work and because it felt possibly related to the first issue, which is a much much bigger deal for us. A tremendous key to our operations has to do with extensive backlog grooming sessions, which will only become more timely and complicated if we are having to filter through items that never belonged in the backlog to begin with. Any help you can offer would be greatly appreciated.
Here is the configuration of the "Create Issue" transition for standard issues.
This is the configuration of the "Reopen transition for subtasks
I am also attaching the logs for our instance from around the time I attempted to create a test issue with the backlog override field set as Ready for Development and it failed to transition the issue into the next status (About 9:41 or 9:42). It does not appear that there are any errors registered in the logs....it's just not executing the transition. (You'll notice tons of error related to a JWT calculated field titled "Time in Current Status". This is unrelated and unfortunately happens every time we create an issue, but isn't critical and it always calculates successfully into every other status.)
Last note: There are at least 5 other places within our workflows where the Issue Status or Execute Transition virtual fields are set with a post-function, and they are all working appropriately. Which is why it seems like this error is specifically related to writing two statuses on the same post-function (no status to open to selected for development on issues, and then selected for development to in progress to closed on peer review subtasks), though I can't prove it.