Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to create issue due to additional required fields #36

Open
allout58 opened this issue Jul 11, 2019 · 5 comments
Open

Unable to create issue due to additional required fields #36

allout58 opened this issue Jul 11, 2019 · 5 comments

Comments

@allout58
Copy link

What it should do

Find required fields, and allow inputting required ones

What it does

Fails to create a new issue because some fields are required for new issues on our Jira projects.

Other Info

After looking into the Jira API a bit, the expand query string can be set to get all fields on an issue type. However, with many projects this can be massive. I would suggest waiting to fetch a more detailed set of metadata until after the user has selected the project at the very least, maybe even better to wait until they have selected the type. The request can then be filtered down by project name and issue type to limit the returned data (see https://docs.atlassian.com/software/jira/docs/api/REST/8.1.2/#api/2/issue-getCreateIssueMeta)

@miguelmich
Copy link
Member

This could be fairly easy to implement as you said, however, I'm thinking how we can implement this when creating issues without the interactive mode, any ideas?

@miguelmich
Copy link
Member

One temporal solution, if the project and issue type are provided and it has additional fields, enter into the interactive mode to ask for those required fields: jira create -p PK -t bug -m "My issue name" (ask for the required fields interactively) what do you think?

@allout58
Copy link
Author

Maybe provide a "generic" flag where you could pass some kind of set of key value pairs for the additional fields, maybe just a plain old JSON object (which would be cleaner to parse, but might be harder to type). I don't know about the flag parsing library you are using, but if you are allowed to repeat flags, you could do like -c "key: value" -c "key2: value2" to allow for multiple fields to be input.

The "go-to-interactive" thing seems like a decent stopgap, but looses some of the power you get to automate things when you have everything as a flag.

@miguelmich
Copy link
Member

@allout58 that sounds good, and it's supported by commander, now I'm thinking about the data type, is it always text?

@allout58
Copy link
Author

Here is an example of the types for the project I found this issue on originally.

["issuetype","array","string","project","option","timetracking","any","date","user","priority","issuelink"]

It looks like just strings should be okay, as my guess is all of these would have to be typed as strings for the JSON request anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants