Define available user roles

[cyrildewit]

Description

We need to analyse which roles we need within the application at this moment. We can then create these roles automatically in each environment.

Analysis

What types of users will live within the current system?

• Member (default) lowest role within the application that all standard users have.
• Handyman or concierge: user that is part of the "Klusgroep" and has extra capabilities to do his job
• Admin: role that has all permissions

Technical requirements

These roles and permissions should be synchronised or maintained in each environment. Both web and rest_api guards needs to have the same setup.

Advice

Since we don't have a admin dashboard for now where we can create a functionality to manage the roles and permissions within the system, we will be maintaining these mappings in-code for now. This will spare us some time for now and we can make sure the roles and permissions are on each environment equal.

Design

Create a new directory in App called ACL (meaning Access Control List) containing interface PermissionsInterface. This interface will contain a list of public constants defining all the permissions within the system.

We will create the roles-permission mapping inside specific role classes in App/ACL/Roles. These classes will provide a method called getPermissions(): array providing all their permissions.

A service should synchronise these mappings with the database. We can execute this action automatically after each deployment, so new changes to these mappings are applied.

The service can then be used in a console command. This command can be fired after each deployment

Realisation

Tests

Feature

• [x] ACLService@synchroniseRolesAndPermissions - Make sure the expected state is there after running the logic. Since the logic uses functionality from the laravel-permission package, testing this logic is unnecessary and not our responsibility.
• [x] GuardService@getByName - Make sure it can find one.
• [x] GuardService@getByName - Make sure it throws an exception if nothing is found.
• [x] GuardService@ existsByName - Make sure it can find one.
• [x] GuardService@ existsByName - Make sure it can not find one.
• [x] SynchroniseRoleAndPermissions@handle - Follow the happy flow.
• [x] SynchroniseRoleAndPermissions@handle - Stop executing if guard name is not valid.
• [x] Test the gate fore hook for role admin. It should always have the rights.

[cyrildewit]

@MiKessels @Prupke @Hoopless can you provide some feedback about the current identified roles? Since most of you have done an analysis, am I missing a few? Or do you think we need more distinctions. And are the names fine? They are for internal reference. Thank you. This way we can finish this ticket.

[MiKessels]

As discussed earlier, the roles are good and are future-proof. For now, probably admin and concierge are the same. In the future you want the admin to add people, for instance, the concierge doesn't need this permission.

I don't think we need more roles (for now). But be prepared for more roles when the app becomes bigger. For instance, an overall admin, but also an admin for the concierges or/and an admin for space management. I think the more features are live the more roles are needed in future releases.