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

Core support for public vs private projects



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



      On SQ.com, as soon as a user will provide billing information (MMF-723) on an organization, he/she will be able to have unlimited private projects.

      Currently, there's no built-in concept of public vs. private projects in SonarQube. The fact that a project is private is defined by the set of permissions granted to individual users and groups on that project, and most specifically to the "anyone" virtual group that matches any users (logged-in or not). This has the following consequences:

      • On the project "Permissions" page (for a project admin):
        • It's not straightforward to quickly see if the project is publicly available or not: the user has to scan all the users and groups on the "Browse" and "See Source Code" permissions, pay attention if "anyone" is listed or not, ...
        • When you want to restrict the visibility and make the project private, it's not a one click action (= remove "Browse" and "See Source Code" from "anyone")
      • On the project home page (for users who have access to it), there's no information that the project is public or not
      • And most importantly (for our matter of the Epic), all this makes it complicated to control when a user makes a project private (by removing user and/org group permissions)

      Use Cases

      As a SQ.com user who has access to an organization which has public and private projects, I want to quickly identify private projects thanks to a label or icon:

      • On the "Projects" page (may it be "My Favorites" or "All")
      • On the home page of the org
      • On the home page of a project

      As a project administrator, when I go to "Administration > Permission", I expect to:

      • Clearly see if the project is public or private
      • Have a simple way to turn the project from public to private - or the other way around:
        • With a description that explains what this implies
        • See the following screenshot to have an example
        • On a public project:
          • I can only manage the "Administer Issues", "Administer" and "Execute Analysis" permissions
            • For "Browse" and "See Source Code": either we don't display them at all, or we grey them out (= disabled).
          • This means that a public project can therefore be accessed by any body, authenticated or not (authentication can be controled by "force authentication" feature)
        • On a private project:
          • On top of the 3 other permissions, I can also see and manage the "Browse" and "See Source Code" permissions
          • This means that a private project behaves like projects prior to 6.4
        • Whatever the project (public or private), "anyone" must not be available as a choice when I grand permissions

      As an org administrator:

      • I can specify the default visibility for new projects: "Public" or "Private"
        • If I run an analysis on a project w/o provisioning/creating it first, this default visibility will be used
        • If I go to "Administration > Project Management" to provision/create the project first, I expect to have a way to choose between private or public in the create modal window - the option being selected by default depending on the organization default visibility for projects
        • Note: when organization are not activated, default visibility is always "Public" (i.e. it's possible to specify the default visibility only when orgs are activated).
      • When I go to "Administration > Permission Templates", I expect to be able to understand that the "Browse" and "See Source Code" permissions are not used when applying the permission template to a public project

      Impact on existing SonarQube instances (migration)

      For all SonarQube instances (i.e. product migration):

      • For project permissions:
        • Remove "anyone" from any permission
        • If for a given project, we detect that "anyone" has "Browse" and "See Source Code", make the project public. Make it "private" otherwise.
      • For permission templates:
        • Same logic as for project permissions

      On top of that, a dedicated script must be executed on SonarQube.com once the upgrade run successfully:

      • Turn all private projects to public
        • Rationale: the product migration (described above) will turn some existing SQ.com projects to "private" because some users remove "anyone" from their project. So we must make sure that all projects are back to "public" to be in a correct state with regards to the free plan that does not allow to have private projects.

      Open questions

      • ?


      Original spec and goal of this MMF was to remove the concept of "anyone" - see the backup of this spec on Confluence. Maybe what described originally in this MMF is still valid (or not) - this needs to be discussed during the technical design.

      Current design proposition

      A badge "Private" next to the project's name is visible for org members. It is visible on Projects page, project's homepage and org page.

      In a Project's Administration tab, you can switch your project to public or private. There's a disclaimer popup when turning it to public.

      In the Org Admin, you can set the default visibility of new projects

      When creating a new project, you can also choose the visibility

      In the Permission Templates page, you can see a disclaimer in the tooltips of "Browse" and "See Source Code" options.

      When trying to apply a permission template with "Browse" and/or "See Source Code" disabled on a public project, a disclaimer will also appear.


        1. Private_Projects_01.png
          170 kB
        2. Private_Projects_02.png
          199 kB
        3. Private_Projects_03_V2.png
          120 kB
        4. Private_Projects_03.png
          121 kB
        5. Private_Projects_04_V2.png
          128 kB
        6. Private_Projects_04.png
          131 kB
        7. Private_Projects_05_V2.png
          110 kB
        8. Private_Projects_05.png
          112 kB
        9. Private_Projects_06_V2.png
          156 kB
        10. Private_Projects_06_V5.png
          158 kB
        11. Private_Projects_06_V5.png
          161 kB
        12. Private_Projects_06_V6.png
          161 kB
        13. Private_Projects_06.png
          152 kB
        14. Private_Projects_07_V2.png
          138 kB
        15. Private_Projects_07_V3.png
          139 kB
        16. Private_Projects_07.png
          141 kB
        17. Private_Projects_08_V2.png
          141 kB
        18. Private_Projects_08_V3.png
          160 kB
        19. Private_Projects_09_V1.png
          159 kB
        20. Private_Projects_10_V1.png
          158 kB
        21. Private_Projects_11_V1.png
          163 kB

          Issue Links



              fabrice.bellingard Fabrice Bellingard
              simon.brandhof Simon Brandhof (Inactive)
              0 Vote for this issue
              4 Start watching this issue