Restriction rules

Capabilities

@nocobase/app-plugin-authz-restriction-rules provides this extension. Restriction rules narrow an existing record range for named subjects. Their selections describe records still allowed, rather than records to hide. Every matching restriction applies.

The application owns rule management. Authorization factories are required in addition to runtime registration.

Scenarios and examples

Example

For interns who may read orders but must handle only non-confidential ones, select non-confidential orders in a read restriction. Sharing a confidential order cannot bypass that restriction.

Confirm the operation grant first, configure the range, then verify permitted records, excluded records and direct API calls. Business queries must apply authorization policies for rules to affect actual access.

Development prompt (for a Coding Agent working in the application directory):

Use @nocobase/app-plugin-authz-restriction-rules. Restrict interns with order-read access to non-confidential orders, verifying that sharing cannot bypass the restriction.
Preserve authorization extensions and integrate rule management with its settings
permissions. Check the read action before configuring records. Do not add admin
grants to bypass restrictions. Verify allowed and excluded records through direct APIs.

Done whenInterns see only non-confidential orders, even when a confidential order is shared.

Key principles and implementation

These are the integration areas and expected interface changes for this example. They describe development work; use the actual file layout of your application.

Integration

Register its Client and Server entries alongside Permission management, apply migrations, and add the factory to server/config/authorization.ts:

import { restrictionRules } from '@nocobase/app-plugin-authz-restriction-rules/server';

// Merge into the existing authorization configuration, retaining other extensions.
plugins: [restrictionRules()]

Runtime registration contributes locales and migrations. The configuration factory installs rule behavior and HTTP endpoints; installing the package alone does not enable them.

Configure and use rules

Selections support all records, explicit IDs or registered recordAccess. Multiple restrictions intersect, so selecting all records in one rule does not cancel another. Removing a restriction can widen access and requires verification.

/api/authorization/restrictionRules provides listing, creation, updates, deletion and supporting selection endpoints. The application owns its management page. Operations require the corresponding read, create, update or delete action on settings:authorization.restriction-rules.

Save rules through protected endpoints. Trusted server code can use the authorization service's restrictionRules API; custom HTTP wrappers must retain authorization and input validation.

AI development constraints and verification

Plugin-specific development constraints

• Selections mean records still allowed; matching restrictions intersect. Removing a rule can widen access and needs rechecking.
• Rules change records, not page, operation or field grants. Verify server queries apply their policies.
• Use non-unrestricted identities to check combined rules, removal and direct access, not only a root account.

Boundaries

Rules grant no page, operation or field permission and do not automatically expose related records. Restrictions still narrow the combined default and shared ranges. Unrestricted identities bypass these rules, so test with ordinary users too.

Related: Permission management, Default data access, Sharing rules, Restriction rules.

These are acceptance requirements for your integration, not claims of completed live verification. Ask the Agent to report actual changes, executed checks and unverified items. See Continue developing your app and Testing for project guidance, Skills and shared checks.

Source: public plugin entries and implementation.