What the documents look like
Retail checkout and loyalty operations draw daily and per-shift material from the POS system, the member CRM, payment platforms and the price tag system. Four document types dominate handover work: promotional price tags, member points rules, the checkout daily report and exception refund forms. These materials carry both price execution detail and member benefit detail, so a store checkout supervisor, a CRM operator and a finance auditor do not see the same scope of the same record.
Two features of this material shape the access-control task. First, the same record can be relevant to three roles whose legitimate interests differ, which makes the authorization source for each role worth checking rather than assuming. Second, the material refreshes daily or per shift, so a handover note has to state the period and shift it covers. Without that scope, the next shift cannot tell what state a pending request was left in.
FastGPT organizes permissions through members, departments and groups. Member permissions carry the highest priority; department and group permissions form a union and rank below member permissions. Resource types include team, app, dataset and collection, where a collection is a file or folder inside a dataset. Knowledge base file-level permission is off by default; while it is off, collection readability follows the knowledge base and the system queries no collection permission records. Once enabled, each file or folder receives a permission snapshot, and list, detail and retrieval recall are authorized entry by entry against that snapshot. Knowledge base permission remains a threshold that collection permission cannot bypass. A team administrator does not bypass file-level permission, while a team owner and system root are treated as holding full permission on all files. Retrieval recall filters by the files the current member can read, and this applies only when authorization runs under the current member identity. A relevance score does not perform permission filtering, so a similarity setting cannot substitute for an authorization check.
Constraints at the access controls step
Handover in this category is a sequence of state changes, not a single act. A submitted request, a reviewed request and an executed request are three different states. Configuration of collection collaborators uses full-overwrite semantics: the submitted list becomes the final result. The creator of a file or folder cannot be granted or modified through collaborator configuration, and a submitted collaborator list must contain the current creator or the submission is rejected. Deletion of a file or folder is limited to the creator; a collaborator with administrator or write permission cannot delete it. Ownership transfer is available only to the creator and moves ownership of subfolders as well.
Two boundaries follow. Enabling file-level permission is the only entry point that produces collection-level custom permission; while the switch is off, any write operation configuring a single file permission is rejected with a prompt to enable first. Closing the switch deletes all collaborator configuration under that knowledge base and restores inheritance, and this operation cannot be reversed. A team administrator permission covers team-level resources such as member groups and organizations, while datasets and files remain authorized by their own collaborator configuration.
Configuration and implementation checks
The table below lists documented settings or implementation checks tied to this page's feature and primary task.
| Configuration item | Documented content | Check method on this page |
|---|---|---|
| Member permission and group permission | Member permission has the highest priority; department and group permissions form a union | Check the actual authorization source of both handover parties on the target dataset |
| Knowledge base file-level permission switch | Off by default; enabling generates permission snapshots | Confirm whether the target dataset has enabled it; while off, configuring a single file permission is rejected |
| Collection collaborator roles | Read, write, administrator, creator | Check whether the submitted collaborator list contains the current creator |
| Collaborator configuration semantics | Full overwrite; the submitted list is the final result | Check whether the list submitted with the handover request is complete |
| File deletion permission | Creator only; administrator or write collaborators cannot delete | Check the identity of the person initiating the deletion in the handover request |
| Retrieval recall authorization condition | Applies when authorization runs under the current member identity | Check whether the retrieval test runs under a member identity |
Hypothetical drill sample: on 10 March 2026, before the end of a shift, a store CRM operator A submits a handover request to checkout supervisor B. The request reads: "Please transfer collaborator permission for the 10 March 2026 exception refund form, form number REF-20260310-07, to B, and delete the original collaborator record." The material supplied for checking reads: "The current creator of this exception refund form is A. The collaborator list contains A and finance auditor C, with roles of creator and read permission respectively. File-level permission has not been enabled for this knowledge base." The request to be judged is the handover request above. The phrase "delete the original collaborator record" touches the creator record. Under the documented rule, the creator cannot be granted or modified through collaborator configuration and the submitted list must contain the current creator. On a knowledge base where file-level permission has not been enabled, the request cannot be executed, and the deletion portion does not conform to collaborator configuration rules.
Three common errors
- Treating a retrieval relevance setting as permission filtering. Input is a similarity configuration from one retrieval test; the comparison is the recall result for the same member with file-level permission enabled and disabled; the observable result is that unauthorized files can still be recalled while the switch is off, which shows relevance does not carry authorization duty.
- Treating a pending handover request as approved and executed. Input is the request A submitted in the sample above; the comparison is whether that request carries a completed review record; the observable result is that while the request sits in submitted state, neither the deletion nor the transfer action has been executed.
- Treating team administrator identity as a bypass for file-level permission. Input is an access test by a team administrator account against the target file; the comparison is the visible scope of the team administrator against that of the team owner; the observable result is that the team administrator is still authorized by file collaborator configuration and does not receive full file permission.
How to verify the setup
- Input the sentence "File-level permission has not been enabled for this knowledge base" from the sample above together with an operation configuring a single file permission. The comparison is the documented statement that while the switch is off, the write operation is rejected with a prompt to enable first. If the operation is rejected and the enable prompt appears, the behaviour matches the document; if the operation succeeds, it does not match.
- Input the sentence from the sample above stating that the collaborator list contains creator A, together with a hypothetical submission whose list omits A. The comparison is the documented requirement that the submitted list must contain the current creator. If the submission is rejected, the behaviour matches the document; if the submission succeeds and the creator record is removed, it does not match.
- Input a dataset search test run under a member identity and the same query run under a non-member identity. The comparison is the documented condition that filtering applies only when authorization runs under the current member identity. If unauthorized files are not recalled under the member identity and no file-level filtering occurs under the non-member identity, the behaviour matches the document; if recall results are identical under both identities, record the actual observation and keep the matter open for verification.