Format as JSON?

[mhanberg]

Hi!

This tool looks really cool. I am curious if it is possible to format output as JSON? I am interested in writing a JIRA completion source for Neovim, and being able to work with JSON output would make that very easy.

Thanks!

[ankitpokhrel]

@mhanberg this CLI tool is created for a different purpose (mostly for day-to-day work with jira using TUI) and adding json output will just complicate things. For json output, you can use tools like httpie or curl to call the API directly.

http GET https://<server>/rest/api/2/issue/ISSUE-1 --auth "<user>:${JIRA_API_TOKEN}"

[eliasdorneles]

I still see value on a --json output, it would make it easy for a user to create scripts, reusing the already existing configuration for jira-cli.

Currently I am doing things like:

jira_user=$(grep login: ~/.config/.jira/.config.yml | sed 's/login: //')
jira_auth="${jira_user}:${JIRA_API_TOKEN:-}"

api_call() {
    curl --silent \
        --user "$jira_auth" \
        -H "Content-Type: application/json" \
        -X "$1" \
        "https://jira.atlassian.com/rest/api/3/$2"
}

[etosan]

@ankitpokhrel while I understand where you are coming from (ie deeper integrations are better done directly through REST APIs), your tool sufficiently abstracts several key differences between on-prem and atlasian-cloud JIRA versions. I do have clients which use both.

Also besides naive TUI usage, this tool is very good for drilling down into projects for project management and searching issues etc. ie what I call "drilling down". Finally IT IS several orders of magnitudes faster than messing around with WebGUI in atlassian-cloud - which is getting atrociously slow for some tenants.

Finally I understand your stance on scripting, from dev's systems/integration point of view, for organizations, but you are disregarding one most important niche of integration, which overlaps with area, where your tool provides the highest value: personal/power-user integration/scripting.

As I said already, I now have several clients, either multitenants in atlassian-cloud or with on-prem instances, and some of them have several dozens plus of projects. I must already resort to using aliases and scripts to manage the chaos (which I am not complaining against), ie. I am slowly building outer layer of scripts on top your tool.

It still provides insane value to me, because it abstracts lot of chores when communicating with JIRAs, and is quite shell/exec/sub-process friendly, especially for some quick and ad-hoc duct-taping - especially when "drilling down" into "project dataset" - but these days more often than not I would really welcome JSON output, just as many others.

JSON can be parsed automatically and consumed relatively safely in any language (escaping issues and stuff), even in shell (using jo and jq). Imagine how flaky it is to extract stuff from jira-cli issues list --plain --bla-bla with sed grep and awk to get to some data - it works, but it is becoming sub-optimal at some point. I would really love to be able to pipe to jq and have stuff selected a mangled according to my immediate needs there.

Not mentioning easing completion integrations and stuff, as somebody already pointed out. I bet it would be really useful addition to this tool for a lot of people.

If however, you consider this extension not wroth the effort, do you have any suggestion for "shell" / "pipeliling" / "data-pipelining" friendly tool similar to yours (ie. abstracting generic JIRA access), but that can return JSON data?

So far I have found only some python stuff and jira-go library, but I would rely prefer something designed as static binary, written in go, that can be shared among colleagues and organization easily, same way other go binaries can be. Any hints?

[JonasToth]

Thank you for this great tool!

I want to add my +1 for this question. I am creating a nvim-plugin to get the daily issue information available in the editor, and allow simple change.

E.g. list all my bugs, open a specific issue, comment on it and close it.

The plugin itself sits on top of CLI tools (gh, glab and hopefully jira at some point). This makes the development much easier, because the CLI tools are concerned about API compatibility with the service, and my plugin is concerned about integration of the results.

If there is a way to achieve some form of JSON, that would be great!
I know that the gitlab/github concepts of issues don't map nice to Jira.