feat: derive ROLE_EMPLOYEE from the account's email domain
This commit is contained in:
+17
-3
@@ -16,6 +16,13 @@ namespace App\Security;
|
||||
* nothing until an administrator approves it in /admin/user. The CRM's word alone is enough to
|
||||
* take a role away, never to hand it out, and an administrator's word alone is enough for
|
||||
* neither.
|
||||
*
|
||||
* One role is not claimed by the CRM at all: ROLE_EMPLOYEE is derived from the account's own
|
||||
* email domain, because BusPro has no selection expressing "works here". It is passed to sync()
|
||||
* as a claim alongside the CRM's, so it is granted and revoked by exactly the same machinery.
|
||||
* That widens a claim from "what the CRM reports" to "what the CRM reports plus what the account
|
||||
* itself implies", and nothing more: ROLE_EMPLOYEE is not administrative, so it cannot reach the
|
||||
* nomination path, and the CRM remains the only source for every role that grants privileges.
|
||||
*/
|
||||
final class Role
|
||||
{
|
||||
@@ -32,6 +39,7 @@ final class Role
|
||||
public const HOUSE_MANAGER = 'ROLE_HOUSE_MANAGER';
|
||||
public const GROUPS_ADMIN = 'ROLE_GROUPS_ADMIN';
|
||||
public const GROUPS_MANAGER = 'ROLE_GROUPS_MANAGER';
|
||||
public const EMPLOYEE = 'ROLE_EMPLOYEE';
|
||||
|
||||
/**
|
||||
* Appended to an administrative role to mark it as claimed by the CRM but not yet approved.
|
||||
@@ -55,17 +63,21 @@ final class Role
|
||||
self::HOUSE_MANAGER,
|
||||
self::GROUPS_ADMIN,
|
||||
self::GROUPS_MANAGER,
|
||||
self::EMPLOYEE,
|
||||
];
|
||||
|
||||
/**
|
||||
* Roles the CRM grants outright. ROLE_CUSTOMER is never claimed by BusPro — it is the
|
||||
* fallback for an account left without any effective role, and exclusive with the others.
|
||||
* Roles granted outright, without an approval step. ROLE_CUSTOMER is never claimed by BusPro —
|
||||
* it is the fallback for an account left without any effective role, and exclusive with the
|
||||
* others. ROLE_EMPLOYEE is not claimed by BusPro either: it is derived from the account's own
|
||||
* email domain (see EmployeeDomainMatcher) and, being effective, displaces that fallback.
|
||||
*
|
||||
* @var string[]
|
||||
*/
|
||||
public const UNCONDITIONAL = [
|
||||
self::TEAMER,
|
||||
self::CUSTOMER,
|
||||
self::EMPLOYEE,
|
||||
];
|
||||
|
||||
/**
|
||||
@@ -180,7 +192,8 @@ final class Role
|
||||
* Nothing here can raise a privilege: step 3 only ever produces markers.
|
||||
*
|
||||
* @param string[] $storedRoles
|
||||
* @param string[] $claimedRoles what the CRM reports
|
||||
* @param string[] $claimedRoles what the CRM reports, plus the roles derived from the account
|
||||
* itself (ROLE_EMPLOYEE); anything outside self::ALL is ignored
|
||||
*
|
||||
* @return string[]
|
||||
*/
|
||||
@@ -274,6 +287,7 @@ final class Role
|
||||
self::HOUSE_MANAGER => 'Hausleitung',
|
||||
self::GROUPS_ADMIN => 'Preisrechner Admin',
|
||||
self::GROUPS_MANAGER => 'Preisrechner',
|
||||
self::EMPLOYEE => 'Mitarbeiter:in',
|
||||
];
|
||||
|
||||
foreach (self::ADMINISTRATIVE as $role) {
|
||||
|
||||
Reference in New Issue
Block a user