42 lines
1.6 KiB
Markdown
42 lines
1.6 KiB
Markdown
# Team Scope Limitations
|
|
|
|
## Current Team Scope Logic
|
|
|
|
Current CRM authorization resolves the most permissive ownership scope from active CRM role assignments.
|
|
|
|
For `team` scope today:
|
|
|
|
- quotation visibility is effectively broader than `own`, but still constrained by branch scope and product scope
|
|
- customer visibility is approximated from branch scope plus related enquiry/quotation relationships
|
|
- approval visibility inherits quotation visibility or current approval-actor visibility
|
|
|
|
## Known Limitations
|
|
|
|
There is not yet a first-class team hierarchy model in the domain.
|
|
|
|
That means the system does **not** currently know:
|
|
|
|
- who reports to whom
|
|
- which sales users belong to the same explicit team
|
|
- whether a manager should see one subset of sales users but not another inside the same branch
|
|
|
|
Because of that, `team` currently behaves as an approximate operational scope rather than a strict org-chart scope.
|
|
|
|
## Contact Sharing Status
|
|
|
|
The production schema now includes persisted contact sharing.
|
|
|
|
Result:
|
|
|
|
- contact visibility is enforced through customer ownership, contact creator visibility, and explicit contact-share grants
|
|
- cross-owner contact access can now be granted and revoked without relying on demo/mock behavior
|
|
|
|
## Future Team Hierarchy Model
|
|
|
|
Recommended future direction:
|
|
|
|
1. add a first-class manager/team relationship model
|
|
2. resolve `team` scope from that relationship instead of permissive approximation
|
|
3. keep expanding security fixtures around owner/share behavior once a first-class team graph exists
|
|
4. expand runtime security fixtures around manager-team boundaries after real hierarchy data exists
|