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? 🤣