We couldn't load all Actvitity tabs. Refresh the page to try again.
If the problem persists, contact your Jira admin.
IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-78839

Restrict editing for custom fields / allow fields to be read-only for certain users i.e field-level security

    • 193
    • 73
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Hello,

      We would like to request a feature to restrict editing of custom fields to specific users and for those fields to be read-only for non-editing users.

      Workaround:

      While there is no current way to meet this requirement, some scenarios/teams might benefit from using Jira Cloud automation to some extent.
      The idea is to use automation to track field changes. If a user from a specific user group (or not from a specific user group) triggers a field change, the automation rule will edit the field value to what it was prior to the edit.

      The automation rule concept:

      1) Trigger: Field value changed
      Select the field to monitor for changes, for example the "Priority" field
      2) Log Action:

      Initial value - {{fieldChange.fromString}}, Modified value - {{fieldChange.toString}}

      3) Add a User Condition
           User: User who triggered the event
           Check to perform: Is not in group / Is in group
           Criteria: Select a group to compare with
      4) Log Action (Optional):

      The user ({{initiator}}) who changed the field value is not part of the required group

      5) Action: Edit Issue
      Populate the "Additional fields" text box with a JSON payload like this:

      {
        "fields": {
          "Priority": {"name": "{{fieldChange.fromString}}"}
        }
      }

      Note that not all fields might be supported and when working with custom fields, their ID must be referenced.
      You can get all the fields from an issue by making a GET call like this:

      https://{YourCloudInstance}.atlassian.net/rest/api/3/issue/{Issue-Key}?expand=names 

      You could improve the rule, for example, to send an email to the unauthorized user (initiator.emailAddress) trying to make changes to the monitored field(s), etc.

      Workaround #2

      This workaround consists of configuring your project so the desired field(s) will not be editable via issue view, but only via a restricted workflow transition accessible only by people that should be able to edit the fields in question. See the recording where I show an example: Restrict field's editing.mp4

            Loading...
            IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
            Uploaded image for project: 'Jira Platform Cloud'
            1. Jira Platform Cloud
            2. JRACLOUD-78839

            Restrict editing for custom fields / allow fields to be read-only for certain users i.e field-level security

              • 193
              • 73
              • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

                Hello,

                We would like to request a feature to restrict editing of custom fields to specific users and for those fields to be read-only for non-editing users.

                Workaround:

                While there is no current way to meet this requirement, some scenarios/teams might benefit from using Jira Cloud automation to some extent.
                The idea is to use automation to track field changes. If a user from a specific user group (or not from a specific user group) triggers a field change, the automation rule will edit the field value to what it was prior to the edit.

                The automation rule concept:

                1) Trigger: Field value changed
                Select the field to monitor for changes, for example the "Priority" field
                2) Log Action:

                Initial value - {{fieldChange.fromString}}, Modified value - {{fieldChange.toString}}

                3) Add a User Condition
                     User: User who triggered the event
                     Check to perform: Is not in group / Is in group
                     Criteria: Select a group to compare with
                4) Log Action (Optional):

                The user ({{initiator}}) who changed the field value is not part of the required group

                5) Action: Edit Issue
                Populate the "Additional fields" text box with a JSON payload like this:

                {
                  "fields": {
                    "Priority": {"name": "{{fieldChange.fromString}}"}
                  }
                }

                Note that not all fields might be supported and when working with custom fields, their ID must be referenced.
                You can get all the fields from an issue by making a GET call like this:

                https://{YourCloudInstance}.atlassian.net/rest/api/3/issue/{Issue-Key}?expand=names 

                You could improve the rule, for example, to send an email to the unauthorized user (initiator.emailAddress) trying to make changes to the monitored field(s), etc.

                Workaround #2

                This workaround consists of configuring your project so the desired field(s) will not be editable via issue view, but only via a restricted workflow transition accessible only by people that should be able to edit the fields in question. See the recording where I show an example: Restrict field's editing.mp4

                        Unassigned Unassigned
                        de16a575f70e Kim An
                        Votes:
                        18 Vote for this issue
                        Watchers:
                        46 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                            Unassigned Unassigned
                            de16a575f70e Kim An
                            Votes:
                            18 Vote for this issue
                            Watchers:
                            46 Start watching this issue

                              Created:
                              Updated:
                              Resolved: