Default transitions and creating new transitions for smart commits

Question

Hi, I can't seem to find the answer to this. I've read the smart commits documentation, and I'm confused by a few things. I'm using Jira issues (stories within epics, using an agile/scrum type project).

Firstly, after reading the documentation I presumed that #close was something I could use automatically. It wasn't until it didn't work that I looked at the edit workflow screen. The only transition I saw on there by default was the "Create" transition.

I added a "close" transition between both the default "TO DO" and "IN PROGRESS" statuses to the "DONE" and then made a commit with "#close" in there and that did close it as expected.

As a side note, I also tried a commit with "#resolve" in there but even though it's in the Smart Commits page, I presume that's just for regular issues in BitBucket?

Are there any "default" transitions? Any that aren't shown on the edit workflow page? Or do all transitions have to be created by myself beforehand. The documentation doesn't talk about this from what I can see.

Also, I see when I click a status, you can select the "Allow issues in any status to move to this one" checkbox in the transitions section. When I click the name on said transitions, it shows for instance, in a greyed input, "Any status moving to “Done”. I'm a bit confused as to what this means.

Many thanks for any advice and links to documentation or community posts I may have missed.

legecha · Answer

Hi Andy,

Thank you for the thorough reply. This explains pretty much everything.

I noted after some further tests that you can also set a status, not just a transition, for instance #in-progress could set a story to the IN PROGRESS state even if there wasn't a transition with that name. Maybe it would be helpful to make this more clear in the documentation too.

Thanks again, I'm really loving the suite of tools!

Andy Heinzer · Answer

Hi @legecha

I see that you have found a problem in our documentation of using smart commits.  The close transition is not commonly found by default on any Jira workflows.  Hence that example in the documentation isn't likely going to be possible for most Jira projects.  I have requested that our documentation team update that example to help clarify here.

In order to be able to call a transition from a commit or pull request, you have to know the transition name to call for that issue.  So using a #resolve could work, but only if the workflow that issue in Jira is using has a resolved transition that can be called from the current state that Jira issue is in.

There is a good guide on how you can customize workflows within Jira Company managed projects over in Work with issue workflows.  It's a good start if you're not familiar with making these changes.  The workflow editor in Jira has two modes: text and diagram.  The diagram mode will show you a visual of the statuses and the transitions between them, but it also shows you the create transition.  This is a special system transition that smart commits are not expected to be able to call since they require an issuekey, and at the time the create issue is triggered there technically is not an issuekey yet.

As for default transitions, well it depends on the type of project you have selected. There are no universal transitions within Jira (except maybe the create transition, but again this is not accessible from smart commits), only those that are defined within the workflow itself.  Most commonly these are "In Progress" or Done.

In regards to "Allow issues in any status to move to this one", this is part of how you can configure a workflow in Jira to allow you to call a particular transition regardless of the current status/state of the issue.  Workflows can be setup in such a way that there might be a complex and restricted set of steps that must be followed.  In such cases, the diagram editor will show you that each box is connected to another to make sure that all issues follow this workflow.  The option you mentioned is a means to allow a transition to always be available.

I hope this helps.

Andy