Add granular workorder page permissions by section and feature

Objective

• Add granular instance-level permissions for the work order and other in-instance surfaces—sections, sensitive actions, and feature-specific access—so managers can default broad access then dial back per user/role (subtractive model discussed in planning).

Background

• Standalone rollout increases need to limit who sees activity, charges/actions, integrations, files, etc., without removing all work-order access.
• Apr 28 implementation transcript reinforced that teams want this to go much deeper, including separate control over event editing, work order actions, and other micro-permissions that should not be bundled into broad access.
• The transcript also made it clear that this work should line up with reusable permission templates so admins are not forced to configure this level of granularity one user at a time across many brands.
• This issue is now the main container for instance-specific permission expansion. The companion admin-level program for cross-instance permission management lives in ATT-1176.

Program framing

• Use this issue to collect and organize instance-level permission surfaces that need to be added or split out, especially where teams need finer control over what users can view, edit, or trigger within an instance.
• Keep larger adjacent workstreams linked as related issues when they inform this program but may remain independently sizable.

Scope

Frontend

• Staff permission UX lives under attik-frontend/src/app/tools/settings/users/[id]/PermissionCheckboxes.tsx and DataForm.tsx. Extend schema/UI with a dedicated work order permission group; gate panels/tabs/actions on the work order accordingly.

Backend

• Persist new permission keys on the user/role model and enforce in API routes that mutate sensitive work-order resources (decision needed: exact key names and default-on behavior).

References

• attik-frontend/src/app/tools/settings/users/[id]/PermissionCheckboxes.tsx
• attik-frontend/src/app/tools/settings/users/[id]/DataForm.tsx

Additional transcript context

• Teams asked for permission coverage to be consistent so users cannot bypass self-only restrictions through side paths like event editing.
• New permissions should likely default conservatively for non-admin users so new features do not silently grant risky access.
• This should be designed in tandem with permission templates and template propagation across brands/locations.