Amsterdam: Introducing a redesigned permission model (LifeTime)

Amsterdam: Introducing a redesigned permission model (LifeTime)

  

Hi,

Starting with OutSystems Platform 9 Amsterdam, we are introducing a redesigned permission model.


Granting permissions to IT users - before  P9 Amsterdam

Before P9 Amsterdam, whenever you wanted to grant permissions to IT users you would do the following:

  • Grant the user with a base role;

  • Grant the user with a specific permission per application using a slider for each environment.



In the example above, Andrea has the Developer role, which grants her permissions to:

  • Open & Reuse all applications in the “Development” environment;

  • List versions for all applications in the “Quality Assurance” and “Production” environments.


We’ve also extended her permissions to:

  • Change & Deploy the Time Sheets and Vacations applications in the “Development” environment

  • Open & Reuse the Time Sheets and Vacations applications in the “Quality Assurance” environment


Granting permissions to IT users - From P9 Amsterdam Onwards

Starting with P9 Amsterdam, in order to achieve the same functionality you will need to do the following:

  • Grant the user with a default role, just as before;

  • Create or reuse a role that defines the same permission levels that you had already defined for each application;

  • Assign that role to the user, for a specific application. That way, the user is assigned the permissions of that role, but just for a specific application.



In the example above, Anna has the Developer role, which grants her permissions to:

  • Change & Deploy all applications in the “Development” environment;

  • List versions for all applications in the “Quality Assurance” environment.


We’ve also assigned her the:

  • Monitor role for the Geo application, which grants her privileges to Reuse & Monitor that application in both environments.  Reuse & Monitor is the new name for the Open & Reuse permission level;

  • Delivery Manager role, for the Paypal connector application. This grants her privileges to Change & Deploy that application in both environments


Once you have created roles with the appropriate permission levels, you can easily apply them to other users in other applications, without having to pick the right slider position for each application in each environment again.


It is worth mentioning that the user gets the permission level associated with the most specific role. In the scenario above, although Anna has Change & Deploy permissions in the Development environment (from the Developer default role assigned to her), she only has permissions to Reuse & Monitor the Geo application.

This happens because the application-specific role, overrides the permission level granted by the default role.


Upgrading to P9 Amsterdam

Once you upgrade your OutSystems Platform, all application-specific permissions are automatically transformed into roles named “CreatedOnUpgrade_<number>”.


These roles are then assigned to users for each specific application with defined permissions, thus keeping all user permissions the same, after upgrading.

For instance, if Dave had permissions to Change & Deploy the “Directory” application in Development but only Open & Reuse it in Quality Assurance, he will have the same permissions. The only thing different is that these permissions will be represented as a role.


All you need to do is change the names of these roles to something that is meaningful in your infrastructure. Or you can keep them as is, as the permission levels will not be changed.


Introducing Teams, and Application Manager

Starting with P9 Amsterdam, OutSystems Platform allows you to organize your users and applications into teams.

A team is a set of users and applications, and each team member has a role that applies to all the applications managed by the team.


We’re also introducing the Application and Team Manager permission. Users that have this permission for a specific application, can manage the permissions other users have for that application, without having permissions for any other app.


Similarly, if a user has that permission over a team, the user can add and remove other users to the team, thus no longer requiring the Administrator role to do this operation.


What’s the priority among different roles that have been granted to a user?

The answer to this one is quite simple. The permission levels associated with the most specific role always prevail and override the more generic roles, as depicted by the following rules:


  • User has just default role

    • Default role permissions apply to all applications

  • User has default role and team role

    • Team role permissions apply to all applications inside the team

    • Default role permissions apply to all other applications

  • User has default role and application specific role

    • Application specific role permissions apply to that application

    • Default role permissions apply to all other applications

  • User has default role, team role in team, application specific role, and application belongs to a team where the user has a role

    • Application specific role permissions apply to that application

    • Team role permissions apply to all applications in the team

    • Default role permissions apply to all other applications


Introducing Permissions for System Components Applications

Before P9 Amsterdam, it wasn’t possible to grant specific permissions for System Components applications. The permissions were implicitly defined by the default role assigned to the user.


Starting with P9 Amsterdam, the default role assigned to a user specifies the permissions the user has for all applications (including System Components), and you can extend those permissions by assigning an application specific role.


This means that you have a finer-grained level of control over the privileges of your users regarding all applications (including System Components).


When you upgrade your platform to P9 Amsterdam, your already existing users will be given a specific role for the System Components applications, based on the permissions they already had (implicitly defined by their role) prior to the upgrade. This allows you to transparently see the permissions that you already had, even if you did not know about them. You can delete these specific assignment of roles in the System Component applications at will, or change them to fit your needs.

Enjoy!