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.

Please authenticate to join the conversation.

Upvoters
Status

Planned

Board
🏠

Main App

Date

2 months ago

Author

Linear

Subscribe to post

Get notified by email when there are changes.