5.2.13 RecommendationPolicy Reference
Source: app/plugins/Awards/src/Policy/RecommendationPolicy.php
RecommendationPolicy is the central entity-level authorization policy for recommendations. It combines configured RBAC rules with workflow-aware visibility and state locks.
Important custom behavior
- Current workflow approvers and retained prior approvers may receive read-only visibility.
- A member with pending recommendation approval work can receive index access even without the normal index grant; the table scope limits the rows.
- Recommendations owned by an active bestowal are locked against incompatible edit/delete/state/group operations.
- Separate methods protect approval decisions/start, state updates, exports, hidden content, private notes, note creation, feedback request/retraction/administration, grouping, and “submitted by/for member” or event views.
- Dynamic
canApproveLevel*methods are resolved in__call()and feed Awards/Recommendation table scoping.
The policy consults workflow approvals/runs and RecommendationWorkflowUiService; callers must load enough recommendation context for the relevant decision. Do not duplicate its workflow visibility tests in controllers or templates.
Usage
Authorize the specific domain action, not a nearby CRUD action. For example, an identity able to view a recommendation is not automatically allowed to view private notes or decide an approval. Pair entity authorization with RecommendationsTablePolicy for every collection/grid/export query.
Testing
Cover normal RBAC allow/deny, current and prior approvers, pending-work index access, bestowal locks, dynamic level permissions, feedback, hidden/private content, grouping, and tenant isolation. Include query-count/regression coverage when changing request-local policy caches.