← Back to Activities Workflows

5.6.5 Activities Security Patterns

Activities combines tenant isolation, CakePHP policies, branch-scoped RBAC, ownership/parent rules, workflow approver resolution, validation, and narrow mass assignment. No single layer replaces the others.

Entity and collection authorization

ActivityPolicy/ActivityGroupPolicy protect individual configuration records. Their table policies protect collections and map grid scope to the index scope. AuthorizationPolicy adds domain actions for add, renew, revoke, retract, member/activity views, and reports.

Self-service is implemented through Member::canManageMember(), which supports the current member and the supported parent/minor relationship. Retraction is owner-management only; administrative revocation uses RBAC.

Approver discovery

An Activity identifies the required permission. Activity::getApproversQuery() delegates to PermissionsLoader with a branch ID, while the workflow provider/action resolves the approval participants. Never accept an arbitrary approver from the client without checking that query and workflow rules.

Input and output rules

• Patch only fields intended for the action; entity _accessible maps do not grant permission.
• Keep status, revoker, role-grant, approval, and audit fields service/workflow controlled.
• Scope lists, counts, API results, autocomplete, and exports before serialization.
• Do not expose member contact data in approver results unless the interaction requires and authorizes it.
• Avoid placing private member details in workflow context or notifications beyond their declared schema.

Tenant and test rules

All permission, member, role, activity, and approval queries run inside one tenant. Cache permission results with tenant namespacing. Tests should cover self, parent/minor, unrelated member, branch-authorized administrator, wrong branch, eligible/ineligible approver, missing permission configuration, malformed IDs, and two tenants with colliding numeric IDs.