What Pull Request review data looks like
Pull Request review data typically originates from code repositories, CI pipelines, Issue links, and contributor submissions. In FastGPT v4.17.0, the PR data storage table includes identity and ownership identifiers such as teamId and tmbId by default. Daily documents cover PR descriptions, code review comments, CI results, and merge records. Update frequency follows the single PR merge cycle or weekly batch synchronization. Change data and review records linked to a single PR update in real time as the process progresses. After merging is complete, the data is archived to the corresponding team’s storage repository. Clear distinctions exist between the data access scope and operational permissions available to different entities. The core data structure centers on change entries, review comments, and merge status.
What constraints do these characteristics impose on permissions and data isolation?
Pull Request review data characteristics create clear constraints for permissions and data isolation. Data sources are scattered across multiple systems including code repositories and CI pipelines. Isolation rules must cover all data entry points to prevent cross-system data leaks. Update frequencies range from real-time to weekly batch synchronization. Permission checks must align with data update rhythms to prevent unauthorized users from accessing PRs during changes. Data includes ownership identifiers such as teamId and tmbId. Missing or incorrectly associated identifiers will directly cause permission checks to fail, leading to cross-team data leaks. Operational permissions vary across different entities. Permission ranges must be strictly limited to prevent unauthorized personnel from modifying main branch code.
How to configure settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Team permission isolation rules | Divide access scope by teamId, only allow members to access PR data bound to teamId | Match PR data’s team ownership identifiers to ensure cross-team data isolation |
| Contributor identity verification | Associate tmbId to verify submitter and reviewer permissions | Ensure only authorized contributors can submit or review corresponding PRs |
| Historical version field completion | Enforce validation for the presence of the tmbId field, auto-complete missing values or block operations | Fix permission failure issues caused by missing tmbId in older version storage tables |
| Intranet MySQL connection configuration | Set connection timeout threshold to 30 seconds, whitelist only intranet network segments | Resolve database connection refusal issues during intranet deployment |
| Team member addition verification | Complete identity verification by binding accounts to teamId, only allow valid accounts to join | Prevent failed additions caused by invalid usernames |
| Review chat record isolation | Divide chat storage partitions by teamId, only allow members to view review communication data from their own team | Ensure isolation of review communication data across different teams |
Three common misconfiguration scenarios
- Historical PR associated data in older versions lacks the
tmbIdfield, so team permission checks cannot be completed. The cause is that the MongoAppVersion table in older versions did not sync thetmbIdfield, and auto-completion rules were not configured. - Database connection refusal errors occur during intranet deployment, while logs show MySQL is running normally. The cause is that no intranet access whitelist was configured, so external requests are blocked by the database.
- After generating a publicly accessible link, cross-team members can view PR review data that does not belong to their own team. The cause is that data storage partitions were not divided by
teamId, so permission isolation rules did not take effect.
How to confirm proper configuration
- Submit a test PR, verify that non-team members cannot view or review the PR, to confirm the
teamIdpermission rules are active. - Review historical PR data, confirm that every record includes the
tmbIdfield with no missing entries. - Test database connections in the intranet environment, verify that only intranet network segments can access the MySQL instance, with no external connection errors.
- Add a team member, verify account validity, and confirm that accounts bound to
teamIdcan join the corresponding team normally.
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.