What the documents look like
Community group-buy leader operations manage community nodes and commission, and they do not perform cold-chain quality inspection directly. The documents that matter for this page are the leader agreement, the commission table, the pickup list and the community announcement. Order details, after-sales records, pickup lists and community announcements update daily and per group, and fulfillment errors lead directly to wrong or missing deliveries and neighborhood complaints. The sharing and embedding step hands the pickup-check and after-sales question entry to a leader or a neighborhood user, so identity and record boundaries become the first concern.
A no-login window is created from the application detail under publish channels. The system generates a complete link, and the link identifier only controls access. It does not serve as an authorization credential for the leader agreement or for commission settlement. An anonymous user is identified by a localId, and records depend on the same device and the same browser; switching devices loses them. The system allows pulling only the most recent 30 days and 20 records. Identity verification uses a POST root address, and initialization, conversation start and conversation end call /shareAuth/init, /shareAuth/start and /shareAuth/finish respectively. The request passes only when success is true, and the response must return a uid that contains none of the characters |, /, \ and does not exceed 255 bytes. Expiration time, QPM, points cap and identity verification are partly configurable only in the commercial edition.
Hypothetical paper exercise sample: a leader agreement states, "Party A authorizes Party B to carry out group-buy pickup service in Sunshine Lane community, authorization period 1 March 2025 to 31 August 2025; Party B commission is settled according to the pickup list of the current month." A draft community announcement intended for embedding states, "This community pickup service is valid long term, and commission is settled in the current month." The pending request is to share this announcement with neighborhood users through a no-login link and to append authToken=leader001 to the link.
Constraints at the shared access step
The link identifier and the authToken are access parameters. They do not establish that the leader holds a valid authorization for the stated period, and they do not establish that commission settlement has occurred. The leader agreement is the material that carries the authorization subject and the authorization period, and the announcement draft is a separate document that must be compared against it on the same field.
The 30-day and 20-record limits apply to what an anonymous user can pull. A record that falls outside that window is not evidence that the record never existed, and a record visible on one device is not evidence that it will appear on another. The identity verification endpoints return a success flag and a uid. A success response means the conversation may continue; it does not mean that settlement, after-sales handling or any downstream business action has been completed.
The points cap limits the billing data produced by the link, and the cost is attributed to the team that owns the application. Expiration time limits how long the link remains usable. These settings are partly restricted by edition, so a setting that appears in one deployment may not be configurable in another.
Configuration and implementation checks
| Configuration item | Use on this page | Check method |
|---|---|---|
| No-login window link | Carries the community announcement and question entry | Create from publish channels and copy the full link; treat the link identifier as access, not authorization |
| Expiration time | Limits the usable range of the shared entry | Compare with the agreement authorization period 2025-03-01 to 2025-08-31, and verify against the actual edition |
| QPM | Maximum visits per user per minute | Set a hypothetical starting value for this exercise and compare with observed visits; not an official default |
| Points cap | Limits billing data from the shared entry | Verify against the team that owns the cost; partly restricted by edition |
| Identity verification root address | Connects leader identity verification | Enter the root address only; check success and uid from /shareAuth/init and /shareAuth/start |
| Conversation record boundary | Describes the anonymous record range | Same device and same browser; pull only the most recent 30 days and 20 records |
Three common errors
- Treating the link identifier or authToken as a leader authorization credential. The input is the shared link with authToken=leader001, the comparison is against the authorization subject and period in the leader agreement, and the observable result is that an openable link does not mean authorization is established.
- Treating the draft phrase "valid long term" as an agreement fact. The input is the announcement draft and the agreement text, the comparison is the validity period field in both, and the observable result is that the two values differ and the draft must be revised.
- Treating a success response from the identity verification endpoint as completed commission or after-sales handling. The input is the response body from /shareAuth/start, the comparison is the uid format and the 255-byte limit, and the observable result is that passing verification only means the conversation may continue; settlement and after-sales still require downstream implementation.
How to verify the setup
- Input the hypothetical sample agreement text and the announcement draft, compare the authorization period field, and confirm the draft is revised to match 2025-03-01 to 2025-08-31 before the condition is met.
- Input the link with authToken=leader001 appended and the response body from /shareAuth/init, compare success and uid against the character and byte limits, and confirm the request passes only when the response is true and the uid is compliant.
- Input a conversation record pull request, compare the device and the time range, and confirm records are visible only on the same device and same browser and only within the most recent 30 days and 20 records. A missing record on another device is expected, and identity and session management still require separate design.