Add security to issue fields

[AlexNPavel]

Is your feature request related to a problem? Please describe.

A project my team and I are working on depends on the security field from an issue. This currently is not in the IssueFields struct and thus we must use the Unknown field and do some manipulation of types to get a clean SecurityLevel struct.

Describe the solution you'd like

A SecurityLevel struct should be added and a Security field should be included in the IssueFields struct that is of the new SecurityLevel type. The SecurityLevel struct should be quite simple:

type SecurityLevel struct {
	Self        string `json:"self"`
	ID          string `json:"id"`
	Name        string `json:"name"`
	Description string `json:"description"`
}

[andygrunwald]

@AlexNPavel Can you point us to the docs from this API endpoint / field struct?
Or is this part of a plugin?

[AlexNPavel]

The jira docs are pretty poor when it comes to the Fields object for issues as it doesn't list all possible fields. However, it can be seen in some of their examples to create issues, where they just set the ID part of the security level value: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-post.

The full security level json definition is documented here: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-security-level/#api-rest-api-3-securitylevel-id-get.

In the project I am working on, we have our own jira client that mostly just wraps this one and simplifies some setup, logging, error handling, and unit testing, as well as adds some custom functionality. We have a helper to extract the security level from the issue.Field.Unknown struct here: https://github.com/kubernetes/test-infra/blob/01ebd501884d117418415e9b288ed9789845454c/prow/jira/jira.go#L544:L576. As we have the helper, this issue isn't urgent, but it would be nice to have this included as part of the upstream IssueFields struct so we don't need the helper.

[andygrunwald]

Hey,

I am very sorry that this issue has been open for a long time with no final solution. We work on this project in our spare time, and sometimes, other priorities take over. This is the typical open source dilemma.

However, there is news: We are kicking off v2 of this library 🚀

To provide visibility, we created the Road to v2 Milestone and calling for your feedback in #489

The development will take some time; however, I hope you can benefit from the changes.
If you seek priority development for your issue + you like to sponsor it, please contact me.

What does this mean for my issue?

We will work on this issue indirectly.
This means that during the development phase, we aim to tackle it.
Maybe in a different way like it is currently handled.
Please understand that this will take a while because we are running this in our spare time.

Final words

Thanks for using this library.
If there is anything else you would like to tell us, let us know!