Problem/Motivation
yoyaku_manager assigns managers one resource at a time, through the yoyaku_resource_manager junction. That fits venues like mountain refuges, where each refuge is in a different place and run by a different team. It does not fit a venue like an auditorium, where a single team runs every event: today that means granting the team on every event, which is tedious and easy to get wrong.
Resources already nest under a hierarchy: a resource has a tenant, and its resource type also carries a tenant scope (empty means shared). Managership should be grantable higher up that hierarchy, not only per resource.
Proposed resolution
Generalize the grant so a manager can be assigned at one of three scopes: a single resource (as now), a resource type (every event of that type), or a whole tenant (everything in it). As the module is pre-1.0, fold the resource-only junction into one polymorphic grant entity rather than adding parallel entities.
- The grant carries its scope, its target (resource, type or tenant) and the existing authority tenant, plus granted_by and expiry.
- A single resolver turns each grant into resource ids (resource: itself; type: resources of that type; tenant: resources of that tenant), merged through the existing tagged-resolver seam, so enforcement is unchanged and events added later are covered automatically.
- Grant authority stays per tenant: a type or tenant grant is authored by whoever may assign managers in that tenant.
- One assignment screen to pick user, scope, target and expiry, alongside the existing per-resource entry point.
Remaining tasks
- Unified grant entity and resolver.
- Assignment UI and per-tenant authority checks.
- Kernel coverage for each scope and their union.
- Documentation and French translation.
Issue fork yoyaku-3612851
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mably commentedComment #5
mably commented