What the documents look like
Site selection and store opening work happens before a store trades. The materials that circulate are lease and construction delivery documents: a site evaluation form, a letter of intent for the lease, a decoration budget, and an opening schedule. Each store produces its own set, updated at irregular intervals rather than on a fixed cycle, and each set is a single per-store record.
These materials move between expansion, regional development, and engineering roles during handover. Who may view, who may modify, and who may approve determines where deposit and schedule risk sits. Rent-to-sales ratio calculations, draft lease terms, and budget versions are process documents; they occupy a different state from a final signed text. In FastGPT terms, the site evaluation form, letter of intent, budget, and schedule are files or folders inside a knowledge base, and the permission system treats a file or folder as a collection.
Two documented properties shape this page. First, permission decisions check individual member permissions first, then take the union of department and group permissions, with member permissions taking priority. Second, file-level permission is a separate capability from knowledge-base permission: when it is off, collection readability follows the knowledge base exactly and no collection permission records are queried; when it is on, each file or folder receives a full permission snapshot, and lists, details, and retrieval recall are checked item by item against that snapshot. Knowledge-base permission always remains a threshold that collection permission cannot bypass.
Constraints at the access controls step
The resource permission table gives knowledge bases three levels: usable, editable, and manageable. Files and folders, recorded as collections, have read, write, and administrator roles, plus a unique creator produced by creation or ownership transfer. The creator cannot be granted or modified through collaborator configuration. A submitted collaborator list must contain the current creator, or it is rejected, because collaborator configuration uses full-overwrite semantics: the submitted list is the final result. Deletion of a file or folder is limited to the creator; an administrator or write collaborator cannot delete, and in batch deletion non-creator items are filtered with a notice.
Retrieval recall filters by the files the current member can read, but only when authentication runs as the current member identity. A workflow that preselects a knowledge base without member-identity authentication does not apply file-level filtering and recalls by knowledge-base permission. Turning the file-level switch off deletes all collaborator configuration for every file and folder in that knowledge base and cannot be rolled back.
Hypothetical walkthrough sample. A chain headquarters expansion department maintains a knowledge base, "East China site handover." Inside it, the folder "Suzhou project" contains the file "Site evaluation form - Suzhou A store." The current creator of that file is member A. File-level permission is on for the knowledge base. Member A is the creator of the file, member B is configured as administrator of the file, and member C holds only knowledge-base read permission.
Source text for review: "Site evaluation form - Suzhou A store. Folder: Suzhou project. Creator: member A. File administrator: member B. Knowledge-base permission for member C: read."
Draft sentence to assess: "B may delete 'Site evaluation form - Suzhou A store' and add C as a collaborator on that file."
Under the file-level rules, deletion is limited to the creator, so B's administrator role does not permit deletion. Configuring collaborators requires file administrator rights and an enabled file-level switch, so B may submit a collaborator list, but that list must contain the current creator, member A, or it is rejected. Adding C falls within what B may submit; whether it takes effect depends on list completeness and downstream execution.
Configuration and implementation checks
| Configuration or check item | Use on this page | How to check |
|---|---|---|
| Knowledge-base manageable permission | Entry point for enabling or disabling file-level permission | As a knowledge-base administrator, open the file list permission menu |
| File-level permission switch state | Determines whether collections are checked against snapshots | Inspect the knowledge-base information bar for the enable notice and close entry |
| File creator | Sole subject for deletion and ownership transfer | Open the file permission dialog and read the creator field |
| Collaborator list | Full-overwrite semantics; submission is the final result | Confirm the list contains the current creator before submitting |
| Member and group permission union | Result of combining individual and organizational permissions | Compare member permissions against department and group permissions |
| Retrieval authentication identity | Determines whether recall filters by member | Confirm whether the calling entry authenticates as the current member |
Hypothetical test starting point: the file-level permission switch is set to enabled, because the sample requires per-file collaborator configuration. The comparison object is the behavior under the disabled state, where collections inherit knowledge-base permission. This starting point is a paper exercise setting for this page, not an official default value.
Three common errors
- Treating knowledge-base manageable permission as file deletion permission. Input: member B's file administrator identity and a deletion request. Comparison: the rule that deletion is limited to the creator. Observable result: the request is rejected, or non-creator items are filtered in batch deletion.
- Submitting a collaborator list that omits the current creator. Input: a collaborator list without member A. Comparison: the rule that the list must contain the current creator. Observable result: the submission is rejected.
- Using a retrieval relevance setting in place of file-level authentication. Input: member C's query that reaches beyond granted access. Comparison: recall filtering when authentication runs as member identity. Observable result: the out-of-scope file does not enter recall; a preselected knowledge base without member-identity authentication does not apply this filter.
How to verify the setup
- As member B, issue a deletion request against the sample file. Input: member B's file administrator identity and "Site evaluation form - Suzhou A store." Compare against the rule that deletion is limited to the creator. If the request is rejected, or the file is filtered with a notice during batch deletion, the behavior matches the rule. If deletion succeeds, record the actual observation as inconsistent with the rule.
- As member B, submit a collaborator list that does not contain creator member A. Input: that list and the file administrator identity. Compare against the rule that the list must contain the current creator. If the submission is rejected, the behavior matches. If it succeeds, record it as pending verification and do not infer downstream permission changes.
- As member C, call a knowledge-base search that authenticates as member identity. Input: member C's knowledge-base read permission and a query. Compare whether "Site evaluation form - Suzhou A store" appears in the recall results. If the file does not appear, the filtering behavior matches. If it appears, record the actual observation. When checking a downstream design against a paper input of an empty result, state only that no content was returned for that input; do not claim that a fictional rule necessarily returns empty. Libraries using different vector models cannot be associated together; check the model identifier first, exclude non-matching ones, and do not run cross-model retrieval to compare missed recall. External system authentication and FastGPT resource permissions are verified separately; an interface authentication result does not replace file-level permission decisions.