What data for this category looks like
Daily documents for this category include level design drafts, resource requirement sheets, test feedback forms, and version submission records. Data mainly comes from level editors, art resource libraries, player test data, and defect tracking systems. Update frequency is mostly weekly or per release cycle. Level design drafts contain path node coordinates, resource reference identifiers, and task trigger logic fields. Resource requirement sheets list art resource IDs and usage quantities. Test feedback forms record player stuck node issues and feedback content. Version submission records include submitter, time, and change details.
What constraints these characteristics impose on permission and data isolation workflows
The multi-source and multi-type nature of this data requires permission isolation to match different data usage scenarios. Level design drafts and version submission records involve core content iteration. Edit permissions must be limited to the corresponding project team. Resource requirement sheets are linked to art resource library call permissions. They must be tied to roles in resource procurement and review processes. Player test data includes user feedback content. Access to sensitive information must be isolated. The high-frequency update feature requires permission configurations to quickly adapt to personnel changes during version iterations. This prevents content leaks or accidental modifications caused by expired permissions.
How to set up configurations
These configurations are based on FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
teamId | Unique team identifier for the corresponding project | Binds the permission scope of all level content within the project, preventing cross-project data confusion |
tmbId | Exclusive identifier for the level template | Isolates configurations and data for different level templates, preventing content misuse |
| Permission role division | Assign by job position: Planning team can edit, review team can view, operations team can manage | Matches the division of labor processes within the category, restricting unnecessary operation permissions |
| Data isolation scope | Divide by project, single project data is not shared across teamId | Avoids content confusion between level design drafts and resource requirement sheets of different projects |
| Sensitive data desensitization | Hide user IDs and device information in player test data, retain feedback content | Meets basic compliance review requirements, protects user privacy |
| Permission change timeliness | Sync takes effect within 10 minutes after change | Adapts to the high-frequency update feature of the category, quickly adapting to personnel changes during version iterations |
Three common misconfigurations
- When adding a custom plugin in a workflow, no input or output parameters are displayed, and no error logs are generated. The cause is that the association identifier bound to the plugin is not correctly configured with
teamId, resulting in unrecognized plugin permissions. - After local deployment, multiple accounts cannot log into the same team, and adding data to the table has no response. The cause is that the association field for team permissions is not correctly configured, resulting in invalid account-team binding relationships.
- When synchronizing application historical versions to the cloud, a field missing error occurs. A table associated with application historical versions lacks the
tmbIdfield. The cause is that the historical version data was not synchronized with thetmbIdidentifier, resulting in failed permission isolation verification.
How to confirm configurations are correct
- Attempt to log in with an account from a non-planning position, verify that editing level design drafts and version submission records is not allowed, confirming that permission role division is effective.
- Switch to an account with a different
teamId, verify that level data from other projects cannot be viewed, confirming that the data isolation scope configuration is correct. - Upload player test data, verify that sensitive information has been desensitized, confirming that the sensitive data desensitization configuration is effective.
- Submit a permission change request, verify that the new account can normally access the corresponding project data within 10 minutes after the change, confirming that the permission change timeliness configuration is effective.
Note: The values provided here are common starting points and should be evaluated 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.