1. Home
  2. Account Management
  3. Migrating to the New User Management

Migrating to the New User Management

Updated on May 16, 2019 Download PDFDownload as PDF
Download PDF

Brief Overview

This article provides a more detailed and technical description of how the migration is performed from the legacy User Management system to the new User Management system.

For more information about the new User Management system. See here.

Why do we need the migration

In the legacy User Management, it was possible to assign different roles per environment.
E.g. it was possible to assign to a user, an Admin role for production env and a Translator role for test env.

In the new User Management, it is possible to assign only a single role regardless of the environment.

The migration process of users needs to do 2 things:

  1. Decide what is the single role to be assigned in the new system.
  2. Decide what are the publishing rights to be assigned for each environment in the new system role.

Which role would the user be assigned to

The goal for the migration process is to have each user keep their current permissions.
It was important that no users get rights they didn’t have before and that no users are blocked from performing actions they could do before.

Migrating roles

  • All default and custom roles have been migrated by granting the same permissions for each feature from the legacy system to the new system.
  • The main publishing rights value in the new system will match the publish right in the legacy system.
  • The publishing rights for each environment will match the publishing rights in the legacy system.

In the example below, the role assigned to production in the legacy system is Workspace Owner, and the Admin & Publisher roles have the same publishing rights as the Workspace Owner (Write), so the user in the new system shall be assigned the Workspace Owner role.

A user who has different roles per environment, and all the roles have different publishing rights, will be assigned a newly created custom role.
The new custom role in the new system shall have publishing rights per environment that match the publishing rights per environment of roles that were in the legacy system.

Migrating Users With the Same Role Per Environment

A user who has the same role across all environments in the legacy system would simply be assigned with that role in the new system.

Migrating Users With Different Roles Per Environment

A user which has different roles per environment in the legacy system, but all roles have the same publishing rights, shall be assigned with the production role of the legacy system, in the new system.

There are 2 cases here:

  1. All roles have the same publishing rights
  2. Not all roles have the same publishing rights

All roles have the same publishing rights

A user which has different roles per environment in the legacy system, but all roles have the same publishing rights, shall be assigned with the production role of the legacy system, in the new system.
In the example below, the role assigned to production in the legacy system is Workspace Owner, and the Admin & Publisher roles have the same publishing rights as the Workspace Owner (Write), so the user in the new system shall be assigned the Workspace Owner role.

Not all roles have the same publishing rights

A user who has different roles per environment, and all the roles have different publishing rights, shall be assigned with a newly created custom role.
The new custom role in the new system shall have publishing rights per environment that match the publishing rights per environment of roles in the legacy system.

                           

Was this article helpful?

Related Articles