Crate laterite_admin 

Laterite admin: the operator-facing web surface.

An Axum router mounted at /admin: a login screen and session cookie verified against laterite-auth, and descriptor-driven screens.

Screens are resources: a module declares a Resource (a list::ListConfig, optionally a form::FormConfig, a base path, and a menu label), and the framework mounts the list, create, and edit routes and adds it to the menu. This is the extension point that lets an application contribute its own admin screens. The framework’s own screens (users, roles) are just built-in resources.

Modules

form

Descriptor-driven create and edit forms.

list

Descriptor-driven list views.

settings

Descriptor-driven settings screens, and the settings store behind them.

Structs

AdminConfig

Deployment-level admin settings passed to router. Per-install brand and per-operator preferences are settings/preferences, not deployment config.

Permission

A permission an operator can be granted: a dotted code, a human label, and a group heading it sorts under in the role editor. The framework registers its own (see the built-in grants), and an application registers its permissions through router so they appear in the editor alongside.

Resource

An admin resource: a list screen, optionally with a create/edit form, mounted under base_path and shown in the menu as nav_label.

Functions

builtin_migrations

The migration sets for every module the admin mounts: the auth schema (users, roles, sessions, access log) and the settings store. Run these before serving router so its built-in screens have their tables, so an application never has to know which framework modules the admin pulls in.

router

Builds the admin router. app_resources are the application’s own list/form screens; app_settings are its settings models; app_permissions are the permissions it defines, offered in the role editor alongside the framework’s. All are mounted alongside the framework’s built-in equivalents.