nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Indunil Rathnayake

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

Accepted answers

Nic Brough -Adaptavist-

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)

Indunil Rathnayake

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.

All comments

Nic Brough -Adaptavist-

Indunil Rathnayake

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-

Ok.

Only fields that ask for entry are placed on the resolution screen, so you can't do this with a data field.
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)
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

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-

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)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

developer

atl-adm