"Operation value must be an object" - has been working up until now!

[Ryan Heath]

Hi, 

I'm using ScriptRunner Listeners to update some JIRA tickets in specific scenarios and these were working fine. I know they were because my custom field has a value in from a previous write from my script, but they seem to have suddenly stopped working. 

I narrowed it down to this in console:

 def result = put("/rest/api/3/issue/AA-1299") 
     .header('Content-Type', 'application/json')
     .body([
         fields: [
             customfield_11623: "Test"
         ]
     ])
     .asString()

Fails and returns the following:

    "body": "{
        "errorMessages":[],
        "errors":{
            "customfield_11623": "Operation value must be an object"
        }
    }",
    "status": 400

I swear something has changed recently to stop this working, but i can't see what the problem is. 

Any ideas would be appreciated?!

[Phil_Dimeski]

@Andy Heinzer Has any progression been made on this issue?

[Andy Heinzer]

Hi Ryan,

I think something might have changed on the back end in regards to the api/3 endpoint in question here.  When I am trying to use this with my cloud site now, I too am getting the same error when trying to just update a custom field of type text.

Interestingly, I found that I could use the /rest/api/2/issue/{IssuekeyOrId} endpoint and that this did work with my same headers/data payload.    So perhaps that could be a work-around here until we can figure out why this changed.

I found one other support ticket about this error, but so far it is not conclusive as to the cause yet.  I suspect this is either a bug or a missing update to documentation.  Either way, it's not right and I have some more investigating to do here.

I hope this helps.

Andy

[Ryan Heath]

Thanks for the suggestion. 

Using the following:

def result = put("/rest/api/2/issue/AA-1299") 
    .header('Content-Type', 'application/json')
    .body([
        fields: [
            customfield_11623: "Check"
        ]
    ])
    .asObject(Map)

.. does work as you suggested, but I still get an error from it, this time 204: No Content

But like I say, the value is changed!

[Craig Ruefenacht]

I'm having a similar issue.  This week is the first time I've tried using the API for Jira Cloud, and I'm trying to create an Epic.

I'm not able to set the Epic Name to a value simply using this:

"customfield_10008": "Hello World"'

That generates the following error:

{
   "errorMessages": [],
   "errors": {
      "customfield_10008": "Operation value must be an object"
   }
}

But the following does work in that the issue is created, but the Epic Name is set to everything on the right side of the colon.  So by making the value an object, it will work, but the entire object will be the value:

 "customfield_10008": { "value":"Hello World" }

Results in the "Epic Name" in the issue looking like this:

Epic Name:{"value":"Hello World"}

Since this is my first time using the API, I cannot say whether this has always been like this or not.  Since I've found some forum posts about similar problems, I'm assuming that the problem is recent.

[Manuel Picazo]

@Craig Ruefenacht I have the same issue, but did you have any solution for it?

[Andy Heinzer]

Hi everyone,

Sorry for the delayed response here.  However there was a ticket created for this problem that is being tracked in ACJIRA-1596 It appears that changes have been made to this endpoint that require specific fields updated/created via the v3 endpoint to use the Atlassian Document Format.

From that case, Chris Fuller noted:

There any public docs which talk about the ADF format, including a link to the schema.

https://developer.atlassian.com/cloud/jira/platform/apis/document/structure/

However, the v3 endpoints are still in beta. The issue description, environment, comment body, and worklog body should all be working for the most part. However, custom fields, as I understand it, are still in active development.

Noting that the v3 endpoints are still in beta and subject to change more so than the v2 endpoints are is important here.  Sorry for the inconvenience, but sometimes changes like this will happen while still in beta phase.  Emrah's comment explains further in

... you also need send a valid ADF document when creating/updating description, environment, comment body, worklog body and textarea custom fields using v3 endpoints. The value that you send doesn't conform to ADF spec.

I hope this helps to clarify this specific error in these examples.

Andy

[Jean Mainguy]

Experiencing the same problem here...

[Arpit Jain]

@Andy Heinzer any updates ?

[Alec Jasanovsky]

Also having this issue - using api version 2 works for me as well. 

[Michael DeCosta]

I'm getting the same issue for a custom field even though the create meta clearly says it's schema type is a string.

customfield_10010:
  hasDefaultValue:false
  key:"customfield_10010"
  name:"Epic Name"
  operations:["set"]
  required:true
  schema:
    custom:"com.pyxis.greenhopper.jira:gh-epic-label"
    customId:10010
    type:"string"

a curl request with {... "customfield_10010":"my value" ...} doesn't work and it used to 
Now I need to use this {... "customfield_10010":{"value":"my value"} ...}