fix(frontend): don't request profiles field for generic kinds in edit form - #10023
Draft
claude[bot] wants to merge 1 commit into
Draft
fix(frontend): don't request profiles field for generic kinds in edit form#10023claude[bot] wants to merge 1 commit into
claude[bot] wants to merge 1 commit into
Conversation
… form
The edit-form GraphQL query builder requested the `profiles` field based
only on the `generate_profile` schema flag. Generic kinds (e.g.
CoreGenericRepository, CoreWebhook) inherit `generate_profile: true`, but
the backend never adds a `profiles` relationship to restricted-namespace
("Core") generics, so the corresponding GraphQL type has no `profiles`
field. Opening Edit on a generic route therefore failed with
`Cannot query field 'profiles' on type 'CoreGenericRepository'`.
Guard the `profiles` selection with `isGenericSchema` so generics never
request it, mirroring the predicate the form component already uses to
route generics to the generic form (which has no profiles UI). Add a
regression test covering both the node and generic cases.
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Requested by Matěj Lanča · Slack thread
Why
Before: opening Edit on a repository (or any object) reached through its generic kind URL — for example from the homepage "Git repositories" widget, which links to
/objects/CoreGenericRepository/<id>— fails with "Something went wrong when fetching the object details." and the GraphQL errorCannot query field 'profiles' on type 'CoreGenericRepository'.After: the edit form loads normally on generic routes; the query no longer requests
profilesfor generic kinds.What changed
The edit-form GraphQL query builder (
frontend/app/src/entities/nodes/object-item-edit/generateObjectEditFormQuery.ts) decided whether to request theprofilesfield based solely on thegenerate_profileschema flag. Generic kinds inheritgenerate_profile: true, but the backend never adds aprofilesrelationship to restricted-namespace ("Core") generics, so the resulting GraphQL type has noprofilesfield — and the query blew up.The fix adds an
isGenericSchemaguard soprofilesis only selected for non-generic schemas. This mirrors the predicate the form component already relies on (isNode && generate_profile), where generics fall through toGenericObjectForm, which has no profiles UI. This is the same class of bug as Jira IFC-2938.A focused regression test asserts that a node schema with
generate_profile: truestill includesprofilesin the built query, while a generic schema (used_by,generate_profile: true) does not.How to test
Both cases pass: node includes
profiles, generic omits it. Manually, opening Edit from a generic route (e.g. the homepage Git repositories widget) now loads the form instead of erroring.Impact & rollout
Checklist