Introductionâ
lina-vben is LinaPro's built-in admin workspace, built on Vue 3 + Vben5 + Ant Design Vue + TypeScript. It is not the definer of business logic â it is the standard UI expression layer for the lina-core API and all enabled plugin APIs.
Developers can build business applications directly on top of it, or replace it with a custom frontend. As long as the new frontend follows the core framework's public RESTful API and permission model, it can plug into the same backend capabilities.
Technology Stackâ
| Technology | Description |
|---|---|
Vue 3 | Frontend framework |
Vben5 | Enterprise-grade admin workspace foundation |
Ant Design Vue | Admin UI component library |
TypeScript | Type safety and frontend engineering quality |
Vite | Frontend build tool |
Pinia | Frontend state management |
TailwindCSS | Utility-first CSS toolkit |
Design Boundariesâ
The workspace consumes contracts, not defines themâ
The workspace reads menus, permissions, users, roles, configuration, tasks, plugin status, and API documentation from the core framework. Interface behavior is defined by backend API contracts â the workspace only organizes the interaction experience.
Menus come from core framework governance dataâ
The sidebar is not a pure frontend hardcode. When the core framework returns the menu tree, it merges built-in menus with menus declared by enabled plugins, and filters based on the current user's permissions. When a plugin is disabled, its menu and route entries disappear automatically.
Plugin pages load through a dynamic page shellâ
Both source plugins and dynamic plugins can declare frontend pages. The workspace loads plugin pages through the system/plugin/dynamic-page shell, reducing the need for plugins to modify workspace code.
Functional Modulesâ
The workspace provides visual entry points for core framework and plugin capabilities. Different modules have different backend owners, but users get a unified experience in the interface.
| Module | Key Capabilities | Source |
|---|---|---|
| Access control | Users, roles, menus, button permissions, permission assignment | Core framework |
| System settings | Dictionaries, parameters, file management, runtime configuration | Core framework |
| Job scheduling | Tasks, groups, execution logs, manual triggers | Core framework |
| Multi-tenant management | Tenants, membership, tenant switching, tenant plugin governance | multi-tenant plugin |
| Organization management | Departments, positions | org-center plugin |
| Content management | Notices and announcements | content-notice plugin |
| System monitoring | Online users, service monitoring, operation logs, login logs | monitor-* plugins |
| Extension center | Plugin discovery, installation, enablement, disablement, upgrade, uninstallation | Core framework and plugin system |
| Developer center | API documentation, system information | Core framework |
Access Control Experienceâ
Access control revolves around the RBAC model:
User management, role management, and menu management handle accounts, authorization sets, and permission tree maintenance respectively. After a role selects menu or button permissions, the permission topology takes effect quickly. In cluster mode, the core framework notifies other nodes to refresh through a cache revision mechanism.
Dynamic Plugin Menu Injectionâ
The plugin menu injection flow:
This design lets plugin enablement, disablement, and permission changes be driven by core framework governance data, without the workspace needing to change code for each plugin.
Extension Centerâ
The Extension Center is the primary interface for plugin runtime governance. It displays plugin type, version, status, runtime upgrade status, dependencies, and available operations.
Common operations:
| Operation | Description |
|---|---|
| Install | Runs dependency checks, installation SQL, and writes governance records |
| Enable | Registers menus, routes, hooks, scheduled tasks, and activates business entry points |
| Disable | Hides menus and routes; retains plugin data |
| Uninstall | Cleans up governance records; optionally cleans plugin-owned data based on user choice |
| Upgrade | Executes explicit runtime upgrade for pending_upgrade or upgrade_failed plugins |
| Upload dynamic plugin | Uploads a .wasm artifact, entering the dynamic plugin discovery and governance flow |
Developer Centerâ
The Developer Center aggregates core framework and plugin API documentation. Developers can view OpenAPI documents, request parameters, response structures, and permission identifiers, and issue debug requests directly. Online debugging uses the current logged-in user's authentication state â write operations produce real data changes and should be used cautiously in test environments.
Default Accountâ
Local demo environments typically use the following default credentials:
| Field | Value |
|---|---|
| Username | admin |
| Password | admin123 |
| Default frontend URL | http://localhost:5666 |
Production environments should change the default password immediately after initialization and configure roles and permissions according to organizational security policies.
Extension Recommendationsâ
To extend business functionality on the built-in workspace, prefer declaring menus, pages, and APIs through plugins rather than directly modifying workspace internal modules. Only modify lina-vben itself when you need to adjust the global layout, theme, login page, or common interaction patterns.