task-l.3
This commit is contained in:
@@ -398,3 +398,35 @@ Future:
|
||||
|
||||
- decide which non-revenue widgets should fully honor project-party role filtering
|
||||
- add a unified filtered reporting projection if cross-widget party-role filtering becomes a hard requirement
|
||||
|
||||
## After Task L.3
|
||||
|
||||
### Customer and contact ownership enforcement
|
||||
|
||||
Current:
|
||||
Customer/contact modules are still more organization-wide than quotation security and need the same resolved ownership model applied consistently.
|
||||
|
||||
Future:
|
||||
|
||||
- add resolved CRM access context to every customer/contact service path
|
||||
- enforce shared-contact visibility without falling back to blanket organization reads
|
||||
|
||||
### Approval visibility scoping
|
||||
|
||||
Current:
|
||||
Approval step handling now resolves multi-role actors correctly, but approval list/detail visibility is still broader than final quotation-scoped security.
|
||||
|
||||
Future:
|
||||
|
||||
- scope approval requests by accessible entity visibility, not organization membership alone
|
||||
- align dashboard approval widgets and approval detail pages with the same rule
|
||||
|
||||
### Team-scope fidelity
|
||||
|
||||
Current:
|
||||
Resolved CRM access supports `team`, but the domain still lacks a first-class subordinate/team graph for precise enforcement.
|
||||
|
||||
Future:
|
||||
|
||||
- define the canonical team relationship source
|
||||
- replace current coarse team handling with explicit team membership or manager hierarchy logic
|
||||
|
||||
Reference in New Issue
Block a user