Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-809

Organization have a default "Members" group



    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:



      With MMF-725, we now have the built-in concept of "Member": it's possible to easily add or remove a user as a member, and then reference this user on global or project permissions.

      The problem is that when managing permissions, we currently don't have a way to reference "all the members". On premise when orgs are not activated, this is the purpose of the default group "sonar-users".

      We should therefore create a default built-in group on each organization:

      • called "Members"
      • with "All members of the organization" description
      • non deletable
      • non manageable in the "Groups" page - i.e. not possible to add or remove users from that group (must be done through the Members WS API)
      • referenced in the default permission template as having the "Browse" and "See Source Code" permissions

      Use Cases

      As the administrator of an org with a paid plan:

      1. I create a "Private project" and analyse it
        • I expect all the members of the org to have read access to it w/o needing to do something else (<= possible thanks to the default permission template that references the "Members")
      2. I add a new employee as a member of the org
        • I expect this new employee that have read access to all the private projects w/o needing to add this user to a specific group or update the permissions of this private project
      3. If I go to the "Groups" page of my org, I expect to:
        • see several groups including "Members"
        • see that "Members" is the default group
        • be able to update/delete all groups but not "Members"

      As a project admin, I expect to:

      • Be able to grant (or revoke) permissions only to members at once using this "Members" group that I can find on the project "Permissions" page

      Behaviour when organizations are not activated

      The built-in "Members" group is in fact the default group - called "sonar-users" on a fresh instance. The only difference is that currently:

      • this default group is set through a setting ("sonar.defaultGroup")

      With this MMF, here is the expected behaviour for OnPrem w/o Orgs:

      • Removal of the global setting which says which group is the default one
      • See on the "Groups" page that "sonar-users" is the default one and that it's not editable

      Technical Details

      To address both cases without too much difference, we "just" need to add 1 information on groups:

      • isDefault => any new user/member becomes part of this group, impossible to delete, update name/description, add/remove users or update the "isDefault" status

      For OnPrem w/o Orgs instances, "sonar-users" will be default.
      When there are orgs, "members" will be default.

      When groups synchronization is activated, make sure that it never removes a user from the default group.

      When activating organization, on the default org:

      • the "members" group must be created
      • all users who belong to default group must be added to "members"
      • "members" must become the default group and then become read-only
      • If possible, grant to "members" the same permissions as the original group:
        • On global permissions
        • On permission templates
        • On project permissions


      For OnPrem w/o Orgs instances (i.e. everybody):

      • Create "sonar-users" group if it has been deleted
      • If "sonar-users" is not default, grant "sonar-users" the same permissions (template, global and project) as the current default group
      • Copy all users to "sonar-users"
      • Deletion of "sonar.defaultGroup" setting
      • Set "isDefault" to "true" on the "sonar-users" group

      When there are org (i.e. on SonarQube.com), for each one of them:

      1. create the "Members" group
      2. add the members to that group
      3. make that group "default"
      4. in the default permission template, grant "members" the "Browse" and "See Source Code" permissions


          Issue Links



              fabrice.bellingard Fabrice Bellingard
              fabrice.bellingard Fabrice Bellingard
              0 Vote for this issue
              1 Start watching this issue