This document is written based on FastGPT v4.17.0.
What This Category of Data Looks Like
Data for this category primarily comes from code repositories, test framework reports, requirement specifications and interface definitions. The update frequency is daily or per code commit. Daily generated documents include test cases, coverage reports, Mock instructions and defect tickets. Test cases contain case ID, execution status and expected result fields. Coverage reports contain code line coverage and branch coverage values. Defect tickets contain defect severity, reproduction steps and repair status fields. Most data is structured text and code snippets, with no complex multimedia content. Data is updated frequently alongside development iterations.
How These Characteristics Impact Permission and Data Isolation
Data sources are scattered and updated frequently. Permission isolation must support access control for multi-source data to prevent cross-team test data leaks. Documents such as test cases and defect tickets include business logic details and defect information. Access to these documents must be restricted to only members of the corresponding project team. Code repositories and test framework reports are linked to code commit records. Permissions must be bound to committers and project permissions to prevent unauthorized modification of test data. Test data structures differ across projects. Isolation configurations must support dividing data storage and access scope by project to avoid cross-project data confusion. Frequently updated data also requires permission checks to adapt to real-time access scenarios, preventing data leaks caused by delayed permission configurations.
How to Configure Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
teamId | Bind to the team ID of the corresponding test project, use the unique team identifier created in FastGPT | Ensure test cases, coverage reports and other data are only accessible to members of the owning team, enabling basic permission isolation |
tmbId | Associate with the template ID of the corresponding test component, use the unique code of the component in the platform | Isolate configurations and execution logs of different test components to avoid data confusion between components |
| Test data storage directory | Divide by project, use the path /fastgpt/test-data/{project_name} | Isolate and store test data for different projects to prevent cross-project data leaks |
| Permission check trigger timing | Trigger every time test data is accessed, enable real-time permission checks | Adapt to the update frequency of test data (daily or per commit) to promptly block unauthorized access requests |
| Test data modification permission | Only allow project maintainers to perform operations, configure the project maintainer role | Prevent unauthorized personnel from modifying test cases or defect tickets, ensuring the accuracy of test data |
Three Common Misconfigurations
- The symptom is a permission error when accessing the test data storage directory after restarting the FastGPT container, with a prompt that the file or directory cannot be opened. The cause is that the permissions of the container mount directory are not bound to the FastGPT running user, and the container user permission configuration becomes invalid after restart.
- The symptom is that after adding a custom test plugin, the input and output parameters do not appear in the workflow, and no error information is displayed in the logs. The cause is that the correct
teamIdis not configured for the plugin, resulting in insufficient plugin permissions to load parameter configurations. - The symptom is cross-project test case data confusion, with test results from different projects appearing in the same list. The cause is that the
teamIdisolation rule is not configured by project, resulting in test data from different projects not being correctly divided.
How to Verify the Configuration is Correct
- Log in to the FastGPT platform, enter the test data management page of the corresponding test project, and check that only team members can view the project's test cases and reports.
- Try to access the project's test data directory using a non-team member account, and confirm that viewing or access is not allowed.
- Submit a code modification to trigger a test task, and check that the test result is only associated with the current project's
teamId. - Modify a test case, and confirm that only the project maintainer role can perform the modification operation.
The values provided are common starting points, and should be evaluated against your own specific 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.