- name
- nocobase-app-plugin-authorization
- description
- Design and implement NocoBase 3 business permissions: job responsibilities, pages, business actions, fields, record scopes, relations, team inheritance, permission assignments, administration and inspection. Use when building a system or feature whose users have different access.
- metadata
- short-description: Design and develop business authorization domain-owner: '@nocobase/app-plugin-authorization'
Authorization development
Use the application's existing authorization service. Resolve authorizationToken from @nocobase/app-plugin-authorization/server in a provider or route factory. Read the application's AGENTS.md and inspect registered plugins and server/config/authorization.ts first. Application-owned features stay in the application's providers/routes/services; create a reusable plugin only when requested.
Identify model and configuration changes
Inspect existing declarations, enforcement, permission sets and installed capability Skills. Classify each requested change by its content, whether the feature is new or already exists. A request can require both model development and configuration.
For permission development, deliver both the implemented model and usable initial configuration based on the responsibility matrix: permission sets, pages/actions, selected scopes, applicable rules and intended user/team assignments. Do not stop at registration and leave configuration to the user unless they explicitly requested model-only work. If recipient identities or access decisions are missing, ask for those specifics while completing independent work; do not guess assignments. Keep configuration editable in the backend and preserve unrelated administrator choices.
Choose delivery by installation state: use seeds for fresh-install defaults and authorized runtime services or a controlled data-change workflow for an existing installation. These are ways to apply configuration, not alternatives to model development. Reuse current management pages and editors. When the App owns a role editor, build it from the UI Library's permission-editor component (; its example is ), selecting the actual application capabilities that administrators need to configure and composing its sections and rows in application-owned code. Registry provides no fixed business catalog. Preserve actual action names, descriptions and independent data scopes; do not copy a full options response or demo catalog into the form. Do not generate a default System and tools category or expose unused optional rule editors. The controlled checkboxes edit a draft saved by the host form. Read the relevant references as needed, beginning with the business workflow for model changes and the service/configuration references for configuration changes.