Skip to main content

Crate laterite_admin

Crate laterite_admin 

Source
Expand description

Laterite admin: the operator-facing web surface.

An Axum router mounted under a configurable path (default /admin, set by AdminConfig::path): 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.

An application usually boots through Bootstrap, which loads config, connects, migrates, and serves this router in one call.

Re-exports§

pub use bootstrap::AppConfig;
pub use bootstrap::Bootstrap;
pub use bootstrap::BootstrapCtx;
pub use bootstrap::DEFAULT_ENV_PREFIX;
pub use axum;

Modules§

bootstrap
Application bootstrap: one call to load config, connect, migrate, build the admin router, and serve it.
checklist
The checklist: checkboxes in groups, one component for every screen.
descriptor
Reading a resource from a YAML file.
field
The open field-type registry: the framework and plugins add form field types.
form
Descriptor-driven create and edit forms.
html
Trusted HTML markup.
http_cache
Conditional responses and cache policy for admin and plugin routes.
import
Bulk import: a file’s rows written through a resource’s form, with a report.
list
Descriptor-driven list views.
medialib
The media library: a Media tab to browse, upload, arrange and remove the files the application keeps, and the route that serves them.
nav
The admin’s menu: a registry of items that modules, resources and screens contribute as data, resolved once at boot into a tree and filtered per request by what the operator may see.
persist
The persister seam: a form’s write is a handler, resolved at boot from a string key on the descriptor.
picker
The reference-picker seam: a generic field picks a value from a data source (another table, a hierarchy) without the framework knowing the source.
plugins
The laterite.plugins built-in module: a registry table recording each plugin’s operator enable/disable state, read at boot to decide which plugins load. record_roster records the compiled plugins here at boot, set_enabled is the enable/disable service (applied on the next boot), and list_plugins feeds the admin screen. The quarantined_* columns hold the system’s verdict (written by a later slice).
relation
Related records on a form: a resource declares which other entity’s rows belong to each of its records, and the edit page carries a section for them.
routes
Routes a module mounts itself: admin screens, and public endpoints.
settings
Descriptor-driven settings screens, and the settings store behind them.
ui
Typed admin chrome for a screen that composes a page by hand: the same buttons, toolbars and badges the framework’s own screens render, built as values and rendered through the shell, so a module never writes the class names itself.

Macros§

resource
Reads a descriptor file at compile time, relative to the crate’s manifest.

Structs§

AdminConfig
Deployment-level admin settings passed to router. Per-install brand and per-operator preferences are settings/preferences, not deployment config.
Contributions
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. Everything the modules and the application contribute to the admin, in one value.
ImportConfig
What a resource declares when records may be imported into it: import: true in a descriptor file, or a map with the keys below.
PageHead
What a contributed page shows above its body: the title, a way back when the page sits under another, and the controls that act on the page as a whole (export, a menu of operations), which render beside the title.
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.
ResourceHook
A change to another module’s resource, applied at boot before the resource mounts: the hook receives the resource as declared and returns it changed, so a module adds a column, a field, a relation or a menu placement to a screen it does not own. The target is the resource’s path as it mounts (/posts; a plugin’s under its module base, /acme/blog/posts). A target nobody declared aborts boot. Hooks run in module order.
SessionHandle
A cheap-to-clone handle to the current session’s typed state, shared between the auth middleware and the handler through request extensions. Mutations set a dirty flag; the middleware persists the blob after the handler runs only when it is dirty.
Shell
The chrome shared by every authenticated page: the top-nav links and the signed-in operator. Built once by the auth guard and injected into request extensions, so page handlers render inside the same shell without each rebuilding it. Templates embed it as shell and base.html renders it.
VerifiedUpload
An upload whose request token has been verified.

Enums§

AdminError
A typed error an admin handler can return.
FlashLevel
The severity of a [Flash], mapped to a style class by the template.

Constants§

ROLE_ADMIN
The built-in role every administrative permission belongs to. Held by the first operator, and by anyone who should administer the panel itself.
ROLE_EDITOR
The built-in role for working with content rather than the panel. Empty on a bare framework: a permission joins it by naming it.

Traits§

AdminRegistry
Typed contribution channels for the framework’s admin surfaces, as an extension trait over the generic laterite_core::Registry. A module contributes its admin screens, permissions, and settings from its register; a wrong-type contribution is a compile error, not one silently ignored. The generic add/items underneath remains for open, plugin-defined points.

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.
builtin_modules
The framework’s built-in modules, in registration order. Bootstrap registers these before an app’s own modules, so the admin’s tables migrate first.
descriptor_sources
Every source string in the framework’s built-in admin descriptors: resource nav labels and their list titles and column headers, settings items and their fields, and permission labels and groups. lat i18n extract folds these into the admin catalog. Collected through the serde source walk, so it never drifts as new label fields are added.
normalize_path
Normalises a configured admin path: a single leading slash, no trailing slash, falling back to /admin when empty. manage, /manage, and /manage/ all become /manage. Shared by router and any caller building the panel’s URL (for example a startup banner), so the two never drift.
permission_renames
Every rename the registry declares, as (old, new) pairs.
router
system_roles
The framework’s roles, with the permissions the registry says they hold.