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; } } }

Advice on how to make a field required without affecting multiple projects

Colleen_pd2nai

There is an employee wanting me to make a field required for five projects. The problem is the field configuration settings are shared by 186 other projects that I don't want to modify. Many of the other projects may or may not use the field, and some don't need to use it at all, so I don't want to make it required in those places.

I know I could copy the field configuration/scheme, make the field required, and assign it to those five projects, but I was wondering if there is a better way to do this. Seems like a lot of unnecessary work for a simple task. Any advice?

Accepted answers

Sid Pathirana

Hi - the standard way will be creating a new field configuration scheme where the field is mandatory and applying that field configuration scheme to the required projects.

If you have the Scriptrunner Behaviours app it will allow you to achieve the same thing without having to modify the field configuration. With this app you can specify the field is mandatory for a particular set of projects and issue types (as well as other features like making the field read-only or hidden). I have done something similiar to what you're trying to achieve using this app on Jira server, but assume it has the same functionality on Jira Cloud.

Personally, I don't think Scriptrunner Behaviours is the most intuitive app to use, so you might find following the field configuration option is actually more straight forward and cheaper as it uses the built-in functionality.

Otherwise, you may have options via a workflow condition (eg. value field) or a validator (eg. field required validator) to check the field is populated depending on where & how the field is used - but this again may require creating a new workflow which is applied to just the relevant projects.

All comments

Sid Pathirana

Hi - the standard way will be creating a new field configuration scheme where the field is mandatory and applying that field configuration scheme to the required projects.

Personally, I don't think Scriptrunner Behaviours is the most intuitive app to use, so you might find following the field configuration option is actually more straight forward and cheaper as it uses the built-in functionality.

Colleen_pd2nai

Ok yeah this pretty much confirms what I thought. Also seems like adding workflow restrictions are just as much work.

Another question if you don't mind. I was reading an article by a person who says he only makes required fields sparingly. Is it reasonable to deny a request because of extensive changes that are required or to stick to Jira best practices? Sometimes I don't know if I should approve everything or say no, I don't recommend.

Sid Pathirana

I usually have a chat with the user to make sure they have valid reasons for asking for a change if the benefit is not obvious and goes against best practice.

In general, I try to make sure any field that is essential to any reporting or tracking is mandatory to ensure we have the data captured at source to avoid any retrospective chasing around for missing values and data cleanses. That may then result in these fields needing to be made mandatory in the field configuration.

If the field configuration is shared across multiple projects but having it as mandatory causes problems in some then I try to add a suitable default value (eg. Not Applicable) when necessary to the config to avoid some users getting confused with not knowing what to populate in the field, or I add some suitable explanatory text to display on the screen via the field's description entry.

Sometimes I use different field contexts and/or field configurations within the field configuration scheme where I have the flexibility of having different behaviour in different issue types where the field is used (eg. required in some issue types, optional in other issue types).

Overall, I don't think the various different layers of interwoven configuration schemes that Jira needs to operate generally makes this kind of thing easy!

Colleen_pd2nai

Ok thanks for your response. It's sometimes hard to know which is the best path when configuring in Jira, but your advice makes sense

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud