Role-based access control
Waldur authorization system determines what user can do. It consists of permissions and roles. Permission is unique string designating action to be executed. Role is named set of permissions.
Permissions are defined in
PermissionEnum which is automatically generated from backend code and pushed to fronted code by GitLab CI. Most of the time you're going to use
hasPermission function which checks, whether user is allowed to perform action on given customer, project or offering. The following example shows how to check whether user is allowed to create offering in organization.
1 2 3 4 5 6 7
Previously we have relied on hard-coded roles, such as customer owner and project manager. Migration to dynamic roles on frontend is relatively straightforward process. Consider the following example.
1 2 3 4 5 6 7 8 9
As you may see, we have relied on selectors with hard-coded roles. The main drawback of this approach is that it is very hard to inspect who can do what without reading all source code. And it is even hard to adjust this behaviour. Contrary to its name, by using dynamic roles we don't need to care much about roles though.
1 2 3 4 5 6 7 8 9 10
The only prerequisite of course is to ensure that backend uses dynamic roles too.