Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Is there a way to hide field in the Advanced Issue Search section of the Filter Tab

Dear Atlassian Community,

I would like to hide some custom fields in the Advanced Issue Search section of the Filter Tab.

In short, in my mind, I would like to restrict some users to some specific projects. and some custom fields should be hidden for some projects.

At first I thought it could be possible with the (project) field configuration. But it seems that hiding a field in the field configuration can work in a custom field. But the user can still use the custom field in a JQL function in the filter section.

Any thoughts? 

Best regards, Geoffrey

1 answer

1 accepted

1 vote
Answer accepted

There's quite a lot to talk about here, especially on the fields side, but I'll try not to wall-of-text you and expect some questions where my attempts to shorten things make it unclear.

There are three questions here really:

Restricting users to projects - this is done with user roles/groups/individual memberships in the project's user/permission area.  On the most part, this is intuitive when you start looking at permissions and roles, you'll see that essentially it is just "give named user a permission via a role/group/rule and they can use the project".  You don't "restrict" people, you just do not give them permission to do it.  The thing that makes this complex for us is that Atlassian default to "everyone can do everything", doing things like "when creating a new project, grant the default permission that 'all logged in users can view, create, edit and transition issues'", and you have to remove that from projects that you want to "restrict" people from

Second question is about Cloud's team-managed (next-gen) projects.  The team owning the project can add fields to these, and the fields there are localised, and hence don't exist in other projects

The third question is about fields for company-managed (classic) projects.  Think of these as global objects that projects can be told to use.  Add a field called "Dave" to the system, and then you can tell the projects whether they should work with "Dave" and how and where.  The really complicated bit of this is that there are three places to look at the field, and they all apply at a project and issue type level (so in one project, Dave applies to bugs, but is not seen on features, for example)

  1. Field Configuration - can be used to say "hide Dave".  Dave still exists in the project/issue-type, and can hold data, but will not be displayed or offered for create or edit
  2. Screens - a screen is a list of fields to show to people when they take certain actions.  View, create, edit and transition screens can all be different.  If Dave is not on a screen, it won't appear when a user does that thing (with some exceptions - system fields like priority, resolution, status etc will always appear on viewing an issue).  As with field configuration, Dave still exists and could hold data, but if it's not on a screen, it won't be shown
  3. Field context - this is the most complicated one.  In the list of custom fields, you can tell a field that it only has context for a project or issue type, or you can accept the default of a field being "global", where it is available to all projects and issue types.  Unlike screens or field configs, this can remove the field completely - if you changed Dave from global to "bugs only", then all the other issue types would lose Dave, and if you had data in there, it would be deleted from the database completely.  Not hidden or made invisible, but deleted.

So, to answer "field is still visible to search", yes, they mostly will be, because a field is a global thing, and JQL is not project locked, it allows you to search for everything it can see.  

There are some cases where some intelligence is applied.  If you use the simple search, or, in some cases, define a set of projects up-front, then the search can know that some fields may not be valid for the project, and hide them in the list.  But the criteria for that is only the context - Dave is a valid field to suggest reporting on even if Dave is hidden in all the field configurations and placed on no screens.  It's only the context that would stop Dave from being suggested as an option in a search that starts "project = X"

TLDR: to thoroughly hide fields from projects, use their "context", but the search isn't going to stop seeing them most of the time.

Thank you Nic for this very detailed answer.

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you