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

Support external user account renaming in SonarCloud



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


      Context - Why

      See SONARCLOUD-42:

      Over the past months, we've had many contact requests of GitHub users who could not log in to SonarCloud after they changed their username on GitHub.

      The problem is partially fixed thanks to MMF-1161: they can now log in with their new username. The problem is that under the hood, this creates a new SonarCloud user who has nothing to do with the former one. The consequence is that the user loses his permissions, favorites, tokens, ...

      Note: if the user simply changed the case of the login (for instance from "Foo" to "foo"), then it's simply impossible to log in again - even with MMF-1161.

      We should find a way to support these use cases that happen quite often.

      Use Cases - What

      As a GitHub user:

      1. I change my username on GitHub from "foo" to "bar"
      2. Next time I connect to SonarCloud, I expect to get a warning message (like when the email is stolen from one account to another) saying:

        We noticed that you recently renamed your username on [GitHub|Bitbucket|VSTS]. As a consequence, we have updated your SonarCloud login and personal organization accordingly.
        Please update the build scripts that might be using your old personal organization key, or any Web Service call that might be referencing your old SonarCloud login.

      3. Once I have acknowledge this warning, I can see in the Web UI that:
        • My username was updated from "foo@github" to "bar@github"
        • My personal organization was updated from "foo-github" to "bar-github"
      4. Obviously, I still see my favorites, my settings, my tokens, my notifications, ... etc.

      Important: with MMF, we should make sure that when a GitHub user simply changes the case of her username (e.g. from "foo" to "Foo"), everything works smoothly too.

      Implementation - How

      The Identity Provider API should allow to provide a provider unique ID, which will be stored in the USERS table.
      This ID will be used to identify user during authentication (login won't be used anymore).

      During authentication, when detecting that the login has been updated, the user will be redirect to a page where we explain to him what will be the consequence of the renaming of the login on his personal organization (This behaviour will looks like what was done for https://jira.sonarsource.com/browse/MMF-1161).

      A UUID should be added to the USERS table in order to not use anymore the LOGIN in other tables.
      For new users, this column will contain a generated UUID, and for existing users it will be the login, in order to not have to perform a huge DB migration.


          Issue Links



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