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)
- 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
- 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
- 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.