Views Module Technical Specifications

The Views module has two concerns:

1. Saved Views — Filter, sort, column, grouping, and view-type configurations for any collection
2. Dashboard Workspaces — Grid-based widget layouts assembled from any module's widgets

Both are built on Aeion's standard auto-generated CRUD for their underlying data, plus a small set of view-specific API routes layered on top — set-default, and listing views scoped to a particular collection.

Because both saved views and dashboards ride on the platform's standard collection infrastructure rather than a bespoke storage layer, they inherit tenant isolation, access control, indexing, backup/restore, and audit history for free — the same guarantees every other collection in Aeion OS gets.

Saved Views — One Default Per Collection Per User

Whenever you mark a saved view as your default, Aeion automatically unsets your previous default for that same collection as part of the same save — there's no separate cleanup step and no window where two views both claim to be the default.

What this prevents: You have 3 saved views for the "deals" collection. You click "Set as default" on a fourth. Without this enforcement, you could end up with 4 defaults — ambiguous which one loads. With it, the 4th becomes default and the previous 3 are automatically unset.

Race condition handling: If two browser tabs simultaneously set different views as default, the result is still deterministic — whichever write commits last wins, and it's guaranteed to be the only default. No manual locking or conflict resolution required on your end.

Dashboards — One Default Per User

Dashboards work the same way, except the default is scoped per-user across all dashboards rather than per-collection — you have one default home dashboard, not one per data source.

Saved views and dashboards use identical, straightforward access rules:

• Read: your own views, plus anything shared with the team
• Create: any authenticated user
• Update / Delete: the owner, or a tenant admin

Shared views are read-only for non-owners — other users see them but can't edit or delete them. They can, however, duplicate a shared view into their own copy and modify that freely.

Admin override: Admins can update or delete any view in their tenant — used for cleanup when users leave the organization.

All view-specific routes require authentication and supplement the standard auto-generated CRUD with view-specific operations.

GET /views/for-collection/:slug

Lists saved views for a specific collection — the requesting user's own views plus any shared views, sorted by creation date.

Use case: Opening a collection fetches saved views for that collection and populates the Saved Views dropdown with "Your views" and "Shared views."

PATCH /views/:id/set-default

Sets a view as default and automatically unsets any previous default for that collection. The request is rejected with a 404 if the view doesn't exist and a 403 if you don't own it — you can only set your own views as default.

Dashboard CRUD Routes

Same pattern for dashboards:

• GET /views/dashboards/list — user's own + shared
• POST /views/dashboards — create
• PATCH /views/dashboards/:id — update (owner or admin)
• DELETE /views/dashboards/:id — delete (owner or admin)

The Saved Views control appears in the toolbar of every collection in the admin. It handles:

• Applying a view — instantly swaps filter, sort, columns, view type, grouping, and conditional formatting
• Saving current state — captures the working configuration as a new named view
• Rename / Delete / Set Default — available inline for any view you own
• Sharing — toggling "Shared" makes a view visible to the rest of the tenant

States your team will recognize:

• Default view selected: star icon on the default view, loads automatically on open
• Unsaved custom state: an "Unsaved Changes" indicator with an active Save button
• Shared views: shown with a "shared" badge; non-owner views are read-only
• Rename mode: inline edit field replaces the view name
• Empty state: "No saved views yet" with a prominent "Save Current View" action

Every field of a saved view — its filter, sort, columns, view type, grouping, and conditional formatting — is captured on save and restored exactly when the view is applied again, including from other devices and sessions.

Every Saved Views API request accepts and validates the same fields you can set in the UI:

typescript { name: string; // required collectionSlug: string; // required viewType?: "list" | "kanban" | "calendar" | "gallery" | "gantt"; filter?: Record<string, unknown>; sort?: string; columns?: string[]; grouping?: Record<string, unknown>; conditionalFormatting?: Record<string, unknown>; isDefault?: boolean; isShared?: boolean; }

The same shape applies to dashboards, substituting layout for the view-specific fields. Validation happens on every write, so malformed filters or unknown view types are rejected with a clear error rather than silently stored.