This documentation applies to FastGPT v4.17.0.
What this category of data looks like
Typically, data related to version releases and Release Notes includes version tags, change logs, release checklists, associated Git tags and merge records, CI artifact hashes, and issue milestone information. Data sources include code repository tags, merged commit records, CI-generated artifact files, and milestone nodes bound to project issues. The update rhythm aligns with version release cycles. One update is completed per new version released. Single documents typically include fields such as version number, change type classification, breaking change notes, and artifact checksum values. There are no fixed standard unit requirements. Version numbers and Git tags serve as core associated fields.
Constraints on Permission and Data Isolation
Release and Release Notes data is strongly bound to specific teams and specific versions. Permission and data isolation must center on team access scope and version context. First, release data from different open-source maintenance teams must be strictly isolated. This prevents cross-team leakage of version information. Second, work orders and chat records of different members within the same team must be linked to the release context of the corresponding version. This prevents mixing of unrelated data. Additionally, data sources involve code repository permissions. Isolation configurations must align with repository team permissions. Only members with repository access can view release work orders and chat content for the corresponding version. Finally, publicly accessible release documentation links must be bound to team permissions. This prevents unauthorized users from accessing unreleased version change information.
How to Configure Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
teamId | Associate with the team ID of the corresponding open-source maintenance team | Bind team access permissions, only team members can access release data associated with that team |
tmbId | Bind the template ID of the current version release project | Isolate release contexts for different versions to avoid cross-contamination of work order data across versions |
| Chat record storage path | For local deployments, store in /data/fastgpt/chat/team_{teamId} directory; for public deployments, store in an isolated dedicated storage bucket | Isolate chat data by team to prevent cross-team data leaks |
| Public access link permissions | Only allow members bound to the corresponding teamId to access, do not grant unrestricted access | Prevent unauthorized users from viewing internal work orders and chat records related to version releases |
| Team collaboration permission toggle | Enable team member collaboration configuration | Restrict only team members to participate in work order Q&A and collaboration related to version releases |
Three Common Misconfigurations
- Phenomenon: After generating a publicly accessible link, unauthorized users can view chat records related to version releases. Cause: The
teamIdparameter is not configured, access permissions for the corresponding team are not bound, and the link is not associated with team permission control logic. - Phenomenon: An error is prompted during test model configuration, but the model runs after being referenced, and change information for different versions is mixed in the version release work order. Cause: The
tmbIdparameter is not correctly configured, release contexts for different versions are not isolated, and data is cross-contaminated. - Phenomenon: Team members cannot be invited to participate in version release work order collaboration after local deployment. Cause: Team permission isolation configuration is not enabled, the corresponding
teamIdis not bound, and the team collaboration permission toggle is not turned on.
How to Confirm Proper Configuration
- Attempt to access the chat link related to version releases using an account that is not a team member, confirm that the content cannot be viewed.
- Switch configurations for different
teamIdvalues, confirm that members of the corresponding team can only access release data associated with thatteamId. - Check the chat record storage directory, confirm that chat data for different teams is stored in separate subdirectories, with no cross-team data mixing.
- Test model calls for version release work orders, confirm that only change logs and artifact information associated with the current version are loaded, with no data from other versions mixed in.
The values provided are common starting points and should be measured against applicable deployment 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.