As a Jira administrator, you can configure what features of Custom Fields Administrator For Jira Project add-on you want the project administrators to use.

You can access the configuration page with these steps:

  1. Log in to your JIRA Server instance as an administrator.
  2. Go to the Administration icon  and click on it.
  3. Locate Add-ons from the menu and click on it.
  4. Locate Administer Fields → Configure on the left panel:

In Configuration

As a Jira administrator, you can restrict the use of Administer Fields for Project Add-on for project administrators (note that all permissions related features will remain for Jira administrators).

Enable/Disable in projects

You can choose which projects the project administrators can see the Administer Fields button. 

You can disable in all projects by clicking and enable in all projects by clicking 

To disable the add-on in specific projects, choose these projects from the Enable in Projects: select and click 

To enable the add-on in specific projects, choose these projects from the Disable in Projects: select and click 

Permissions to select fields per project


You can choose who will be able to enable specific fields per project:

  • Only Jira administrators
  • Jira administrators and Project Leads - Project Leads who are also project administrators will have permissions for this feature also in their own project.

See more about this feature in the Project Specific guide.


Allowed Actions

You can choose which actions the project administrators will be able to perform.

 You can find detailed information about each action in the Project administrators guide.



Permissions to show/hide fields

You have three options:

  • All fields:
    • Project administrators will have the ability to show/hide fields to all the fields in the system. 
    • For example:
      User A and User B can show/hide all the fields in the system.
      When User B hide field in Project A the field will also be hidden in Project B to Sub-tasks.
  • Field configuration is shared with projects the user is admin:
    • Project administrators will have the ability to show/hide fields only to issue types associated to Field Configuration that is shared only with projects the user is project administrator in.
    • For example:
      User A can show/hide all fields in Project A, but in Project B, he can hide the fields only to Sub-task and Epic issue types.
      User B can't show/hide any field.
  • Field configuration is unique for a specific project:
    • Project administrators will have the ability to show/hide fields only for issue types that have a unique Field Configuration to the project.
    • For Example:
      User A can't show/hide fields in Project A, because the Field configuration is shared with Project B.
      User A can show/hide fields in Project B only for Epic issue type.

Permissions to edit options

You have three options:

  • All fields:
    • Project administrators will have the ability to edit options for all the fields in the system. If the field has a unique context the option will be added only to this context, if not, the option will be added to the global context.
    • For example:
      User A and User B can add/disable options in Field A,Field B and Field C.
      When User A adds an option to Field B from Project B the new option will be added to Context B.
  • Field context is shared with projects the user is admin:
    • Project administrators will have the ability to edit options only to fields that have a context to the project and that this context is shared only with projects the user is project administrator in.
    • For example:
      User A can add/disable options in Field A and Field B, but not in Field C, because it uses a global context.
      User B can add/disable options in Field B, but not in Field A because the context is shared with project B which he's not an administrator in.
  • Fields with a unique context to a specific project:
    • Project administrators will have the ability to edit options only to fields that have a unique context to the project.
    • For Example:
      User A and User B can add/disable options only to Field B, because it's the only field with a context only for one project.
      User A can't add/disable options to Field A even though he's an administrator in both Project A and Project B.

Permissions to update screens

You have three options:

  • All screens related to project:
    • Project administrators will have the ability to update all screens that are related to the project.
    • For example:
      User A and User B can update Default Edit Screen, Default View Screen.
      User A can also update Default Create Screen, Workflow Screen and       PB Create Screen.
  • Unique screens for a specific project:
    • Project administrators will have the ability to update screens that are related only to the current project.
    • For Example:
      User B can update only Workflow Screen, because it's the only screen that is unique for Project A.
      User A can update Workflow Screen in Project A and PB Create Screen in Project B.


Example Jira

Projects:
Project Administrators:  User A, User BUser A
Field Configuration:Task, Sub-task - 
 PAB Field Configuration

Task -
Default Field Configuration
Sub-task - 
PAB Field Configuration
Epic - 
Epic Field Configuration

Task, Sub-task - 
 Default Field Configuration
Related Screens: 

Default Create Screen
Default Edit Screen
Default View Screen
Workflow Screen

 PB Create Screen 
Default Edit Screen
Default View Screen

Default Create Screen
Default Edit Screen


Custom Fields: 

  • "Field A" contexts:
    • Global
    • Context AB - Project A + Project B
  • "Field B" contexts:
    • Global
    • Context A - Project A
    • Context B - Project B
  • "Field C" context:
    • Global