Unable to update custom field

I have done plenty of searching, trial & error on this already and I am completely stumped.

My question is exactly like this one https://community.developer.atlassian.com/t/update-issue-custom-field-value-via-api-without-going-forge/71161 except the solution they used already doesn’t work for me.

I am trying to update a custom field for an Epic, I can clearly see it when I retrieve my issue like so:
GET /rest/api/2/issue/XXX-0000?fields=summary,status,assignee,customfield_77777

The custom field presents itself in the response like so:
"customfield_77777": 77.0

However, when I attempt to update it using:
PUT /rest/api/2/issue/XXX-0000

{ 
    "fields": {
        "customfield_77777": 13.0
    }
}

I just get back this error:
“Field ‘customfield_77777’ cannot be set. It is not on the appropriate screen, or unknown.”

Which honestly doesn’t make sense because I can edit it in the UI just fine. I edit the UI, run a GET and I see the value has updated.

Therefore, I started looking around and tried:
PUT /rest/api/3/app/field/customfield_77777/value

and I am met with:

“This API works only with fields provided by Forge apps.”

So basically I am stuck. I cannot edit the issue and I also cannot edit the custom value directly. So what do I do?

Just to be clear, this is an Epic. When I do the exact same thing with an Initiative it works just fine which just adds to my confusion.

Hello @EliHayon

This question has been asked over on the public Community Forum and elsewhere on the Internet some hundreds, possibly thousands of times, over many, many years, and the answer is always the same… the response from the REST API is a statement of fact; the API is not wrong, it is not mistaken, it is not at fault. The fault is always, always the person in the equation.

The person didn’t triple check to make sure that the exact field in question was on the EDIT screen of that Issue type in that Project and that the user account they were using had access to it. They think they did, but they didn’t.

… they were confusing the Issue CREATE screen with the EDIT screen

… or they were in the wrong Project, or they were viewing a different Issue type’s EDIT screen.

… or they were mistaking a field they saw in the GUI that had the same NAME as the field they were trying to set, but it was a totally different field with a totally different ID, since Jira allows multiple fields to all have the same name.

… or the credentials they were using for making the request to the API endpoint didn’t have permission to access that field on that screen for that Issue type and they were accessing the GUI with a different user account with different permissions and not realising it.

… or the custom field belonged to an app, had a special purpose, and it wasn’t addressable by the REST API outside the context of that app.

I can only recommend that you slowly, carefully retrace your steps and have a peer / colleague double-check your work.

PS. Yes, you cannot use any of the endpoints for that are for custom fields created by an app outside the context of that app, just as the documentation states and the error you got message confirmed.

PPS. Doing a GET request to the /rest/api/2/issue/{issueKey} endpoint only tells you that the field is on the VIEW screen, it does not tell whether or not the field is on the EDIT screen, or the CREATE screen.

Ok so as luck may have it, I don’t actually need to set this field in order to transition the Epic, so I am just going to give up on this.

Clearly you are annoyed with the question as it has been asked so many times, but that to me means there is a design flaw in Jira’s architecture if this can so easily be misunderstood with pretty much zero debugging or recourse to offer easily. So I agree with you this is an instance of PEBKAC, but for this problem to arrise this many times and no tools to be provided to debug it is an indication that Jira is doing something wrong. I am an end user doing my best to navigate this whole thing.

Doing a GET request to the /rest/api/2/issue/{issueKey} endpoint only tells you that the field is on the VIEW screen, it does not tell whether or not the field is on the EDIT screen, or the CREATE screen.

If I am understanding this correctly I can see the field on both the edit and view screens - but I am not sure if we are talking about the same screens. How can I determine which screen is which?

XXXX.atlassian.net/browse/XXX-0000 ← I can view my issue here and edit it too
When I click the create button I get a modal, but the custom field is not there.

So this is basically what I figured out last night is that someone must have changed the template (if that’s what it is called) and the field still shows up on older versions of Epics, but it no longer will be supported for newer Epics. I have experienced this before just using the UI, but thought it was a fluke or something. Turned out the templates really were being edited.

Am I on the right track?

Then whoever created that custom field and is the ‘owner’ of it, either:

  1. Did not put it on the appropriate screen (the CREATE screen) for that Issue type for a reason.
  2. Did not do their job properly, as I can’t think of a reason why you would want a field whose value can’t be set when the Issue is created, only edited

You can of course test this by using the REST API to create one of those Issue types and set that field at the same time. If you get the classic “The field isn’t on the appropriate screen” error, you have validated that.

Yep. Sounds like someone either:

  1. created a new Issue type called an Epic in that project and created a new screen scheme for it (the ‘template’ you refer to), or:
  2. edited the default screen scheme for the default Epic issue type:

… and didn’t put that custom field on all the required screens.

Sounds like the API was right all along and Jira was not at fault, a person was at fault.

Here comes the answer you might not like to hear… Google ‘jira manage issue screens’ to learn about them.

Have fun :slight_smile:

I just want to point out, I didn’t once say the API was wrong. I maintain this is confusing and Atlassian can do something to make it more clear, but clearly chooses not to.

I figured that would you be your reply. Thanks I will keep looking around.

I could debate that topic ad infinitum :slight_smile:

IMHO, Jira was just doing exactly what someone configured it to do. The person who did that didn’t avail themselves of all the documentation and discussions on the topic, and their action caused an outcome that’s also widely documented.

Anyhow, let’s consider the discussion closed now, eh.