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

Mandatory fields being "too mandatory"

Scott Hung_cda1zk

Looking for a little help with a mandatory field.

I created a field that is mandatory so when a bug is resolved a checkbox must be chosen. The default is for no checkboxes set. All is good.

Problem is I'm in a Catch-22: I put the field on the edit screen in case someone needs to change it, but if they use the edit screen for a different field and no checkboxes are selected they are required to select a checkbox. For now I removed the field from the screen so devs must re-open the bug and resolve it again to change it but I'm looking for any better suggestions.

Thanks!

Accepted answers

Nic Brough -Adaptavist-

If you set a field mandatory in Jira, it is mandatory from the beginning of the lifecycle and all the way through. You have to set it when the issue is created, and you can't blank it out again.

The screens it is on are irrelevant. If it's mandatory, it's got to have a value from create, doesn't matter if you don't put it on any other screens.

The way to deal with this is usually validators. These check that a user is doing something on an issue *transition*. Annoyingly, Jira off-the-shelf totally neglects the very common case that a field is only required later in an issue lifecycle and doesn't provide a useful validator. Lots of plugins do though: Misc workflow extensions, Jira Suite utilities and several others. To use them, you strip the mandatory field setting in the field config and then add in validators like "Field called Root-Cause must be filled in before allowing user to close the issue" (incident type workflow) or "Field called Tester must be filled in before allowing user to push issue into the first QA step".

All comments

Nic Brough -Adaptavist-

If you set a field mandatory in Jira, it is mandatory from the beginning of the lifecycle and all the way through. You have to set it when the issue is created, and you can't blank it out again.

The screens it is on are irrelevant. If it's mandatory, it's got to have a value from create, doesn't matter if you don't put it on any other screens.

Scott Hung_cda1zk

D'oh! You're right about issue creation & mandatory fields. I'll take a look at some plugin validators.

Edit: It was easy with MWE (Misc Workflow Extensions) to add "field must be modified" ...But what happens if a bug is re-opened and re-resolved? If the field was set correctly the first time it was resolved and subsequently got re-opened then when its resolved the second time it must have the field changed. One way to avoid this is to modify the workflow so a re-open uses a different transition but I was hoping to avoid change the workflow too much. Any other ideas?

Nic Brough -Adaptavist-

I'd clear the field on re-open - I think the MWE has "set custom field to a value" as a postfunction, so you could use that to set the calue to "". If that's not appropriate, then I think you might need a different reopen :-(

Scott Hung_cda1zk

Nic - Very helpful. I do see this post function. Unfortunately, my custom field is a set of check boxes and it's not obvious to me how to uncheck them. Using a blank field or "NONE" doesn't do anything. I thought to try some javascript but it looks like MWE accepts ASCII or groovy...

Mike Sorensen

You could use a Select List field type instead of the series of checkboxes. You can also choose choose a Multi-Select field if you want to let the user choose multiple selections. Then you can clear the field easily on the reopen transition.