allagroup/alla-allaos-fullstack
Template
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

task-l.3.1

Browse Source
This commit is contained in:
phaichayon
2026-06-22 14:18:26 +07:00
parent 42f403a7ed
commit 1b901efc51
21 changed files with 1320 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/security/crm-authorization-boundaries.md
View File

@@ -56,6 +56,34 @@ Approval step handling must use resolved CRM role unions instead of a single leg
- `organization`: organization-wide inside active tenant
- `monitor`: read-oriented role with limited commercial visibility
## Customer Boundary
Customer visibility is now enforced from resolved CRM access.
- `organization` and admin scopes can see organization customers within branch scope
- `team` currently behaves as branch/product-scoped broad visibility until a first-class team graph exists
- `own` can see customers they created or customers linked to enquiries/quotations they can already access
- `monitor` can see customers only when those customers are related to visible lead/enquiry records
## Contact Boundary
Contact visibility is enforced through customer visibility plus contact ownership rules.
- if a user can access the parent customer, they can access its contact list within their role boundary
- contact creators retain access to their own contacts
- admin/organization scope retains access
- production shared-contact persistence does not exist yet, so legacy demo sharing is not part of the live authorization boundary
## Approval Boundary
Approval visibility is now narrower than generic approval-read permission.
A user can see approval records only when at least one of these is true:
1. they can access the related quotation through resolved CRM scope
2. they are the current approval actor by resolved CRM role
3. they are admin / organization-wide CRM authority
## Artifact Boundary
Artifact permission alone is not enough for approved quotation PDFs.
@@ -74,6 +102,8 @@ Dashboard access is split:
- approval widgets: approval read permission
- export visibility: same scope as dashboard, with extra revenue export restriction
Approval widgets additionally inherit approval-request visibility rules, not just a raw approval permission.
## Audit Events
Security-sensitive denials are recorded under entity type `crm_security_access` with actions: