61 lines
3.2 KiB
Markdown
61 lines
3.2 KiB
Markdown
|
# sdk-collection-permissions Specification
|
||
|
|
|
||
|
|
## Purpose
|
||
|
|
定义面向 `ManagePlatform` 用户的 SDK 直连权限配置能力，使角色绑定与 collection CRUD 授权能够通过 hooks 页面完成并映射到 PocketBase rules。
|
||
|
|
## Requirements
|
||
|
|
### Requirement: Role-based SDK direct access SHALL be configurable from hooks pages
|
||
|
|
|
||
|
|
The system SHALL provide a hooks-mounted management page that allows `ManagePlatform` users to assign roles to auth users and configure PocketBase SDK direct-access CRUD permissions by role and collection.
|
||
|
|
|
||
|
|
#### Scenario: Role is assigned to an auth user
|
||
|
|
|
||
|
|
- **WHEN** a management user selects a role for an auth user and saves the assignment
|
||
|
|
- **THEN** the system SHALL persist the role mapping used by the SDK direct-access permission model
|
||
|
|
|
||
|
|
#### Scenario: Collection operation is granted by role
|
||
|
|
|
||
|
|
- **WHEN** a management user authorizes a role for a collection operation such as list, view, create, update, or delete
|
||
|
|
- **THEN** the corresponding PocketBase collection access rule SHALL be updated for that role
|
||
|
|
|
||
|
|
### Requirement: Role identity SHALL be name-based in the management UI
|
||
|
|
|
||
|
|
The hooks permission page SHALL hide internal role IDs from the UI and present role assignments and selectors by role name only.
|
||
|
|
|
||
|
|
#### Scenario: Current role display hides role ID
|
||
|
|
|
||
|
|
- **WHEN** a management user views the role assignment page
|
||
|
|
- **THEN** current role labels and selectors SHALL show the role name without exposing the internal role ID
|
||
|
|
|
||
|
|
### Requirement: Permission editing SHALL be immediate and constrained by rule type
|
||
|
|
|
||
|
|
The permission page SHALL save authorization changes immediately after a checkbox toggle, SHALL render CRUD labels in Chinese, and SHALL prevent editing for operations already governed by public or custom rules.
|
||
|
|
|
||
|
|
#### Scenario: Authorization change auto-saves
|
||
|
|
|
||
|
|
- **WHEN** a management user toggles an editable permission checkbox
|
||
|
|
- **THEN** the change SHALL be persisted immediately without requiring a separate save button
|
||
|
|
|
||
|
|
#### Scenario: Public operation is read-only
|
||
|
|
|
||
|
|
- **WHEN** a collection operation is already publicly accessible
|
||
|
|
- **THEN** the page SHALL show a brief `可公开访问` notice and SHALL NOT render an editable authorization checkbox for that operation
|
||
|
|
|
||
|
|
#### Scenario: Custom operation is read-only
|
||
|
|
|
||
|
|
- **WHEN** a collection operation is governed by a custom rule
|
||
|
|
- **THEN** the page SHALL show `当前操作使用 custom 规则，禁止修改` and SHALL NOT render an editable authorization checkbox for that operation
|
||
|
|
|
||
|
|
### Requirement: Collection-level bulk selection SHALL respect editable operations only
|
||
|
|
|
||
|
|
The permission page SHALL provide a collection-level select-all control that applies only to editable operations, and the control SHALL be disabled when the collection has no editable operations.
|
||
|
|
|
||
|
|
#### Scenario: Collection select-all grants editable operations
|
||
|
|
|
||
|
|
- **WHEN** a management user enables the collection-level select-all control
|
||
|
|
- **THEN** all editable CRUD operations for the current role on that collection SHALL be granted and auto-saved
|
||
|
|
|
||
|
|
#### Scenario: Collection select-all is disabled when nothing is editable
|
||
|
|
|
||
|
|
- **WHEN** every operation in a collection is either public, custom, or otherwise not editable
|
||
|
|
- **THEN** the collection-level select-all control SHALL be disabled
|