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

Consequences of unlocking some of the locked fields in JIRA?

Tayyab Bashir

Hi,

There are a few custom fields (e.g. Rank, Sprint, etc) that are locked by default in JIRA.
From this https://confluence.atlassian.com/jirakb/how-to-unlock-a-locked-field-779158866.html, I gather that it is not recommended to unlock these fields because they might cause unwanted behaviors.

I haven't been able to find out exactly what might be the consequences of unlocking any of these fields.
For e.g. I unlocked the field 'Sprint' because I had to make it required in one of the custom fields, but I couldn't see any breaking in JIRA operations or other unwanted behaviors.

So my question is, has anyone experienced unwanted JIRA behavior after unlocking these fields?
How can I find out if unlocking is actually affecting the JIRA behavior at all? Or is it just working normally?
Can this be tested?

Many thanks in advance.

Accepted answers

Nic Brough -Adaptavist-

I can give you two examples of consequences learned the hard way from one client.

Unlocked sprint field - all the sprint data was lost when they upgraded. Had to go to a backup and even then we lost a lot of historical sprints.

Unlocked Epic name - the relationships between story and Epic became corrupted, with the wrong Epic name being written onto issues, and eventually, sub-tasks started to get Epic names which were different to their parents. So the data was nonsense. Correctable, but not fun. We think the actual corruption was down to something an add-on was doing, but it was the unlocking of the field that allowed the system to be configured that way.

One reason for locking fields is non-technical - you don't want your admins doing bad things with your system. For example:

>I unlocked the field 'Sprint' because I had to make it required in one of the custom fields

That is a terrible thing to do, as it completely breaks Scrum. You should never be automatically jamming things into a sprint on issue creation, you should only add things to a sprint when you plan, with the odd exception when it's important. That's why it's optional - filling in a sprint on creation should be a very rare occurrence

All comments

Nic Brough -Adaptavist-

I can give you two examples of consequences learned the hard way from one client.

Unlocked sprint field - all the sprint data was lost when they upgraded. Had to go to a backup and even then we lost a lot of historical sprints.

One reason for locking fields is non-technical - you don't want your admins doing bad things with your system. For example:

>I unlocked the field 'Sprint' because I had to make it required in one of the custom fields

Tayyab Bashir

Hi Nic, thanks for the answer, it helps understand the effect better now.

I had unlocked the Sprint field, made it "Required" in field configuration. Now I have locked it back again.
Do you think there would still be potential for unwanted/harmful behavior to JIRA? Even after locking the field? (But with 'Required' condition now being applied)

Or should I unlock the field, remove the required restraint, and lock it back again?

Nic Brough -Adaptavist-

I would remove the constraint, mainly because it's a bad thing to do in terms of usage. I don't expect the config to cause you any technical problems. You should definitely re-lock the field after making config changes.

The fields being unlocked themselves does not cause a problem directly, but they do allow people to set up situations where things can go wrong.

Tayyab Bashir

Thank you for the help.

MattS

I haven't seen data being corrupted because a field is unlocked, but the situation Nic describes where some other add-on corrupted the data is possible. I would leave them locked. Use a validator to check that the field has a value

unknown

The challenge of using a validator on transition is that it does not solve the 'move' case. People (intentionally or unintentionally) can get around required fields when creating issues as one type that don't require the field, and then move the issue to the type that requires the field. The move only enforces required fields, nothing in the transition. Somebody suggested adding the validator on each transition so that the issue can't move through it's workflow without the required field....but that's not great and issues that aren't moved through the workflow remain without the setting, and this creates more complex workflows that must be maintained. Has to be another way......

Welcome!

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

Quick Links

Find more posts tagged with

custom-field

jira

jira-core