Conversation
Signed-off-by: hortison <160366376+hortison@users.noreply.github.com>
|
Yay, your first pull request! 👍 A contributor will be by to give feedback soon. In the meantime, you can find updates in the #github-notifications channel in the community Slack. |
Summary of ChangesHello @hortison, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the organization schema to achieve better alignment with the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request updates the organization schema to align with meshery-cloud Go models. The changes include making several fields in Organization, Location, and Theme optional, adding an invite_id to the Organization model, and introducing new payload schemas (LogoPayload, ThemePayload, PreferencesPayload, OrganizationPayload) for creation and update operations. The schema for DashboardPrefs is also updated to include a required layout property.
The changes are well-aligned with the summary provided. I've added a suggestion to improve consistency in the schema definitions by explicitly defining the Go type for object properties with additionalProperties, similar to how it was done for Theme.vars.
| type: object | ||
| additionalProperties: true |
There was a problem hiding this comment.
There was a problem hiding this comment.
Pull request overview
This PR updates the Organization schema to align with meshery-cloud Go models by loosening validation requirements and adding support for invitations and dashboard layout preferences.
Changes:
- Reduced required fields for Organization (only name and metadata remain required), Theme (id and logo no longer required), and Location (all requirements removed, svg property removed)
- Added
invite_idfield to Organization schema to support invitation tracking - Added new payload schemas (LogoPayload, ThemePayload, PreferencesPayload, OrganizationPayload) for API request/response handling
- Modified DashboardPrefs from flexible additionalProperties to structured schema requiring a layout property
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| required: | ||
| - layout | ||
| properties: | ||
| layout: | ||
| type: object | ||
| additionalProperties: true |
There was a problem hiding this comment.
The DashboardPrefs schema now defines a structured type with a required 'layout' property, but it uses x-go-type: "DashboardPrefs" which references the existing Go model defined as type DashboardPrefs map[string]interface{} (see models/v1beta1/organization/organization.go:32). This creates an inconsistency between the schema definition and the Go type it's supposed to map to.
Either remove the x-go-type annotation to let the code generator create a new struct based on the schema, or align the schema definition with the existing Go type by removing the structured properties and keeping it as additionalProperties: true.
| required: | |
| - layout | |
| properties: | |
| layout: | |
| type: object | |
| additionalProperties: true | |
| additionalProperties: true |
| x-go-type: "Location" | ||
| properties: |
There was a problem hiding this comment.
The Location schema removed the 'svg' property but uses x-go-type: "Location" which references the existing Go model that requires both 'svg' and 'location' fields (see models/v1beta1/organization/organization.go:34-38). This creates a mismatch where the schema defines only a 'location' property but the Go type expects both 'svg' and 'location'.
Either add back the 'svg' property to match the existing Go type, or remove the x-go-type annotation to let the code generator create a new struct that matches this schema definition.
| x-go-type: "Location" | |
| properties: | |
| x-go-type: "Location" | |
| required: | |
| - svg | |
| - location | |
| properties: | |
| svg: | |
| type: string |
| required: | ||
| - id | ||
| - name | ||
| - country | ||
| - region | ||
| - description | ||
| - owner | ||
| - metadata |
There was a problem hiding this comment.
The Organization schema now only requires 'name' and 'metadata' fields, removing requirements for 'id', 'country', 'region', 'description', 'owner', 'created_at', and 'updated_at'. However, the existing Go model (models/v1beta1/organization/organization.go:69-85) defines these fields as non-nullable/non-pointer types. When the Go code is regenerated from this schema, there will be a breaking change where these fields become optional (pointers). Ensure this aligns with the intended behavior mentioned in the PR description about matching meshery-cloud Go models, and update all code that depends on these fields being non-nil.
| vars: | ||
| type: object | ||
| additionalProperties: true | ||
| x-go-type: "map[string]interface{}" |
There was a problem hiding this comment.
The vars property uses x-go-type: "map[string]interface{}" which is appropriate for an object with additionalProperties: true. However, this approach should be applied consistently to DashboardPrefs as well, where the existing Go type is also defined as map[string]interface{} (models/v1beta1/organization/organization.go:32).
| $ref: "#/components/schemas/PreferencesPayload" | ||
| invite_id: | ||
| $ref: "#/components/schemas/UUID" | ||
| nullable: true |
There was a problem hiding this comment.
The OrganizationPayload schema includes an 'invite_id' field (line 384-386), but there's no corresponding 'invite_id' field in the existing Organization Go model (models/v1beta1/organization/organization.go:69-85). While this field is being added to the Organization schema (lines 254-258), ensure that when the Go code is regenerated, both the Organization entity and OrganizationPayload will properly include this field with consistent nullable semantics.
| nullable: true |
| properties: | ||
| id: | ||
| type: string |
There was a problem hiding this comment.
The Theme schema removed requirements for 'id' and 'logo' fields. However, the existing Go model (models/v1beta1/organization/organization.go:139-144) defines both fields as non-nullable (non-pointer types). When Go code is regenerated from this schema, these fields will become optional pointers, which is a breaking change. Additionally, the Logo schema still requires all four location properties (desktop_view, mobile_view, dark_desktop_view, dark_mobile_view), so even though logo is now optional on Theme, if provided it must be complete. Verify this matches the intended behavior from the PR description about loosening logo/location requirements.
Summary