meta data is not populated for jira create

[gvol]

I see the full json (with fields and allowedValues) coming back from the jira createmeta request (with -v -v -v, but it doesn't translate into the output. Looking at it a little, it seems that jiradata/IssueType.go doesn't have Fields defined. Do I need to update the schema somehow? Maybe running schemas/fetch-schemas.py against my instance of Jira? I can send more debug information if desired.

[udryan10]

Confirmed that adding Fields property gives correct behavior. It looks like fetch-schemas.py is pulling the definition from https://docs.atlassian.com/jira/REST/cloud/#api/2/issuetype-getIssueAllTypes which, for some reason, does not have the fields property documented. This is causing the auto-generated type IssueType to leave it out.

[thedillonb]

If simpletons like myself get here, to get this to work, as @udryan10 suggested, put the following into IssueType.go's structure:

Fields      FieldMetaMap `json:"fields,omitempty" yaml:"fields,omitempty"

rebuild and profit.

[mivok]

I'm also hitting this issue, which is resulting in jira create not showing all the relevant fields when creating a new issue, and dug into it a little.

The short version is that it appears that the behavior of slipscheme (used to generate the files in jiradata) changed since the last released version and so make generate is generating two IssueType.go files, one overwriting the other, with the one that createmeta uses being overwritten. I believe the solution is for slipscheme to be fixed to avoid this naming conflict and for the relevant jiradata files to be regenerated.

And the longer version (which ended up way longer than I intended):

From what I could see initially, the issue appeared to be that jiradata/IssueTypes.go was referencing IssueType, which had the wrong fields in it. However, there is a CreateMetaIssueType type, that has the correct fields, so changing IssueTypes to reference CreateMetaIssueType (and fixing the types in issues.go and a couple of other places to get rid of compile errors) fixed the issue.

However, it appears that the files in jiradata/ are all autogenerated, and manually tweaking things until they worked didn't seem like the right fix, so I tried running make generate to see what came out. I did this with the latest released version of slipscheme (0.0.2) and aside from a few minor fixes (e.g. JQL becoming Jql and changing a type back to IntOrString in Attachment.go) this worked. It updated the CreateMeta and child types correctly, and the jira createmeta command showed the fields. When I used the latest version of slipscheme from master however (I realized that the latest released version of slipscheme didn't do the comments correctly in the generated files), I hit the issue again.

From what I can see, when the jiradata files are generated using the latest master of slipscheme, there is a naming conflict for the IssueType type, which is generated from both schemas/CreateMeta.json and schemas/Project.json, with the one generated from Project.json winning. In the older, released, version of slipscheme, the conflict appears to be avoided by prefixing the IssueType type name with CreateMeta (hence the CreateMetaIssueType type being present, but not used), but somewhere along the way this behavior went away.

It looks like, if slipscheme is changed so that it creates CreateMetaIssueType instead of just IssueType when processing the CreateMeta schema, then the jiradata files are regenerated and type errors fixed, that would fix the issue while still having the jiradata files able to be autogenerated.

[coryb]

I have merged in PR#127 to add the Fields field to IssueType and added a unit test to make sure we dont lose the field if we have to regenerate the jiradata types.

Thanks all for looking into this.