Hiding a custom field versus removing the screens associated to the custom field

Question

I would like to know the advantages and disadvantages of one option and the other:

1) Hiding a custom field from an issue type for a given project

2) Removing the screens associated to the custom field from an issue type for a given project

I have explored the two alternatives and with both of them I seem to arrive to the same results.

Why is the rationale of using 1) or 2)? What is the best practice you would recommend?

Thanks

Victoria.

Nic Brough -Adaptavist- · Answer

That's not quite true.  Admin permissions let you configure the system, so you can show/hide fields, but if you hide a field from a project, it's hidden, it won't appear for anyone.

Maria Victoria Martinez Torino · Answer

The thing is that having JIRA Admin permissions allows me see the custom field in both situations.

In what particular case would I not be able to see a hidden custom field? Should I remove the JIRA Admin permission to try this out?

Thanks for your support.

Victoria.

Nic Brough -Adaptavist- · Answer

Hiding a custom field in the field configuration hides it everywhere.  One effect is that you can share screens that include it, and it will not appear, so it can simplify your screen usage.  It also means it won't appear in reports, agile, it won't be searchable, and so-on

Removing a field from a screen is a bit more flexible.  You'll be able to search on it, you can do things like have it on the create screen, but not edit, so it's not changable after creation, you can still use it on boards and reports and so on.

My personal preference is to ignore field configurations.  Screens are more intuitive and obvious, and if I really don't want the field in my project/issue type, I can remove it from the custom field context.  But that is just the way I've evolved my preferences.  The main thing I'd advise is to try to stick to one way of doing it - a mess of screen/context/config is painful to unpick, go for screen/context or screen/config as much as possible.