What the documents look like
Peak-sale warehouse and delivery scheduling centers on short-term peak capacity and the arrangement of people, vehicles, and yards. The working materials are a peak-sale forecast table, staff shift rosters, courier support plans, and daily exception reports. These materials move between roles during operations handover, so access controls and data isolation require checking each account against the content it can actually see and the operations it can actually perform. Update frequency does not change the permission logic, but the handover moment determines which materials sit in a readable, writable, or pending-review state.
In FastGPT v4.17.2, a knowledge base is the resource type dataset, and a file or folder inside it is a collection. Collection-level permission is a commercial-edition feature. When the switch is off, collection readability follows the knowledge base exactly and the system queries no collection permission records. When the switch is on, every file and folder carries a permission snapshot, and lists, details, and retrieval recall are authorized against that snapshot. The knowledge base permission remains the threshold: a collection grant cannot bypass it. A team administrator does not bypass collection-level permission; team-level management covers only team resources such as member groups and organizations, while knowledge bases and files are still authorized by their own collaborator configuration.
Constraints at the access controls step
Collaborator configuration uses full-overwrite semantics: the submitted list is the final result. The creator cannot be granted or modified through collaborator configuration, and a submitted collaborator list must include the current creator or it is rejected. A single full overwrite can therefore drop the creator record if the list omits it.
The switch is the only entry point that produces collection-level custom permissions. Before it is on, any write that configures a single file permission is refused with a prompt to enable it first. Enabling materializes permission snapshots for all files and folders synchronously within the request; with many files this takes longer. The switch is set only after materialization succeeds, and a mid-way failure leaves it off, so the operation can be repeated. Disabling deletes all collaborator configuration under that knowledge base, restores inheritance everywhere, and cannot be rolled back; the interface requires a second confirmation. Re-enabling after disabling is equivalent to a first enable.
Retrieval recall filters by the files the current member can read, and only when authorization runs under the current member identity. A workflow that preselects a knowledge base without member-identity authorization does not filter at collection level and still recalls by knowledge base permission. A relevance score does not act as a permission or entity filter.
Configuration and implementation checks
The settings below describe a hypothetical paper exercise sample. They are documented settings or implementation checks, not defaults, and no test has been run.
| Configuration item | Setting in the hypothetical exercise sample | How to check |
|---|---|---|
| Knowledge base collection-level permission switch | The target knowledge base is in the enabled state | Check whether the knowledge base information bar shows the enabled notice and the disable entry |
| Collection collaborator role | Member A is granted read permission | Compare the role wording in the file permission dialog against the submitted list |
| Creator record | Member B is the creator of the file | Check whether the submitted collaborator list includes Member B |
| Knowledge base read permission | Member A holds read permission on the knowledge base | View the file list and details with Member A's account |
| Retrieval recall authorization mode | The sample authorizes by current member identity | Check whether the knowledge base search node authorizes by member identity |
| Team administrator identity | Member C is a team administrator | Check with Member C's account whether collection-level permission still follows the collaborator configuration |
Three common errors
- Treating a retrieval relevance setting as a permission filter. Input: a member account and a retrieval query. Comparison: that member's collaborator configuration on the target file. Observable result: whether the member sees the target file in the file list. A relevance score carries no entity or permission filtering function, and a retrieval setting does not replace checking the collaborator configuration.
- Treating a pending permission request as an effective grant. Input: a collaborator change request marked pending review. Comparison: the current actual collaborator list against the list the request proposes to change. Observable result: whether the member's actual role in the current list has changed. A pending request does not show that an operation permission has changed, and an unexecuted request produces no change in actual access.
- Treating team administrator identity as grounds to bypass collection-level permission. Input: a team administrator account and the target file. Comparison: that account's collaborator configuration in collection-level permission. Observable result: whether the account can view or operate on the target file. A team administrator does not bypass collection-level permission, and team-level management covers only team resources.
How to verify the setup
Hypothetical paper exercise sample: a peak-sale warehouse and delivery scheduling knowledge base has collection-level permission enabled. Member A is granted read permission on the peak-sale forecast table, Member B is the creator of that file, and Member C is a team administrator who has not been added as a collaborator on that file. The material text available for checking is: "Peak-sale forecast table - session 12 - 18 June 2026 - East China warehouse - expected peak order volume 8,000 orders - confirmed." One handover request to be assessed is: "Change Member A's permission on this file from read to write; current status is pending review."
- Verification one: input Member A's account. Compare that account's collaborator role on the peak-sale forecast table against the knowledge base read permission. The observable result is that Member A can view the file list and details but cannot modify file information. The condition is met when the role shows read permission and the knowledge base read permission exists.
- Verification two: input Member C's account. Compare whether that account is a collaborator on the peak-sale forecast table. The observable result is whether the permission entry appears in the file row menu for Member C. The condition is met when Member C, not added as a collaborator, does not see the permission entry, and the team administrator identity does not change that result.
- Verification three: input the pending permission change request above. Compare Member A's actual role in the current collaborator list against the role the request proposes to change. The observable result is that Member A's current role remains read permission. The condition is met when the request status is pending review and the actual role is unchanged, since a pending request produces no write permission.
Retrieval check: input Member A's account and a query term. Compare whether the recall result includes the peak-sale forecast table. The observable result is that the file is recalled when Member A can read it and is not recalled when Member A cannot read it. The failure branch is a workflow that preselects the knowledge base without member-identity authorization, where the file is still recalled by knowledge base permission. An empty result can be carried forward by checking downstream design against the explicit paper input []; this does not claim that a fictional rule retrieval necessarily returns []. Knowledge bases across different vector models cannot be associated together; check the identifier first and exclude those that do not match, rather than running cross-model retrieval to compare missed recall.