What this category of data looks like
This category of data is generated across the full user acceptance testing (UAT) workflow. Typical sources include requirement specification documents, test environment operation logs, customer business sample data, and defect tracking system records. Core daily deliverables include UAT test cases, acceptance issue tickets, acceptance reports, and customer signed confirmation documents. Data is updated once per acceptance phase or software version iteration. Different stakeholders (implementation consultants, test managers, customer business representatives) are responsible for data maintenance in different stages. Document fields include test steps, expected results, defect severity, acceptance conclusions, etc. There is no unified fixed unit. Values adjust dynamically based on document type.
What constraints these characteristics impose on the "permissions and data isolation" link
Data sources include customer business samples, which involve sensitive customer business information. Cross-customer data access must be strictly isolated to prevent unauthorized users from accessing customer business details. Document updates iterate with acceptance phases. Permission configurations must be tied to phases to avoid cross-phase data leaks or accidental operations. Different stakeholders are responsible for different stages. Operational permissions must be divided by role. For example, customer business representatives may only view their own assigned acceptance reports. Implementation consultants may only edit UAT test cases for their corresponding projects. Signed confirmation documents are formal compliance records. Only authorized roles may modify or export them to prevent tampering with acceptance conclusions. Additionally, the use of global variables must account for isolation needs across different users. Avoid conflicts from identically named variables disrupting UAT workflows.
How to configure the settings
This document is written for FastGPT v4.17.0, and all following configurations are compatible with this version.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
teamId | Bound to the exclusive ID of the current acceptance project | UAT test cases are updated per acceptance phase. Binding teamId isolates acceptance data across different phases for the same customer |
tmbId | Associated with the exclusive identifier of the implementation consultant or test manager | Different implementation consultants are responsible for UAT projects for different customers. Using tmbId isolates the scope of data each individual is responsible for |
| Role permission granularity | Assign operational permissions by document type | Only test managers and customer business representatives may view acceptance reports; only authorized administrators may modify signed confirmation documents |
| Global variable isolation rules | Bind teamId and user ID | Avoid value conflicts from identically named global variables created by different users, which meets data isolation requirements in UAT workflows |
| Data cache validity period | 3600 seconds | Matches the update frequency of UAT data per phase, prevents cache expiration or excessive resource occupation from long retention |
| Single-team data quota | 500 MB | Matches the average storage size of UAT documents, prevents single-team data overflow from affecting overall platform operation |
| Single document pull limit | 200 items | Matches the bulk viewing needs of UAT test cases, avoids performance issues caused by pulling too much data in a single request |
Three common configuration mistakes
- Issue: Unauthorized users can view cross-customer UAT test cases. Cause: UAT test cases are not bound to the corresponding customer's
teamId, resulting in incorrectly isolated permission scopes. - Issue: Identically named global variables created by different users have their values overwritten. Cause: Global variables are not bound to
teamIdor user ID, violating data isolation requirements in UAT workflows. - Issue: The tokenLogin interface returns data from the old team after switching teams. Cause: Team data is not stored in association with
tmbId, resulting in failed binding of login status to team.
How to verify correct configuration
- Attempt to access a specified customer's UAT test cases using an account not bound to
teamId, confirm the corresponding documents cannot be viewed. - Create identically named global variables using two different user IDs, assign different values to each, then confirm their respective values do not interfere with one another.
- Switch teams and call the tokenLogin interface, confirm the returned team data matches the current logged-in account's
tmbId. - Check that the global variable isolation rule has been configured to bind
teamIdand user ID, confirm the configuration takes effect.
The values provided here are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.