What the documents look like
Large-format fresh-food concession counters are frequently run on site by a supplier, with revenue shared according to sales. The documents that circulate in this arrangement include the concession contract, the daily sales report, the shrinkage (loss) sheet, and the food purchase inspection record. These materials carry different visibility scopes and different operation scopes. The store fresh-food department, the supplier's on-site staff, and the store manager each need a defined view of which reports they can read and which documents they can submit. This is a permissions and data-isolation problem rather than a reporting problem.
The daily sales report and the shrinkage sheet are updated daily or per batch. During a shift handover, documents left pending by the previous shift must be distinguished from records already submitted. A handover request is a request, not an executed grant. A pending review does not demonstrate that a permission has taken effect.
Constraints at the access controls step
FastGPT permissions combine member permissions, department permissions, and group permissions. Resources include the team, applications, knowledge bases, and files/folders (collections). File-level permission for a knowledge base is off by default; in the off state, collection readability matches the knowledge base. When it is on, each file receives a permission snapshot, and list, detail, and retrieval recall are authorized item by item against that snapshot. Knowledge-base permission is always the threshold; collection permission cannot bypass it. Retrieval recall filters by the files the current member can read, and this applies only when authorization uses the current member identity. A team administrator does not bypass file-level permission.
Hypothetical paper exercise sample: a large-format store fresh-food department signs a concession contract with a supplier, with revenue sharing based on the daily sales report. The daily sales report for 10 March 2025 shows counter sales of 8,600 yuan, and the shrinkage sheet records 120 yuan of shrinkage for that day. An on-site staff member submits a handover request reading: "Grant write permission on the 10 March shrinkage sheet to the newly arrived on-site staff member, and modify the daily sales report at the same time." The source text available for comparison reads: the concession contract provides that on-site staff may only view this counter's daily sales report and shrinkage sheet, and that modification rights belong to the store fresh-food department; the food purchase inspection record is kept by the store fresh-food department. In the request to be judged, "grant write permission" does not match the viewing scope agreed in the contract, and "modify the daily sales report at the same time" does not state an authorizing subject.
Configuration and implementation checks
The following items concern this page's sample and list only settings the official documentation describes, or implementation checks.
| Configuration item | Official basis | How this sample is checked |
|---|---|---|
| Knowledge-base file-level permission switch | Off by default; when on, authorization is per file | Confirm whether the knowledge base holding the daily sales report is on; while off, a single-file authorization write is rejected |
| Collection collaborator roles | Read, write, administrator, creator | Compare the on-site staff member's current role against the viewing scope agreed in the concession contract |
| Full-overwrite semantics for collaborators | The submitted list is the final result and must include the creator | Check whether the collaborator list in the handover request includes the creator; a missing creator causes rejection |
| Inherited state and independent state | Inherited follows the parent; independent is not overwritten | Determine whether the folder holding the shrinkage sheet is inherited or independent, to judge whether a grant would be overwritten by a parent change |
| Retrieval recall authorization condition | Filtering applies only when authorizing by current member identity | Check whether the retrieval entry after handover authorizes by member identity; an entry without member-identity authorization performs no file-level filtering |
Hypothetical starting point for this exercise: set the on-site staff member's role to read permission. The reason for this choice is that the concession contract provides for viewing only. This starting point is a paper assumption, compared against the knowledge-base administrator role, to observe whether a write operation is rejected. This is a hypothetical starting point, not an official default value.
Three common errors
- Treating a retrieval relevance setting as a permission filter. A relevance score does not distinguish entities or authorization scope, and a retrieval setting cannot replace collection collaborator configuration. In the sample, the on-site staff member being able to retrieve the shrinkage sheet does not indicate write permission.
- Treating a handover request as an executed grant. A collaborator change request awaiting review does not demonstrate that permission has taken effect; signing, reaching cooperation, and contract effectiveness are three distinct facts. In the sample, the "grant write permission" request is in a to-be-judged state and cannot be treated as the on-site staff member having obtained write permission.
- Treating a team administrator as bypassing file-level permission. A team administrator does not bypass file-level permission; the knowledge base and files are still authorized by their own collaborator configuration. In the sample, if the store manager is only a team administrator, a write operation on the shrinkage sheet still requires collaborator authorization for that file.
How to verify the setup
- Input the source text of the sample materials and the handover request; compare the viewing scope agreed in the concession contract with the write grant in the request. Observable result: when the requested write grant does not match the contract's viewing scope, record it as authorization scope pending verification, and do not judge it as granted.
- Input the on-site staff member's account and the shrinkage sheet file; compare that member's role in the collection collaborator list with the write-operation requirement. Observable result: when the role is read permission, the modify-file-information operation is rejected; when the role is write permission, the operation can be submitted, and the submission result is recorded according to the actual return.
- Input the collaborator list in the handover request; compare whether the list includes the current creator. Observable result: when the creator is missing, the submission is rejected; when the creator is included, the submission enters the processing flow, and the processing result is recorded according to the actual state, without presupposing success.
Empty-result continuation: use a paper input of an empty list to check downstream design, describing the visibility scope when there are no collaborators, without claiming that retrieval necessarily returns empty. Different models cannot be jointly associated; first check identifiers and exclude those that do not match, and record the actual observation.