Description
View Property Personalization stores how properties appear in a specific saved view, independent of the shared schema and row values.
View Property Personalization is delivered through typed package contracts rather than a surface-specific shortcut. Its primary modules separate the public input or configuration shape from validation, durable state, and the operation that produces the result. That separation lets product surfaces and integrations invoke one implementation while tenant scope and existing domain rules remain in force. Errors stay bounded to the request instead of weakening the underlying data contract.
Selling Points
- Hides irrelevant fields without deleting data.
- Preserves ordering and column widths per perspective.
- Separates presentation choices from schema changes.
- Applies one typed package contract across every supported caller and surface.
- Keeps invalid inputs and unavailable dependencies from silently widening durable state.
User Story
As a sales lead, I show pipeline fields in my board while the finance view emphasizes value and forecast data. In practice, I configure or invoke the capability through a supported surface, supply only the inputs its contract accepts, and receive a result governed by the same rules as every other caller. I can inspect the resulting row, setting, event, or query state and correct my input when validation fails. I walk away with a repeatable workflow rather than a one-off client implementation.
Extension Surface
Configurable: callers set visibility, ordering, widths, and supported display flags through validated service inputs.
The configurable rating is evidenced by packages/dotabases/src/services/view-property-settings.ts, which defines the supported seam used by trusted callers or configuration. The capability can be composed wherever that contract is available, but its invariants are not replaced by tenant-authored executable code. This keeps extension honest: callers control documented inputs and policy choices while the package owns validation and safety.
Capabilities & Limits
- Capability: Executes the scoped workflow described above through the cited live implementation paths.
- Capability: Preserves typed validation and applicable tenant, schema, lifecycle, or service boundaries.
- Limit: Settings are view-scoped, not per-user private overlays. Rendering remains a UI responsibility. View Property Personalization supports the concrete operations described here and composes them with tenant, schema, or lifecycle checks already owned by the package. It does not grant raw database access, make unsupported inputs valid, or assume that optional providers and downstream consumers exist. Callers remain responsible for permissions and meaningful configuration, and product rendering or external delivery stays outside the package unless explicitly stated.
Implementation Map
packages/dotabases/src/services/view-property-settings.tssetViewPropertyConfigpackages/dotabases/src/services/view-display-settings.tssetViewDisplaySettingspackages/dotabases/src/services/dotabase-view-service.tssetViewColumnWidths