Admin Modules and Pluggable Types📋

Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.

An administration module describes how authorized users inspect and operate a domain. It must use the domain's application contracts and enforce their rules rather than treating every database table as unrestricted CRUD.

Module contributions📋

A module description must identify its application type or service, available views, editable fields, operations and required capabilities. Contributions may supply list layouts, editors, filters, panels or complete modules.

A field type can bring both a frontend representation and an admin editor. Composite types can reuse editors from dependencies. The module host resolves those contributions through explicit contracts and reports missing editors before exposing a broken form.

Contributed UI implementations remain independent from the domain model. A new editor should not require moving EF persistence types into a client-side shared kernel.

Generated baseline📋

For Acme Catalogue, the configured Product module must provide a list, detail and edit views, category selection, validation feedback and supported filtering/paging. The Media extension supplies the media picker. Enquiry operations are declared business actions.

Generated modules must expose accessible labels, validation associations and keyboard behavior through the chosen editor family. Supported locale and publication controls must identify which record version is being edited.

The baseline is generated from model and admin descriptors. Complex business rules are supplied by the application or its extensions.

Application operations📋

An operation description identifies its inputs, availability conditions and expected result. The server-side application contract remains authoritative even if the UI has already validated input.

Permission checks must cover the actual operation and target record, including batch actions. UI visibility is presentation feedback; it does not replace enforcement at the application boundary.

A stale edit must return a conflict that lets the user preserve or reconcile their work. A failed action must not appear successful because the client component rendered without error.

Model designer and content editor📋

The model designer edits definitions in a workspace and invokes validation/generation. The content editor changes records under their storage and publication policy.

Both can appear in the administration experience, but their scopes and activation paths must be explicit. “Add field” is a model operation. “Change Product description” is a content operation.

Changing a type through an installed modeling extension may introduce migrations and generator changes. The admin must display that impact rather than immediately altering a production schema as a side effect of opening an editor.

Code policy and UI configuration📋

Code-defined policy states which admin settings are configurable. Saved instance configuration may select permitted list columns or editor implementations. Fixed constraints remain enforced.

The UI must show an effective configuration value and its origin. CLI and automated clients must obtain the same permitted operation set and validation behavior.

Lab service configuration can use these admin contracts. A GitLab service type, for example, can contribute its own form while its Bundle and wrappers retain operational responsibility.

Acceptance📋

ADMIN-01: generated Product administration uses the Category relationship and contributed Media editor.

ADMIN-02: a custom enquiry action invokes application behavior with permission, validation and conflict handling.

ADMIN-03: changing a model is visibly distinct from editing its records; generated updates preserve custom modules.

ADMIN-04: UI and automation resolve the same configuration and cannot override a fixed policy constraint.

Previous: Front: Pages, Areas, Zones and Widgets · Next: Lab: Branches, Builds and Deployments · Series index · Section index