Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-25181

Users without "Browse Users" permission cannot edit project roles

XMLWordPrintable

      (Copied from https://studio.atlassian.com/browse/JST-5368)

      When editing project roles, if the current user does not have the "Browse Users" permission, the Frother-ised control doesn't know of any allowable values and does not allow arbitrary usernames to be entered. Everywhere else in JIRA, if the current user does not have the "Browse Users" permission, it displays a simple text field instead.

      Video:
      http://screencast.com/t/mNzyYPkqn4

      This is a problem for Studio as the sysadmin user does not have this permission (sysadmin doesn't belong to the "developers" group - this is a separate issue and is tracked at https://studio.atlassian.com/browse/JST-5031).

      This worked fine in 4.3.x and will be a pain point for Support if not fixed.

      This bug needs work to make sure the multiuser picker gracefully degrades if the user of the component has no browse user permission. For example allowing submission of a list of comma separated usernames, or allowing usernames to be entered that are not part of the list (as there is no list) and failing out after checking with the server for that user.

            [JRASERVER-25181] Users without "Browse Users" permission cannot edit project roles

            sladey added a comment -

            Issue copied to https://jdog.atlassian.com/browse/JRADEV-8108

            sladey added a comment - Issue copied to https://jdog.atlassian.com/browse/JRADEV-8108

            metapoint added a comment -

            This needs work to allow the multiuser picker to continue to work well in jira studio and other circumstances.

            metapoint added a comment - This needs work to allow the multiuser picker to continue to work well in jira studio and other circumstances.

            Mark Lassau (Inactive) added a comment -

            James has committed his change to the Studio Branch, but not into 4.4.x or 5.0
            It gives SysAdmin user an implied "Browse Users" permission.

            We should consider whether to move this to JIRA core, and whether a SysAdmin gets an implied "all other permissions" - I don't see why "Browse Users" is special.

            Mark Lassau (Inactive) added a comment - James has committed his change to the Studio Branch, but not into 4.4.x or 5.0 It gives SysAdmin user an implied "Browse Users" permission. We should consider whether to move this to JIRA core, and whether a SysAdmin gets an implied "all other permissions" - I don't see why "Browse Users" is special.

            tier-0 grump added a comment -

            This is slightly complicated by the fact that sys-admin is a permission, not a group - I have a fix in mind and am going to crucible review it now.

            tier-0 grump added a comment - This is slightly complicated by the fact that sys-admin is a permission, not a group - I have a fix in mind and am going to crucible review it now.

            metapoint added a comment -

            Okay talking to @nmenere and @pslade about this. The feeling is that sysadmin permission should "trump" any other permission (including lack of "Browse Users" permission), this would make this change more of a java side rather than javascript change.

            metapoint added a comment - Okay talking to @nmenere and @pslade about this. The feeling is that sysadmin permission should "trump" any other permission (including lack of "Browse Users" permission), this would make this change more of a java side rather than javascript change.

            metapoint added a comment - - edited

            Why cant the "Browse Users" permission be given to the system-administrators group along side the developers group? Isn't that the quickest and best solution? We dont have to give it to all users.

            It feels to me if we are asking support to edit this for our customers we should be giving them the power to do so.

            The problem with "de-frotherising" the multiselect as I see it is that this is not a small change we need to process a textfield to parse out usernames, verify the usernames, and add them. IF the sysadmin knows or is going to have to guess usernames anyway, just give him browse user access and be done with it.

            metapoint added a comment - - edited Why cant the "Browse Users" permission be given to the system-administrators group along side the developers group? Isn't that the quickest and best solution? We dont have to give it to all users. It feels to me if we are asking support to edit this for our customers we should be giving them the power to do so. The problem with "de-frotherising" the multiselect as I see it is that this is not a small change we need to process a textfield to parse out usernames, verify the usernames, and add them. IF the sysadmin knows or is going to have to guess usernames anyway, just give him browse user access and be done with it.

            sladey added a comment -

            agreed, this is a an issue. will talk to rob about scheduling this into 4.4.1.

            sladey added a comment - agreed, this is a an issue. will talk to rob about scheduling this into 4.4.1.

            Veenu Bharara (Inactive) added a comment -

            This issue was raised during JIRA 4.4 but somehow got fixed only for single frother(Component tab/Edit Project lead/Add project) but not for multi frother control.

            Veenu Bharara (Inactive) added a comment - This issue was raised during JIRA 4.4 but somehow got fixed only for single frother(Component tab/Edit Project lead/Add project) but not for multi frother control.

              Unassigned Unassigned
              pwyatt Penny Wyatt (On Leave to July 2021)
              Affected customers:
              1 This affects my team
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: