Visible Custom field should be writeable using the Jira API with default configuration but is not

Hi there,

I was in discussion with kchan who pointed out this seems to be bug that needs to be fixed.

He pointed out that:

Custom Field needs to be set with both a Screen and a Context in order for the Custom Field to appear in the UI, or be editable by your app.

However this is almost how it works, but not quite. I am specifically looking at the custom field Story Points, which
a. is associated with the Default screen
b. permission to edit is set through the Default configuration scheme - as can be seen further below

Let’s go through this:

1. Create a new project in Jira:
Default Screen configuration is set follows: (notice I skipped fields that come after Story points)
Screenshot taken from: https://YOURSERVER.atlassian.net/secure/admin/ConfigureFieldScreen.jspa?id=1

2. By default users can view and edit story points
Notice the text, we display fields you have permission to edit. We can easily confirm we indeed have permission to view and edit story points for issues of type: Epic, Story or Bug, as can be seen here:


3. What permission grants this access?
The permission to View and Edit story points is set by the “Default Configuration Scheme for Story Points”, as can be seen here:


Screenshot taken from: (set the customFieldId corretly) https://YOURSERVER.atlassian.net/secure/admin/ConfigureCustomField!default.jspa?customFieldId=10030&fieldConfigSchemeId=10131

And here:

This permission out of the box is explicitly set to give users View and Edit Story Points permissions for issues of the following types:

  1. Epics
  2. Story
  3. Bug

4. Hence, the field “is set with both a Screen and a Context” but still you cant edit!
Using the API returns the following error:

{customfield_10032: "Field 'customfield_10032' cannot be set. It is not on the appropriate screen, or unknown."}
Response:{"headers":{"server":["envoy"],"cache-control":["no-cache, no-store, no-transform"],"content-type":["application/json;charset=UTF-8"],"content-encoding":["gzip"],"strict-transport-security":["max-age=315360000; includeSubDomains; preload"],"date":["Thu, 24 Jun 2021 19:11:10 GMT"],"x-request-id":["00dc889c793009df"],"x-arequestid":["f6d18b16-582c-48d2-b35a-c68259535afe"],"x-aaccountid":["5c77262d5246045a2d8fe269"],"x-xss-protection":["1; mode=block"],"transfer-encoding":["chunked"],"x-envoy-upstream-service-time":["151"],"timing-allow-origin":["*"],"x-content-type-options":["nosniff"],"connection":["close"],"x-trace-id":["00dc889c793009df"],"set-cookie":["atlassian.xsrf.token=b85ca376-f686-4e0f-890d-2518aa9fdac7_166928e216f6c956bec20eee9b1fb74f1bdc3d31_lin; Path=/; Secure"],"x-frame-options":["SameOrigin"],"expect-ct":["report-uri=\"https://web-security-reports.services.atlassian.com/expect-ct-report/global-proxy\", enforce, max-age=86400"]},"ok":false,"status":400,"statusText":"Bad Request"}

Notice that the API call returns:

  • status":400,“statusText”:“Bad Request”}

Which does’t make sense - because the same request returns Ok, 204 as soon as I add the following “Field definition”

So the API seems to be working incorrectly - when the field is only associated the the Default Screen, because:

  1. The field is associated with a screen - through the Default screen config - confirmed by the fact I can see the field
  2. The permission to edit the field is in place - through the Context definition - confirmed by the fact I can edit story points for Epics, story and Bug

So it should be possible to use the API to update the field as both requirements are in place, else this statement doesn’t hold true:

“Custom Field needs to be set with both a Screen and a Context in order for the Custom Field to appear in the UI, or be editable by your app.”

1 Like

To test the API call you can use the following code:

const issueIdOrKey = "TEST-1";
const response = await api
  .asApp()
  .requestJira(`/rest/api/3/issue/${issueIdOrKey}`, {
    method: "PUT",
    headers: {
      Accept: "application/json",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ fields: { customfield_10016: 7 } }),
});
console.log(response.status);
if (response.status !== 204) console.log(await response.text())
1 Like

Hi again,

I need feedback from Atlassian on when this is likely to be fixed. Because I have an Add-on ready to go live depending on this API call.

I see three options, please let me know if there are any alternative solutions:

  1. Go live without any changes
    a. Users who try the add-on will get the following error message:
    b. Screenshot 2021-06-29 at 11.58.40
    c. Users will have to troubleshoot what is causing the problem and find a solution
    d. Users will have to ask their Jira Administrators that they associated the field with Screens for all projects the are using
    => I expect large portion of users will give up and find a better solution

  2. Go live with an improved error message guiding users towards a solution
    a. Publish an article explaining how to resolve the issue
    b. Programatically detecting this case and providing users with a link to the article
    c. Users will have to ask their Jira Administrators that they associated the field with Screens for all projects the are using
    => I expect portion of users will give up and find a better solution

  3. Get the API fixed so permissions users certainly have - also work when called from the from the REST API.

Hoping for a quick solution :wink:
All the best