Jira administrators guide

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

 Click here to expand...

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

 Click here to expand...

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

 Click here to expand...

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

 Click here to expand...

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

 Click here to expand...

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 can't add/disable options to Field A even though he's an administrator in both Project A and Project B.

When editing options

 Click here to expand...

You have three options:

  • Change existing context of a field:
    • Project administrators will have the ability to edit options in shared/global context of the field.
    • For example:
      When User A adds option to Field A in Project A, the option will be added to Context AB (and will appear in both projects)
    • When project administrators add/disable option in a shared/global context of a field, the context will be copied to a unique context for the project, and all values will stay the same.
    • For example:
      When User A adds option to Field A in Project A, new context will be created for Project A with the same values as Context AB, but Context AB won't change. All issues in Project A with value in Field A will still have the same value.
      When User A adds option to Field B in Project B, the new option will be added to Context B. All issues in Project B with value in Field B will still have same value.
    • When project administrators add/disable option in a shared/global context of a field, the context will be copied to a unique context for the project, and values for this field in the project will be deleted from all issues.
    • For example:
      when User A adds option to Field C in Project B, new context will be created for Project C with same values as Global context. All issues that had value for Field C in Project B will be updated and the value for Field C will be deleted (if PC-1 had value 111 for Field C, now the value will be None).

Permissions to update screens

 Click here to expand...

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.
  • Screens in projects the user is admin:
    • Project administrators will have the ability to update screens that are related to the project and are also related to projects the user is project administrator in.
    • For example:
      User A can update Workflow Screen, Default Edit Screen, PB Create Screen and Default View Screen.
      User B can update only Workflow Screen because the other screens that related to Project A are also in use in other projects that User B is not a project administrator in.
  • 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 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