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 Limitation
|
|
|
|
The production schema currently has no persisted contact-sharing table.
|
|
|
|
Result:
|
|
|
|
- contact visibility is enforced through customer ownership plus contact creator visibility
|
|
- mock/demo shared-contact behavior from legacy demo data is not part of the production boundary yet
|
|
|
|
## 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. add explicit contact-sharing persistence if the business still requires cross-owner contact access
|
|
4. expand runtime security fixtures around manager-team boundaries after real hierarchy data exists
|