Starting with OutSystems Platform 9 Amsterdam, we are introducing a redesigned permission model.
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
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.
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.
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
User has default role, team role in team, application specific role, and application belongs to a team where the user has a role
Team role permissions apply to all applications in the team
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.