REST API to create a custom read only field with a defualt value

Indunil Rathnayake December 21, 2018

Hi,

We need to have a custom field in the resolved screen, which is read only. But in order to appear it in the UI, a defualt value should be defined.

From the JIRA UI, we can't add a default value to a read-only field. Is there any REST API to do that? If so, can someone please let me know a sample request?

Thanks

 

 

2 answers

2 accepted

1 vote
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 22, 2018

This is a little contradictory.  A default value for a field is the data that Jira will put into it when you use "create issue".  It's a pre-select, designed to guide users and, if used properly, make them think about the data they put in.  For example, I will often default "priority" to a low level, like "trivial".  This makes users think a bit about how important it really is.  If they can't be bothered to read the fields, and decide to give me the right information about an issue, then it can't be that important!

A read-only field is, well, read-only.   They don't need default values, because they don't get data set by the users, because they can't, as they are read-only.  As well as the logic there, Jira only presents editable fields to users on edit screens, so as a read-only field is read-only, it won't appear.

I think what you really want to look at is a "Message field for edit" - this is a type of field provided by the "Jira Toolkit".  With these, there is nothing to enter, they just display the text you put in their "default value" when configuring them.  This is NOT intuitive for any users, but it does at least work once you've got it (it's a cheap kludge which I think really should be improved)

0 votes
Answer accepted
Indunil Rathnayake January 3, 2019

Thanks a lot for your valuable input. The actual use case which we are trying to address is as follows.

1) There should be a read-only custom field in the resolved screen (i.e. which cannot be modified by the users).

2) We need to update that custom field value from the JIRA REST API. So that the value of the filed is different in each JIRA issue.

This will be updated based on creating a separate internal JIRA in our organization. That internal JIRA ID is the value of that field and it should be considered when resolving the issue.

3) We consider that field as mandatory through a workflow validator. So that, a developer can't resolve an issue, without creating an internal JIRA in our organization.

Really appreciate all your help for identifying a way to do this. 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 3, 2019

Ok. 

  1. Only fields that ask for entry are placed on the resolution screen, so you can't do this with a data field.
  2. Yes this can be done, as long as the field is on the edit screen for the issue (i.e. it is NOT read-only)
  3. That's fine, although I'd consider the use of a condition as well, so the transition can't be started without the field being filled.  Also, if you put it in a validator, but don't put the field on the validation screen for the user to enter when it fails validation, you're going really annoy your users - if you make a field mandatory with a validator, you should always make it enter-able on the transition screen.
Indunil Rathnayake January 6, 2019

Thanks a lot for your response Nic.  So the only possible option to achieve our requirement is to use some other custom filed in resolved screen, which the user can edit.

Use a Drop Down : We have to add some defualt values when creating a drop down. Is it possible to override this defualt value, issue wise, by using REST API?

 

Any other field you can think of?

We need to allow user only to select the corresponding value we have set from the REST API(i.e. internal JIRA ID). There should be no possibility for user to add there own value.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 7, 2019

Yes.  A drop-down would suit you the best here, as you can give it a fixed list of options, the users would not be able to add to that list (only admins can)

Indunil Rathnayake January 7, 2019

Thanks for your quick response Nic.

The problem with the drop down list is, there we need to configure a set of options beforehand. But in our case, dynamically the options should be added. And only one option(i.e. Internal JIRA ID) should be there and it is different from issue to issue.

Appreciate your thoughts on achieving this.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 8, 2019

That's not going to be a drop-down then, if it's a single entry and different for each issue.  That needs to be a text field.

You need to decide how you want that populated.  Either users can enter it (use a text or short text field) in the UI and/or over REST, or you should calculate it (use a scripted field from one of the scripting/automation apps).

Suggest an answer

Log in or Sign up to answer