You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JIRA handles issue states quite differently, so far all backend support open
and closed states but JIRA can have many different states and possible
different parameters when transitioning between states which may or may not be
required.
One solution could be to add a new command:
$ git issue transition <state>
The transition command, when invoked, would prompt the user to input any
required parameters as defined by the JIRA transition screen associated with the <state>. This has the downside of loosing out on command line completions for
the parameters.
A second approach could be to shoehorn the state transitions into the git issue {edit,close,reopen} commands. States which can be transitioned to but could be
augmented using choices given to the user with pick as is already done
to disambiguate user searches. This has the downside of not being a one-to-one
match of transitions available for an issue and possibly counter-intuitive
command names.
Third approach would be to assess GitHub projects and GitLab
boards for any commonalities between the services which might be
more instructive when implementing JIRA support.
The text was updated successfully, but these errors were encountered:
GitHub projects have boards with columns and cards, not unlike JIRA boards and
issues. The nomenclature used there is move instead of transition, this
could be a good name for a possible command.
JIRA handles issue states quite differently, so far all backend support
open
and
closed
states but JIRA can have many different states and possibledifferent parameters when transitioning between states which may or may not be
required.
One solution could be to add a new command:
The
transition
command, when invoked, would prompt the user to input anyrequired parameters as defined by the JIRA transition screen associated with the
<state>
. This has the downside of loosing out on command line completions forthe parameters.
A second approach could be to shoehorn the state transitions into the
git issue {edit,close,reopen}
commands. States which can be transitioned to but could beaugmented using choices given to the user with pick as is already done
to disambiguate user searches. This has the downside of not being a one-to-one
match of transitions available for an issue and possibly counter-intuitive
command names.
Third approach would be to assess GitHub projects and GitLab
boards for any commonalities between the services which might be
more instructive when implementing JIRA support.
The text was updated successfully, but these errors were encountered: