Versions Compared

Version Old Version 20 New Version 21
Changes made by

Oren Zehavi

Oren Zehavi

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: V2.3.9

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 Image Removed and click on it.
  3. Locate Add-ons from the menu and click on it.
  4. Locate Administer Fields → Configure on the left panel:
    Image Removed

In Configuration

Table of Contents
minLevel4

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

Expand

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

You can disable in all projects by clicking Image Removedand enable in all projects by clicking Image Removed

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

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

Permissions to select fields per project

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

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

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

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 Image Added and click on it.
  3. Locate Add-ons from the menu and click on it.
  4. Locate Administer Fields → Configure on the left panel:
    Image Added

In Configuration

Table of Contents
minLevel4

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

Expand

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

You can disable in all projects by clicking Image Addedand enable in all projects by clicking Image Added

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

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

Permissions to select fields per project


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

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

Expand

You have three options:

  • All fields:
    • Project administrators will have the ability to edit options for ability to show/hide fields to 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
    •  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 edit options only to fields that have a context to the project and that this context 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 add/disable options in Field A and Field B, but not in Field C, because it uses a global context 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       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
    • 't show/hide any field.
  • Field configuration is unique for a specific project:
    • Project administrators will have the ability to edit options only to fields to show/hide fields only for issue types that have a unique context Field Configuration 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.
When editing
    •  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

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

    :

    None)
    • 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         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 sameB.
    • 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:
        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 
      • 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

    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.
    • 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