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

A project must belong to an organization


    • Type: EPIC
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:
    • Epic Name:
      Projects belong to Org


      Main Targets

      At the end of this Epic, a project must always belong to an organization and:

      • When there's only 1 org (the default one), we expect the UI to behave exactly as in previous versions
        • For more simplicity, we will call that mode "OnPrem" - simply because this is the main use case when installing SQ on premise
      • When several orgs are defined, the UI must adapt to display the org of a project (everywhere) and list projects in the context of an org (new space with basic admin actions - edit and delete)
        • For more simplicity, we will call that mode "Cloud" - simply because this is the main use case for SQ.com

      This obviously means that the scanners must support the concept of organization to be able to feed SonarQube.

      Main Features

      What is described here (as well as all the MMF of this Epic) describes the features for the Cloud mode. (remember: nothing - or almost nothing - must change for OnPrem mode)

      Cloud mode is activated thanks to the call of a dedicated WS. Once activated, it's not possible to get back to "OnPrem" mode (for the time being). The user who makes this WS call to activate orgs becomes "root" and can later on add other root users.

      Rough overview of what is expected: https://xtranet.sonarsource.com/pages/viewpage.action?pageId=20519492

      • The "Projects" and "Issues" pages display the org name in front of the project names - but behaves exactly as before for anything else
        • And this must be the same for any other page/service in SonarQube (i.e. augment the project name with the name of its org)
      • When clicking on a project, the project space is displayed:
        • With the name of the org in front of the project name
        • The "Key" description must be updated to reflect the belonging to the org
        • All the rest must work as before
      • When clicking on a org, a new org space is displayed:
        • With a "Projects" (main) page that lists all the projects of that org - in the exact same way as the top "Projects" page
        • If the user is an admin of the org, with a "Administration" menu that allows to:
          • Edit the org
          • Delete the org
          • Nice-to-have: access pages to administer Users, Groups and Permission Templates
      • When the user goes on his "Account" space:
        • Groups are no more displayed in the "Profile" tab
        • "Projects" tab is replaced by "Organizations" tab which lists all the orgs that the user belongs to with actions to access and administer (when the user is the admin) them.

      What is not visible in the page is that scanners must support a new "org" parameter that will default to the default organization when not provided by the user.

      Technical Details

      To be able to do all this incrementally, there's only one constraint that will be removed later on: project keys must continue to be unique - even accros organizations.


          Issue Links



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


                • Created: