Why do some fields have more Operations than others in the View Field Configuration page?

[Deleted user]

I'm new to JIRA. I need help understanding what I am looking at when I am viewing the View Field Configuration page. The first sentence on the page says this, "The table below shows all fields configured in JIRA and their properties for TP: Bug Field Configuration."

The first field I see listed is this: "Account" and it also has a little annotation that reads "LOCKED". Under the "Operations" column that field has 1 link: "Screens".

The 2nd field is called "Affects Version/s" and has the following links listed under the "Operations" column: "Edit", "Hide, "Required", "Screens", and "Renderers".

The 3rd field is called "Aha! Reference" and has the following links listed under the "Operations" column: "Edit" and "Show".

My 1st question is: Why do some fields have more Operations than others in the View Field Configuration?

2nd question is: How do I gain access to all Operations on all the fields I see on this page?

3rd question is: Why do I see fields on this page that are NOT actually part of my project?

4th question is: Can someone please explain to me what the Field Configuration is and how to use it in my project? With screens, screen schemes, workflows, workflow schemes, fields, field configurations, and field configuration schemes...it's hard to tell what the function of each one is and how I can make any sense of how to go about using the functionality.

*Also just want to communicate that I have read through all the documentation in the "Administering JIRA Cloud Applications" section of the Atlassian Documentation and it doesn't help. Unfortunately, my questions remain unanswered after going through the documentation.

Thanks for any help you can give a new person to JIRA!

 . Adam .

[Nic Brough -Adaptavist- · Accepted solution]

Some field types have more functions than others.  Plain short text for example, is just that - a box for some text.  But a select list field has options, and options which can vary by project/issue-type, so it needs more operations to control it.  You won't get "access to other operations", because they're simply not there.

Locked fields also reduce your operations lists - fields are locked to try to make sure you don't inadvertently remove them and break a critical part of something big (like the Agile Add-on/Application).  You can unlock fields, but it requires a little bit of hacking, and you can't do that on Cloud (if there's a good reason to unlock them, you need to raise a support request, but you can expect them to be refused unless you can demonstrate that you really do need to unlock them and you won't be breaking anything by doing it)

So that's answers to your 1 and 2, albeit a bit mixed up.  So...

3.  Fields are global artefacts, even when they only really apply to one project.  They have to be global to allow you to change where they can be used!

4. Field configurations hold bits of config for fields that doesn't fit anywhere else.  They cover :

• Renderers (I think these should be in the field context)
• Mandatory/optional (I'd bin that and do it by screen)
• A show/hide option (which can be done two other ways and far more logically in those places)
• Changing descriptions (which never seems to work)

The best page to read on this is https://confluence.atlassian.com/jira/configuring-fields-and-screens-187859099.html

(Can you tell that I'm not fond of field configurations?)

[Steven F Behnke]

They are certainly complex but if wielded correctly they are very powerful. Unfortunately, I've not had the opportunity of seeing them implemented correctly often enough.

[Will Wilson]

"fields are locked to try to make sure you don't inadvertently remove them and break a critical part of something big"

How does a field become locked?  I have created custom fields in the past, and now some of them are locked and some of them are not.  Is there a way to tell which custom fields are going to become locked?

[Nic Brough -Adaptavist-]

Code.  I don't think JIRA Core locks any fields, I'm not sure about Service Desk from memory, but JIRA Software locks a swathe of them.  I suspect the ones you had before were Software related fields and when you upgraded, it went "I need to lock those" and did it.  It's mainly done by field type, e.g. a rank field, or an epic link field etc.  Standard custom fields don't get locked (although an admin wiht database access can do it too of course)

[Will Wilson]

Nic,

Thank you for your response.  What I meant to ask was, whenever the code locks a field, WHY did it decide to do so?  What is the criteria for locking a field?  If I create a new custom field, right now I have no idea if it will get locked.  Is there any way to predict that?  Surely the locking of a field does not just happen randomly, right?

We are using Service Desk.  What did you mean when you said "when you upgraded"?  I am not sure if we have upgraded anything...

[Nic Brough -Adaptavist-]

It's the field type - the code takes ownership of fields it doesn't want you to mess with.

If it appears to be randomly locking fields of the standard types, then you've got some odd code or an admin doing it.

What types are all of the fields you have that are locked?  (And name might be handy)

[Will Wilson]

The fields I created were type "SLA CustomField Type".  Did you want the name of each field?  One of them was "Time in IN BACKLOG" and the others were all "Time in X".  (I had created a number of Statuses, and I created these custom fields to track how long an issue is in each Status.)

Maybe there is something about the SLA CustomField Type?

[Nic Brough -Adaptavist-]

I asked for the names in case you'd run into one that was not an unusual field type.

SLA and Time-on fields are indeed locked by Service Desk.

[Will Wilson]

OK, so once I create an SLA/Time-on field, I can never edit or delete it?  That seems unusual to me.  Regardless, the reason I got to this page originally was because I wanted to get those custom SLA fields into a CSV.  I created a filter and added those fields and saved it, and it shows them as expected in JIRA.  But when I export to CSV, it does not include those fields.  Do you know if that could be because they are locked?  (I noticed that every field which is not in the CSV is locked, which eventually brought me here)

[Nic Brough -Adaptavist-]

Correct, it's locked to prevent you editing it because you shouldn't.  Delete is a little different, I'm not sure of the logic of that, but I suspect it's because the lock is a quite binary thing, on or off, no half-way "can't edit, but can delete" options.

The correlation between locked fields and csv is I'm afraid, misleading you.  CSV doesn't care if a field is locked, it cares that a field can give it usable output.  If you had JIRA Software, you'd find the locked Story Points and Ranking fields come out in CSV.  I suspect it's simply that CSV doesn't know how to read the fields (yet)

[Will Wilson]

Well I sure hope I created those fields correctly, since I can never change or delete them!

As to the CSV, I am not sure if there is a way to tell, but I suspect the issue is not that the CSV can't read those fields.  I think those fields are not being included at all in the export.  If I open the file in Notepadd++, and just see the raw text, there is nothing for those fields.  The first row has all the field names, and it does not include any of the SLA fields.

If I do "Export HTML", it includes those SLA fields.  But if I do "Export Word" or "Export Excel CSV", it does not include those SLA fields.  I guess at this point I should create a ticket with Atlassian, right?

[Nic Brough -Adaptavist-]

It drops columns it is unable to export.

Yes, it should be reported as a bug.  They're doing a lot of stuff on the CSV recently, so it might be flagged as a duplicate.

[Will Wilson]

OK cool.  Thanks for the help!