So I have added a Custom Field to my App’s Manifest as follows:
jira:customField:
- key: environment
name: Environment (TM)
description: Indicates in which enviornment the bug or test occured
type: string
collection: list
Depending on certain actions that the users do within the App (Custom UI), the field should list different options that the users can then select on the Issue.
Unfortunately, I get an error 400 when trying to create contexts for the field via API:
const payload = {
name: `${req.context.extension.project.key} Project`,
description: "A context used to define the custom field options for Business Process.",
projectIds: [req.context.extension.project.id]
}
const response = await api.asApp().requestJira(route`/rest/api/3/field/${req.payload}/context`, {
method: 'POST',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json'
},
body: JSON.stringify(payload)
})
The idea is then to use the created context to create options.
Is this the default behaviour? And if so is there anyway to achieve what I am trying to do?
Defining contexts programmatically should be possible for Forge custom fields, just like for regular custom fields. Aside from the 400 status, do you get any error message? Perhaps it would shed some light on the issue.
It looks like you can’t modify contexts of Forge custom fields after all. This is something we will need to look into and decide if it’s really the intended behaviour.
For now, you can try using the Storage API for storing your field data instead.
@kkercz , bummer, The users should be able to select on option from a list of options displayed. The list of options changes according to what the users do on the app. So I store this list of options in the Storage, but how do I go on to show this list when the users click on the field as to edit it?
I am guessing I will need to add an edit: resource to the custom field? I haven’t been able to find any example as to how the implementation looks like.
Which I am guessing is the right way of doing this. I then fetch the stored fields to render as options, and figure out how to submit the values (with view.submit(fieldValue) I am guessing).
That is really a chore, and the UI looks suboptimal, I am guessing the modal has to be there?
Yes, I’m afraid that on the issue view, editing in a modal is the only option.
By the way, I’m assuming you want to use the custom field module specifically, so it probably won’t help, but if you used the custom field type module to provide a custom field type that a Jira admin could use to create a field instance of, then that custom field instance would have access to contexts as expected – it wouldn’t be locked like custom fields are.
@kkercz as I saw from this thread CustomFieldEdit on create screen - #2 by iragudo, the CustomFieldEdit from UI Kit looks to provide a better UX, my question is, I have Custom UI App where I point my Project page and Global page to, but is it possible that I point the CustomField entry in the manifest to a UI Kit function which then uses this CustomFIeldEdit element?
Otherwise I will have to create the fields that my App uses via API, which results in unlocked fields, but is critical if the users modify something which may result in unwanted behaviour.