How to create a jira issue (type: test) with params dataset

Detlev_x4ccw5

Currently I try to create a issue of type test with a params dataset.

The creation of an issue of type test without a params dataset works fine, but when I try to add the customfield for the params dataset I get an 400 as response for my request.

Unfortunatelly I can't find any documentation for creating issues with param datasets.

 

Her you can see how my request looks like and what the response is.

As I said the normal creation of the issue of the type test works normal and the issue will be created without anny error only if I add the customfield to the fields structure the error occurse.

 

hopefully you can help me with this problem, to solve it. I've also tried some variations of the customfield structure for the params customfield, e.g. with and without the datasetRestBean tag but it leads allways to the 400.

I havn't also find any documentation if I have to use a special operation to add params to an issue like I can do it for adding comments to an issue with

" String requestURL = "rest/api/2/issue/" + testID + "/comment";
   String jsonString = "";

   jsonString = "{\"body\": \""+ comment + "\"}";"

 

best regards

 

Detlev

Radek Dostál

It's most likely that the field is not supported by REST - I assume since there doesn't appear any documentation for that field, you took a sample value from a sample issue with a GET and then tried to PUT/POST it?

Probably the format is different between what the user "enters" and what Jira "shows". I don't know what field type that is, but maybe if you can do some updates in browser (while watching the http requests in dev tools), you could see what format is being used in the payload.

If that is a regular field in the sense the field's value is sent as a parameter when you try to update the issue, and it doesn't use it's own and custom REST interface for CRUD stuff.

If it's not using Jira's native servlet/payload, and if it does use it's own custom REST, then at best you would need to create the issue first, and then update it afterward to supply the field:value over REST.

And since this seems undocumented, of course this will be prone to any changes in the future should the vendor decide to change something.

So overall I'd first check what sort of interface that field uses in browser to begin with, if it's just a field:value in the payload (along with all the other fields), it might be worth a shot.

But even if you get the format right, it doesn't guarantee that it will work, because browser and REST use different endpoints, so there might be some difference between how they will handle the values (really not sure).

You could ask the vendor too if they can give a hint what and how to do and/or public documentation for it, but I assume the use case is.. slim.. for this to be missing, they have a lot of things documented already. Again, I don't know what field that is so I'm not going down that line, but this is overall what I'd try.