feat: add supervisor role

config/packages/security.yaml

@@ -7,6 +7,13 @@ security:
     # No password_hashers: there are no passwords here. Authentication is OAuth2 against myep,
     # which owns the credentials; ephub only ever sees a userinfo response.
 
+    # An administrator can do everything a supervisor can, so the "may act on other people's
+    # bookings" checks ask for ROLE_SUPERVISOR alone. Only isGranted() sees this:
+    # User::getRoles() still returns the stored roles, which is why CodeVisibility names
+    # ROLE_ADMIN explicitly.
+    role_hierarchy:
+        ROLE_ADMIN: [ROLE_SUPERVISOR]
+
     providers:
         app_user_provider:
             entity:
@@ -46,8 +53,11 @@ security:
         # Before the catch-all, or ROLE_EMPLOYEE would match ^/ first and the admin area would be
         # open to everybody. Order is the whole guard here.
         - { path: ^/admin, roles: ROLE_ADMIN, requires_channel: https }
-        # Either role opens the app -- access_control treats a list of roles as an OR. Not
+        # Everybody's bookings, for supervisors and (through role_hierarchy) administrators. Kept
+        # out of ^/admin so that everything under it stays administrator-only.
+        - { path: ^/manage, roles: ROLE_SUPERVISOR, requires_channel: https }
+        # Any of these opens the app -- access_control treats a list of roles as an OR. Not
         # ROLE_USER: myep authenticates far more people than work here, and someone who holds
-        # neither of these is refused at login with an explanation rather than let in to an
-        # empty screen.
-        - { path: ^/, roles: [ROLE_EMPLOYEE, ROLE_ADMIN], requires_channel: https }
+        # none of these is refused at login with an explanation rather than let in to an empty
+        # screen. Keep in step with Role::ELIGIBLE.
+        - { path: ^/, roles: [ROLE_EMPLOYEE, ROLE_SUPERVISOR, ROLE_ADMIN], requires_channel: https }