-
Improvement
-
Resolution: Unresolved
-
Major
-
None
We are using the jira ext plugin to set JIRA issues to the status "Live" when they get deployed. We often have the case where the status has been set manually before. In such cases it would be great, if there was a way to prevent the plugin to trigger the transition again, if the Before status and After status are the same.
[JENKINS-32913] Prevent transition if status wouldn't change
flaimo flaimo
added a comment - I have attached the workflow (jira agile workflow) and board as screenshots.
The basic use case, which already works, looks like this:
1) Developer finished his code review and deployment tasks by merging into the master branch and manually changes the ticket status to "done"
2) Jenkins job pushes the new release to the live servers
3) The plugin changes the status of the ticket from "done" to "live" → Because of jira e-mail subscriptions the product owners get an email that the status has changed to "live"
Now there are two corner cases which cause unnecessary status transitions:
a) The developer set the status to "live" manually by accident before the jenkins job was triggered
b) Some tickets, that are part of a base library, are checked out with every deploy. This means the plugin triggers the transition to "live" for some tickets over and over again, which were already set to "live" by a previous job.
The problem is, that in both cases our product owners get status update mails for tickets that have already been set to "live" once. The problem could easily be solved, if there was an option in the plugin that, if activated, would check the status of every ticket it is about to do a transition on and if the current status is the same as the status after the transition, it should just skip the issue. So in the two cases above transitions from "live" to "live" should be skipped.
flaimo flaimo
added a comment - I have attached the workflow (jira agile workflow) and board as screenshots.
The basic use case, which already works, looks like this:
1) Developer finished his code review and deployment tasks by merging into the master branch and manually changes the ticket status to "done"
2) Jenkins job pushes the new release to the live servers
3) The plugin changes the status of the ticket from "done" to "live" → Because of jira e-mail subscriptions the product owners get an email that the status has changed to "live"
Now there are two corner cases which cause unnecessary status transitions:
a) The developer set the status to "live" manually by accident before the jenkins job was triggered
b) Some tickets, that are part of a base library, are checked out with every deploy. This means the plugin triggers the transition to "live" for some tickets over and over again, which were already set to "live" by a previous job.
The problem is, that in both cases our product owners get status update mails for tickets that have already been set to "live" once. The problem could easily be solved, if there was an option in the plugin that, if activated, would check the status of every ticket it is about to do a transition on and if the current status is the same as the status after the transition, it should just skip the issue. So in the two cases above transitions from "live" to "live" should be skipped. Ah okay, interesting, so you can transition the ticket to "Live" when it is already "Live". I hadn't considered a workflow having transitions to the same state.
flaimo flaimo
added a comment - Those "every state to every state" transitions are the default, if you create a new project with a Kanban or Scrum template in JIRA Software.
flaimo flaimo
added a comment - Those "every state to every state" transitions are the default, if you create a new project with a Kanban or Scrum template in JIRA Software.
https://confluence.atlassian.com/agile/jira-agile-user-s-guide/configuring-a-board/configuring-columns/using-jira-agile-simplified-workflow 
Hi, can you describe the states and workflows so I can understand the problem better.
For example, do you have:
open -> in progress -> closed
Where 'start work' is the transition name to move from open to in-progress, and you want to use that only if the transition is 'open', but not 'in progress'?
If so - what is the behavior you see today?