3 ms·

I think you're underestimating how bad the "something" people can come up with is. Think "weekly status reports to describe how you're doing on fixing a problem

I think you're underestimating how bad the "something" people can come up with is. Think "weekly status reports to describe how you're doing on fixing a problem that was described through email, or an in-person meeting with someone, or a phone call, and never entered into a ticketing system at all". Also the mandatory fields are definitely a per-organization thing. At my org we have I think 3 mandatory fields, which are the project the ticket goes under, the title, and the description. In many cases, "migrating" from JIRA to JIRA but 90% of the features are disabled would probably be an improvement.

stjohnswarts 6y ago
If you don't have scripts that will fetch all your parameters and just have to fill in a couple of fields then you're doing it wrong.
- JoshuaDavid 6y ago
  I do in fact have such scripts :). Also to automatically tag my git commits with the ticket, transition the jira issues appropriately when the relevant things happen with those branches or pull requests, etc. I don't actually interact with JIRA-the-application all that much these days, but in the rare cases when I do it's because I'm doing something non-trivial, and in those cases the UI seems relatively straightforward. ... I suppose that might be the main difference between people who hate JIRA and people who find it a little bit clunky but generally acceptable: people who mostly have the baseline stuff happen automatically are fine with it, and people who spend a lot of time interacting with the web frontend in repetitive ways hate it.
- dijit 6y ago
  Uh... I’m having trouble envisioning this, do you have any examples? I ended up forcing my slack bot to issue POSTs to Jiras API out of frustration.
  - JoshuaDavid 6y ago
    Yes, exactly that. Basically wire up very simple commands with curl and jq that do the transitions you need, pulling data from other rest apis as necessary. The two workhorses of my integration are two methods named jira_get and jira_post. function jira_get { ENDPOINT="$1" PAYLOAD="$2" URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT" QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')" curl \ --silent \ --request "GET" \ --header "Content-Type: application/json" \ --user "$JIRA_USER:$JIRA_TOKEN" \ "$URL?$QUERY_STRING"; } function jira_post { ENDPOINT="$1" PAYLOAD="$2" URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT" QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')" curl \ --silent \ --request "POST" \ --user "$JIRA_USER:$JIRA_TOKEN" \ --header "Content-Type: application/json" \ "$URL" \ --data "$PAYLOAD"; } Then if you want to get the available transitions, and required fields for those transitions, you can do ISSUE=PRJ-1234 ISSUE_JSON="$(jira_get "issue/$ISSUE/transitions" '{"expand":"transitions.fields"}' TRANSITION_NAMES="$(echo "$ISSUE_JSON" | jq '.transitions[].name')" and then given the transition in question, you can look at the fields required for the transition, and figure out where you get the data that goes in those fields normally. Any time the data that goes in those fields is obtained through a rote process, you automate that process, and then prompt for any fields you can't get in an automated fashion (e.g. "signed off by" you can fetch the reviewer names from the github api for the associated pull request). But yeah, a slack bot that issues requests to the JIRA api is a perfectly workable solution, and I think you'd be surprised at how much of a quality of life improvement you'll get by continuing to add capabilities to it that reflect your specific workflow.

stjohnswarts 6y ago

If you don't have scripts that will fetch all your parameters and just have to fill in a couple of fields then you're doing it wrong.

JoshuaDavid 6y ago
I do in fact have such scripts :). Also to automatically tag my git commits with the ticket, transition the jira issues appropriately when the relevant things happen with those branches or pull requests, etc. I don't actually interact with JIRA-the-application all that much these days, but in the rare cases when I do it's because I'm doing something non-trivial, and in those cases the UI seems relatively straightforward. ... I suppose that might be the main difference between people who hate JIRA and people who find it a little bit clunky but generally acceptable: people who mostly have the baseline stuff happen automatically are fine with it, and people who spend a lot of time interacting with the web frontend in repetitive ways hate it.
dijit 6y ago
Uh... I’m having trouble envisioning this, do you have any examples? I ended up forcing my slack bot to issue POSTs to Jiras API out of frustration.
- JoshuaDavid 6y ago
  Yes, exactly that. Basically wire up very simple commands with curl and jq that do the transitions you need, pulling data from other rest apis as necessary. The two workhorses of my integration are two methods named jira_get and jira_post. function jira_get { ENDPOINT="$1" PAYLOAD="$2" URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT" QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')" curl \ --silent \ --request "GET" \ --header "Content-Type: application/json" \ --user "$JIRA_USER:$JIRA_TOKEN" \ "$URL?$QUERY_STRING"; } function jira_post { ENDPOINT="$1" PAYLOAD="$2" URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT" QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')" curl \ --silent \ --request "POST" \ --user "$JIRA_USER:$JIRA_TOKEN" \ --header "Content-Type: application/json" \ "$URL" \ --data "$PAYLOAD"; } Then if you want to get the available transitions, and required fields for those transitions, you can do ISSUE=PRJ-1234 ISSUE_JSON="$(jira_get "issue/$ISSUE/transitions" '{"expand":"transitions.fields"}' TRANSITION_NAMES="$(echo "$ISSUE_JSON" | jq '.transitions[].name')" and then given the transition in question, you can look at the fields required for the transition, and figure out where you get the data that goes in those fields normally. Any time the data that goes in those fields is obtained through a rote process, you automate that process, and then prompt for any fields you can't get in an automated fashion (e.g. "signed off by" you can fetch the reviewer names from the github api for the associated pull request). But yeah, a slack bot that issues requests to the JIRA api is a perfectly workable solution, and I think you'd be surprised at how much of a quality of life improvement you'll get by continuing to add capabilities to it that reflect your specific workflow.