I’m trying to get all fields available on issues in a specific project of any issue type on any screen. This sort of question seems to bubble up once in awhile and the usual tactic is:
use create meta, but that would miss fields that are not on the create screen
use edit meta on the issue, but that is for a specific issue/issue type and may miss fields on other issue types
Now that there are a number of new field related APIs (as listed here Project configuration API has arrived!) I figured I’d reach out and see if anyone knows how to pull this off.
Best as I can tell doing this set of calls gets me pretty close:
GET /rest/api/3/field
This gets all fields in the system, but no choice options. It also doesn’t say which projects they relate to except in the case the project is nextgen.
To figure out whether they relate to a specific project it looks like you need to go through a sequence of calls to figure out which configuration they belong to, ie
GET /rest/api/3/fieldconfigurationscheme/project
GET /rest/api/3/fieldconfigurationscheme/mapping
GET /rest/api/3/fieldconfiguration/{fieldConfigurationId}/fields
At that point it looks like I can thread it back to the original field list to trim it down to ones only applicable on the project, but I’m missing choice information still. Some choices are simple to get:
GET /rest/api/3/priority
Components come back on GET GET /rest/api/3/project/{projectIdOrKey}
For custom choice fields GET /rest/api/3/customField/{fieldId}/option
But that last one doesn’t work on nextgen specific custom choice fields. For example a next gen service desk project creates a “Change reason” single choice field, but requesting the options via that route fails as it only supports “global context” fields. There is a route for getting custom fields created by apps too (GET /rest/api/3/field/{fieldKey}/option) but that requires an app key which I don’t really have from the rest of the output.
I’d like to share with you my idea how to fetch all fields for classic project.
You can call /rest/api/3/issuetypescreenscheme/project?projectId=XXX to get configured issue type screen scheme ID for that project.
Then you can call /rest/api/3/issuetypescreenscheme/mapping?issueTypeSchemeId=YYY to get mappings between issue type screen scheme, issue types and screen schemes.
Now you can check screens for every issue type using rest/api/3/screenscheme?id=ZZZ
When you get sum of fields present on all tabs of all screens - create/edit/view/default by calling /rest/api/3/screens/AAA/tabs/BBB/fields then you have a list of fields used in project.
Eh, it’s quite complex .
According to my knowledge performing such operations in next-gen project is impossible with currently available APIs.
When it comes to getting custom fields option values including non-global context, it’s something that we keep in mind during planning the next steps of extending project configuration APIs, but I can’t share any exact dates when it will be done.
That flow sounds promising, and I would happily make that stream of calls if necessary as we’re not doing it particularly often.
It’s unfortunate that it won’t work for nextgen though. I’m glad to hear that it’s being kept in mind during planning and look forward to new and improved APIs in the future.
We are currently using the flow you described to add a field to issueType screen if it is not there. Did you mean there is no way of doing the same (add fields to screen) with next-gen projects?
sorry for a late response, but I’d like to confirm it with next-gen team. Here is what I heard.
There’s no public API to do that at the moment. In fact, there’s no screen concept in Next-gen project. It will be associating/adding a field to an issue type once we have that public API available.
As far as I’m concerned we currently don’t have any work in progress in that area.
.