- Introduced phase 4 documentation detailing treatment estimates, data models, state machines, API endpoints, and new dashboard metrics. - Added phase 5 documentation covering consumables, lab operations, periodontal charts, sterilization cycles, clinical images, and a checklist for professional review. - Created a preset content document outlining default dental service packages and protocols for clinics.
14 lines
846 B
Markdown
14 lines
846 B
Markdown
# Practice domain belongs to the tenant, not only to the clinic
|
|
|
|
`practice_domain_id` originally lived on `clinics`, but every piece of operational data in this
|
|
codebase is owned by an `(entity_type, entity_id)` pair where `entity_type` is `doctor` or `clinic`.
|
|
A solo practice is a `doctor` tenant, so it could never declare a practice domain at all — the beauty
|
|
domain has the same hole, it simply had not been noticed. The column is therefore added to `doctors`
|
|
as well and read through a single `PracticeDomainResolver` that takes an `EntityContext`, so no
|
|
caller has to know which kind of tenant it is looking at.
|
|
|
|
## Considered Options
|
|
|
|
Letting a doctor inherit the domain of a clinic they work at was rejected: a doctor with no clinic
|
|
would stay domainless, and a doctor working at two clinics with different domains would be ambiguous.
|