What Are Locked Fields in Jira? And How Do I Unlock Them?

[#1]

When you sign up for a Jira instance or install an app from the Atlassian Marketplace, there are a few fields that are used by a Jira product or the app. These fields are considered system fields and are “locked” upon their creation.

Though they are system fields, they show up in the list of custom fields, but include a “Locked” label beside them. These are fields like Affected Service, Approvals, Category, development, Epic-related fields, Flagged, Goals, and others.

If you have a popular Checklist app, you will see locked fields associated with various Checklist fields. Some of these fields are related to Jira Service Management and will not show up with Jira only instances.

Okay, duly noted – now how do I unlock them so I can modify them or set the context in some way. Well, you can’t. Seriously? Nope, you can’t so stop trying.  😊

These fields cannot be unlocked, deleted, or edited in any manner. You can add the locked field to a screen or view the field details, including applied contexts and associated screens, but that’s pretty much it.

Why these fields show up in Custom Fields but other fields like Due Date, Summary, etc., don't is somewhat of a mystery to me. I believe the most likely answer is that these system fields do not get rolled out to every created instance but are product or app dependent. 

Therefore, there is no built-in system name like duedate, created, resolved, and so on. So to make use of them in automation rules you might need to find the custom field ID for them. But that little "Locked" label makes us want to try to pry them open. 

Currently there is an open JAC ticket for you to vote for and follow if you are keen on getting access to these mysterious fields.

JRACLOUD-64188: Ability to unlock system field, to Configure it

Or if you are looking for more information, you can find additional documentation here:

Locked-custom-fields

So, for the sake of generating some discussion, which field would you most like to edit in some way, and what would you like to do?

[Bill Sheboy]

Hi @John Funk 

Thanks for the information, and to your discussion prompt, I would invert that to this:

I would like declarative referential integrity on field naming to prevent creation of fields with the same name in possible shared contexts to avoid confusing JQL, dashboard gadgets, and automation rules between locked and unlocked fields.  That would perhaps cut down on some odd errors.

Kind regards,
Bill

[Matt Doar _Adaptavist_]

Bill, well, me too! The idea of allowing fields with duplicate names was a work around from a long time ago to allow for having different field configurations for different issue types I think? Anyway it's time it was stopped IMO

But as to locked fields, I recall a couple of cases where I had to unlock a field in DC (via DB or ScriptRunner) but I don't remember the details. I'm interested to hear why anyone would need to unlock a  field in Jira Cloud these days

John, I suspect you are right. Custom fields for specific apps are declared with one system (and can be marked locked or unlocked) but system fields are defined using a different code path

[Yatish Madhav]

Thanks @John Funk  "Why these fields show up in Custom Fields but other fields like Due Date, Summary, etc., don't is somewhat of a mystery to me." - me too!

I also agree totally with @Bill Sheboy  RE duplicate or similarly named fields - we have around 1000 fields and some are duplicated due to past multiple admins doing what they feel is right without considering administration and the issues that it can lead to.

In my opinion and simplicity of Jira, it is, at super high level, a tool which has projects which have tasks/issues which have fields which have values (among other things ofcourse) and so ALL fields should be listed fully in the Fields listing and where they come from - system related, product related, addon related, custom field, etc...

RE the locked fields, we have a custom connect app that creates and populates fields as we needed it and as an admin on that app and on Jira, i think it would be handy to be able to see some additional details. Examples include:

- locked single or multi select field and its options in read-only mode
- fields like summary, duedate, created at, updated at, etc
- field ids and custom field keys as a way to debug (granted this is technical but would be handy)
- fields by screen(s) and field(s) by layouts

Thank you for this discussion again
Yatish

[John Funk]

Thanks all of the comments! Sounds like we are all in agreement here!

[Dave Liao]

@John Funk - funny, when I first read this article title, I thought you were referring to read-only fields. Would be awesome to be able to natively be able to lock down the ability to change field values... I wonder what the JAC ticket is for that.

@Bill Sheboy - would love to prevent admins (even myself) from creating fields that share the same namespace. One day! Who needs three "Location" fields, anyway? 🤣

[Gary Spross]

"Would be awesome to be able to natively be able to lock down the ability to change field values..."

@Dave Liao, by this do you mean to lock the field contexts so the options contained within a field are not able to be changed or do you mean to make a field read-only. Because you can do the later by placing the field on the View screen and not the Edit screen. Automation will be able to modify the field value and it will show on the issue screen, but not be editable by the end user.

[Dave Liao]

@Gary Spross - true, good call on that method of having virtually read-only fields!

I think users can still overwrite them via a bulk update operation (or via other unsavory methods). Would love a way to make a field value truly immutable except to those who should modify them.

[Gary Spross]

Oh, yeah, I guess bulk updating is still the workaround to this method. Damn, nefarious users! : )
I agree that it would be helpful to have a true concept of "read-only" for individual fields, with the ability to specify users who should be able to.

[John Funk]

This would be field level security - which is not native for Jira, but I think a few Marketplace apps exist that can do that. 

[Denys Kontorskyy_Railsware_]

Definitely would be the Epic-related fields. Having more control over their configuration just helps things be simpler...

[Gary Spross]

@John Funk, apps definitely have their place, but, in my opinion, a feature like "field level security" should not require having to pay an additional fee because Atlassian has a shortcoming. Something like this should be built into Jira.

I'm just voicing a bit of frustration because I feel like the answer is always "there's an app for that" which causes the overall cost of the tooling to continue to balloon leading to "fun" conversations with leadership to explain/defend budgeting.

[Matt Doar _Adaptavist_]

Ah, this takes me back to the earliest days of Jira and https://jira.atlassian.com/browse/JRASERVER-1330 where they said why they decided not to support field level security

[John Funk]

@Gary Spross  - I totally agree with you. Just stating the current environment. 

@Matt Doar _Adaptavist_  - Yeah, not buying it for their answer(s). If there are apps that can do it now, Atlassian could implement it relatively easily compared to their answer. But that's just me.  :-)