Is your feature request related to a problem? Please describe.
The Jira Cloud provider takes transition_to in _notify
(keep/providers/jira_provider/jira_provider.py:557), matches the name against
the transitions Jira offers for that ticket and applies it, both to an existing
ticket and to one it has just created (__get_available_transitions and
__transition_issue, lines 277 and 307).
The on-prem provider's _notify
(keep/providers/jiraonprem_provider/jiraonprem_provider.py:513) has no such
parameter. A workflow that closes a ticket when its alert resolves runs on Cloud
and cannot be moved to Server or Data Center by changing type, even though the
API behind it is the same: /rest/api/2/issue/{key}/transitions, GET for the
list and POST to apply one.
Describe the solution you'd like
transition_to on the on-prem provider, spelled the same way as on Cloud: the
name matched case-insensitively, applied after an update and after a create, and
an unknown name failing with the list of the transitions that do exist.
Describe alternatives you've considered
Calling the transitions endpoint from a generic HTTP step. That means configuring
the personal access token a second time outside the Jira provider and looking the
transition id up by hand for every project.
Additional context
A PR implementing this follows.
Is your feature request related to a problem? Please describe.
The Jira Cloud provider takes
transition_toin_notify(
keep/providers/jira_provider/jira_provider.py:557), matches the name againstthe transitions Jira offers for that ticket and applies it, both to an existing
ticket and to one it has just created (
__get_available_transitionsand__transition_issue, lines 277 and 307).The on-prem provider's
_notify(
keep/providers/jiraonprem_provider/jiraonprem_provider.py:513) has no suchparameter. A workflow that closes a ticket when its alert resolves runs on Cloud
and cannot be moved to Server or Data Center by changing
type, even though theAPI behind it is the same:
/rest/api/2/issue/{key}/transitions, GET for thelist and POST to apply one.
Describe the solution you'd like
transition_toon the on-prem provider, spelled the same way as on Cloud: thename matched case-insensitively, applied after an update and after a create, and
an unknown name failing with the list of the transitions that do exist.
Describe alternatives you've considered
Calling the transitions endpoint from a generic HTTP step. That means configuring
the personal access token a second time outside the Jira provider and looking the
transition id up by hand for every project.
Additional context
A PR implementing this follows.