Details

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

      Description

      Context

      To be able to define the monthly subscription that must be paid by an organization that has private projects (so that has given its billing information), we need to know how many members this organization has.

      We need to define what an org member is in SonarQube. A member is a user who has access to at least 1 project of the organization - may it be:

      • because the user belongs to a group that has at least 1 permission on this project
      • because the user is directly granted some permissions on that project (w/o belonging to a group)

      Use Cases

      As an org administrator, I expect to:

      • Easily know all the members of the org
        1. I go to a "Members" tab on the org
        2. I will see the list of members
        3. I can search for a given member
      • Easily add a user as a member of the org
        • From that moment on, I will be able to:
          • add this user in any existing group
          • grant this user org-level permissions
          • reference this user in permission templates (even if the use case is not very good)
          • or directly on any project on that org
        • In other words: it's not possible to add non members to a group (at org level) and it's not possible to directly grant a non member project-level permissions
      • Easily remove a member from the org
        • He should then be removed from any group or project-level permission

      As a project admin, I expect to:

      • Be able to grant permissions only to members at once
        • This will be possible thanks the the built-in "Members" group (see MMF-809)
      • Be able to set the default assignee of a project only to members

      As a member of an org that has access to a project, I expect to:

      • Be able to assign issues only to members

      As a standard user, when I go to an organization, I expect to be able to see the members of the org w/o more details.

      Migration

      For existing organization, it is expected that every user involved in an org becomes "de facto" a member during the upgrade:

      • If the user belongs to at least on group of the org
      • If the user has some org-level permissions
      • If the user is referenced in permission templates of the org
      • If the user has project-level permissions on projects that belong to the org

      Behaviour when organizations are not activated

      The concept of "member" should not be visible (even if it might be there in the underlying model) - which means that the WS and the Web UI must keep on working as usual. This means that when a new user is created (manually or through a external provider), the SQ admin shouldn't have to add this user to a member list to be able to add him to a group, to grant him permissions, ... etc.

      Under the hood, this might mean that in such context, every new user is added by default to the default organization ( ? ).

      Open questions

      • Maybe it would be nice to allow the org admin to say wether or not this member list is public?
        • This can be addressed later on in a dedicated MMF about visibility of an organization
      • As an org admin, I would like to easily manage the members of the org and request the following details on any member:
        • what are the groups he/she belongs to?
        • what are the projects he/she directly has access to?
        • => This is a nice to have and can be addressed later.

      Notes

      • GitHub differentiates "Members" and "Outside Collaborators":
        • Difference:
          • Members are invited at org level, and can then be grouped into teams to ease repo permission management
          • Outside Collaborators are users added "add-hoc" on a repository, they can't be part of teams
          • Billing is done on the number of members only
        • In SQ, the equivalent would be:
          • Members would be invited at org level and could be added in groups to ease project permission management
          • Outside collaborators would be users who get granted "add-hoc" project permissions directly
          • Billing would be done on members only
        • For SQ.com, is it worth doing the same differentiation? I don't think it's worth the complexity.

      Design proposition

      A "members" tab is displayed on the organization page

      Users that are not administrating the org see the list of members, and can search for a given member but cannot perform any action

      Administrators of the organization can have access to extra actions

      When clicking on "Add a user" button, they can search for a SonarQube user, and add it to the list of members


      When clicking on the settings button on each user item, they can manage groups or remove the user

      Removing a user:

      Clicking on "Manage groups" opens a modal where you can manage groups for this given user only.

        Attachments

        1. Organizations_Members_01.png
          Organizations_Members_01.png
          142 kB
        2. Organizations_Members_02.png
          Organizations_Members_02.png
          46 kB
        3. Organizations_Members_03.png
          Organizations_Members_03.png
          51 kB
        4. Organizations_Members_04.png
          Organizations_Members_04.png
          49 kB
        5. Organizations_Members_05.png
          Organizations_Members_05.png
          53 kB
        6. Organizations_Members_06.png
          Organizations_Members_06.png
          51 kB
        7. Organizations_Members_07.png
          Organizations_Members_07.png
          53 kB
        8. Organizations_Members_08.png
          Organizations_Members_08.png
          51 kB
        9. Organizations_Members_9.png
          Organizations_Members_9.png
          105 kB
        10. Organizations_Members_remove_member.png
          Organizations_Members_remove_member.png
          55 kB
        11. V2_Organizations_Members_01.png
          V2_Organizations_Members_01.png
          142 kB
        12. V2_Organizations_Members_02.png
          V2_Organizations_Members_02.png
          42 kB
        13. V2_Organizations_Members_03.png
          V2_Organizations_Members_03.png
          49 kB
        14. V2_Organizations_Members_04.png
          V2_Organizations_Members_04.png
          47 kB
        15. V2_Organizations_Members_05.png
          V2_Organizations_Members_05.png
          52 kB
        16. V2_Organizations_Members_06.png
          V2_Organizations_Members_06.png
          49 kB
        17. V2_Organizations_Members_07.png
          V2_Organizations_Members_07.png
          52 kB
        18. V2_Organizations_Members_08.png
          V2_Organizations_Members_08.png
          56 kB
        19. V2_Organizations_Members_09.png
          V2_Organizations_Members_09.png
          54 kB

          Issue Links

            Activity

              People

              • Assignee:
                fabrice.bellingard Fabrice Bellingard
                Reporter:
                fabrice.bellingard Fabrice Bellingard
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: