What the documents look like
Pinduoduo low-price campaign operations revolve around campaign resource slots, campaign inventory, and refund-rate swings. The working materials named in the brief are campaign registration forms, product cost calculation sheets, after-sales refund slips, and platform site messages. During a handover these materials move between roles at the same time, and each carries a different kind of fact: a registration form carries a registration price and a campaign quantity, a cost sheet carries a cost basis, a refund slip carries an after-sales status, and a site message carries a platform notice. The brief gives daily and per-campaign update frequencies. Handover checking works from the version currently visible to the person checking.
This matters for access control because the materials sit with different roles. When boundaries are unclear, a person taking over can see cost or refund detail outside that person's responsibility. FastGPT separates member permissions from department and group permissions. Member permissions have the highest priority, and department and group permissions are combined as a union. Resource types include team, app, dataset, and collection, where a collection is a file or folder. File-level permission inside a dataset is a commercial-edition feature and is off by default; while it is off, collection readability matches the dataset. Once it is on, list, detail, and retrieval recall are checked item by item against a permission snapshot, and dataset permission remains a threshold that collection permission cannot bypass. Retrieval recall filters by the files the current member can read, and this applies only when authentication runs as the current member identity. A similarity or relevance score does not carry permission or entity isolation duty, and retrieval settings do not replace an authorization decision. A team administrator does not bypass file-level permission. System root and the team owner are treated as holding full permission over all files.
Constraints at the access controls step
The named task is operations permission and handover management, with the feature being permission and data isolation. The constraint is that a handover request, a form entry, or a retrieval result is not an authorization. A pending request is not an approval, an offered option is not execution, and an unsigned termination is not a completed termination. A site message that records a pending review status does not show that a resource slot was approved, and it does not show that the receiving role lacks permission to act. Where a document field is not provided, that field stays unknown.
Assume an exercise sample. Source text one: "This campaign registration form states that product A has a registration price of 9.9 yuan, a campaign quantity of 500 units, a registering entity of the store operations group, and a submission date of 10 March 2025." Source text two: "The product cost calculation sheet states that product A has a per-unit cost of 8.5 yuan, on a basis that includes freight, prepared by the supply chain procurement role, with a version date of 9 March 2025." Source text three: "A platform site message notifies that the campaign resource slot review status for product A is pending review, and it does not state a pass time." Draft sentence to be judged: "Product A has been approved for the campaign resource slot and can accept 500 orders at 9.9 yuan."
The draft sentence turns a pending review status into an approval, and it does not check whether the registration form and the cost sheet agree on entity, period, and field. The registration form names the store operations group; the cost sheet names the supply chain procurement role. The two documents do not share one entity, so a single authorization decision covering both is not supported by these texts. The site message carries no pass time, so approval remains unverified rather than denied.
Configuration and implementation checks
The table below covers the permission and handover checks for this page's sample. Each value is a hypothetical starting point for this exercise, with the reason for choosing it and the comparison object stated.
| Configuration or check item | Hypothetical starting point | Reason and comparison method |
|---|---|---|
| File-level permission switch for the dataset | Off | The documented default is off, so collection permission matches the dataset; compare against the on state to see whether a snapshot and item-by-item checks appear |
| Collaborators on the dataset holding campaign materials | Operations group given edit, procurement group given use | Check read and operation scope item by item against the resource permission table; a role name does not substitute for an access test |
| Collection-level collaborator configuration | Registration form and cost sheet each given read permission | With file-level permission on, checks run against the snapshot; compare against the dataset threshold to see whether dataset read permission is still required |
| Retrieval recall authentication mode | Authenticate as the current member identity | The documents state that file-level filtering takes effect only in this mode; compare against a preselected dataset without member authentication |
| Authorization status record for the handover request | Recorded as pending verification | The site message states no pass time; compare against the fields an approval would require |
| External system authentication | Verified separately from FastGPT resource permission | The documents state that external interface authentication and resource permission are verified separately, not merged into one decision |
Three common errors
- Treating a pending review status in a site message as an approval. Input is source text three; the comparison object is the fields an approval would require; the observable result is that the draft sentence and the source status field do not agree.
- Using retrieval relevance in place of a permission decision. Input is one retrieval query; the comparison object is the set of files the current member can read; the observable result is whether a file outside that set appears in the recall results.
- Merging the cost sheet entity and the registration form entity into one authorization during handover. Input is source text one and source text two; the comparison object is the entity field; the observable result is that two different entities were cleared under one permission decision.
How to verify the setup
- Check the draft sentence against the source texts sentence by sentence. Input is source text three and the draft sentence; compare the pending review status field and the approved status field; the condition is met only when the source states a pass time and the fields agree. At present the status is pending verification.
- Use one account with permission and one account without permission to check the same file. Input is the same campaign registration form; compare the visible content and the operation result for the two accounts; the condition is met only when the account without permission can neither see nor operate on the file.
- Check whether retrieval recall filters by member. Input is a retrieval request authenticated as the current member identity; compare the recalled files against the readable file list; the condition is met only when files outside the readable set do not appear. For empty-result handling, use an explicit paper input of an empty list to check the downstream design, and do not claim that a rule returns an empty result.
Across these checks, a missing field stays missing. The site message does not state a pass time, so approval is not supported. The registration form and the cost sheet do not share one entity, so a single authorization covering both is not supported. A pending review does not show that an operation permission is absent. External interface authentication and FastGPT resource permission are verified separately, and a retrieval setting does not exclude unrelated businesses or unauthorized records.