What the documents look like
Overseas stock replenishment management for third-party warehouses involves replenishment plans, inbound appointment forms, inventory ageing tables and final-mile delivery notes. A third-party warehouse can serve several sales channels, so the seller allocates stock across channels rather than relying on a single platform's fulfilment programme. The material comes from the overseas warehouse WMS, ERP sales forecasts, freight forwarder systems and carrier bills.
For contract and transaction material comparison, one replenishment batch may appear across a purchase contract, an inbound appointment form and a final-mile delivery note, each carrying different fields. Team roles, resource permissions and file-level permissions together determine which materials a given operations staff member can see. The update frequency of the underlying data does not drive the permission design on this page.
FastGPT's permission system combines member permissions with department and group permissions, taking the union of the latter two. Applications and knowledge bases carry "usable", "editable" and "manageable" permissions; files and folders (collections) carry read, write and admin permissions. File-level permission is off by default; while off, collection readability matches the knowledge base and the system queries no collection permission records. Once on, each file or folder receives a permission snapshot, and retrieval recall filters by the files the current member can read. Knowledge base permission remains the threshold; collection permission cannot bypass it. Retrieval relevance does not perform permission filtering, and a similarity setting does not exclude unrelated business records or unauthorized records. A team administrator does not bypass file-level permission, while system root and the team owner are treated as holding full permission over all files.
Constraints at the access controls step
The comparison task sits on top of these permission layers. A document that exists in the knowledge base is not automatically visible to the person comparing it, and visibility in a list does not imply permission to modify, move or delete it. The knowledge base read permission is a prerequisite: a collection-level grant alone does not make a file accessible to someone without knowledge base read permission.
Retrieval recall follows the same boundary. When file-level permission is on, knowledge base retrieval filters by the files the current member can read, covering the knowledge base search node in workflows and agents and the knowledge base search test. This filtering applies only when authentication runs as the current member identity. A workflow that preselects a knowledge base without member-identity authentication does not perform file-level filtering and still recalls by knowledge base permission.
A hypothetical paper exercise sample follows. An operations staff member, referred to here as Person A, submits a replenishment plan comparison request on 10 March 2025 concerning overseas warehouse A. The materials are inbound appointment form WH-A-0310 and final-mile delivery note LM-0310-07. The source text reads: "Inbound appointment form WH-A-0310 states an appointed inbound quantity of 1,200 units and an appointment date of 12 March 2025. Final-mile delivery note LM-0310-07 states a delivery quantity of 1,200 units and a delivery date of 12 March 2025." The proposed sentence is: "The two documents agree on quantity and date, confirming this replenishment batch has been received into the warehouse as planned." The question to decide is whether the proposed sentence is supported by the materials.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this page | Reason and comparison method |
|---|---|---|
| Knowledge base file-level permission switch | On | Needed to isolate materials from different overseas warehouses by file; compared with the off state, where collection permission does not take effect |
| Collection collaborator role | Person A holds read permission | Only viewing materials is required; compared with write permission, which allows content changes |
| Knowledge base read permission | Person A holds it | Collection permission cannot bypass the knowledge base threshold; compared with an account without knowledge base read permission |
| Retrieval authentication identity | As the current member identity | File-level filtering does not run without member-identity authentication; compared with a preselected-knowledge-base scenario |
| Team role | Person A is an ordinary member | A team administrator does not bypass file-level permission; compared with system root |
| Comparison scope | Only WH-A-0310 and LM-0310-07 | Limits the comparison to the same subject, same period and same fields; compared with cross-warehouse documents |
The file-level permission switch is the only entry point that produces collection-level custom permissions. While it is off, any write operation configuring an individual file's permission is rejected with a prompt to enable it first. Enabling requires knowledge base admin permission, and materialization of all file and folder permission snapshots completes synchronously within the request; the switch is set only after materialization succeeds. Disabling deletes all collaborator configurations under that knowledge base and is not reversible. Collaborator configuration uses full-overwrite semantics, and the submitted list must include the current creator.
Three common errors
- Treating a retrieval relevance score as permission filtering. Input: Person A searches the knowledge base for "inbound appointment". Compare: the similarity threshold in search settings against Person A's read permission on the target file. Observable result: Person A sees only files for which read permission is held, and the similarity score does not change the visible range. Assuming a lower similarity threshold reveals unauthorized files is an error.
- Treating a pending request as approved. Input: the replenishment plan comparison request Person A submitted carries the status "pending review". Compare: the request status field against the "approved" status. Observable result: a pending status does not demonstrate a lack of operating permission and does not equal approval. A proposed sentence reading "confirmed ready for inbound" exceeds what the materials support.
- Treating a quotation validity period as a supply term. Input: a purchase quotation in the materials states "quotation valid until 31 March 2025". Compare: the quotation validity field against the supply term field. Observable result: quotation validity does not indicate a supply term. A proposed sentence reading "supply term until 31 March" conflates two fields.
How to verify the setup
- Input: Person A's identity and file WH-A-0310 from the hypothetical sample. Compare: Person A's knowledge base read permission against the collection read permission. Observable result: Person A can see the file content, and the list filters item by item by readability. If Person A lacks knowledge base read permission, the file remains invisible even with a collection grant.
- Input: the proposed sentence "The two documents agree on quantity and date, confirming this replenishment batch has been received into the warehouse as planned." Compare: the phrase "has been received into the warehouse as planned" against the source text, which states only appointed and delivered quantities and dates. Observable result: the materials do not state actual inbound completion status, so the proposed sentence is unsupported and should be recorded as pending verification.
- Input: Person A's collection permission on LM-0310-07 as read permission in the hypothetical sample. Compare: read permission against the deletion requirement of creator only. Observable result: Person A cannot delete the file, and non-creator items are filtered out with a prompt during batch deletion. If Person A is the creator, deletion is possible.