Skip to content

fix(frontend): don't request profiles field for generic kinds in edit form - #10023

Draft
claude[bot] wants to merge 1 commit into
stablefrom
fix/edit-form-profiles-generic-kind
Draft

fix(frontend): don't request profiles field for generic kinds in edit form#10023
claude[bot] wants to merge 1 commit into
stablefrom
fix/edit-form-profiles-generic-kind

Conversation

@claude

@claude claude Bot commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

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 error Cannot query field 'profiles' on type 'CoreGenericRepository'.

After: the edit form loads normally on generic routes; the query no longer requests profiles for generic kinds.

What changed

The edit-form GraphQL query builder (frontend/app/src/entities/nodes/object-item-edit/generateObjectEditFormQuery.ts) decided whether to request the profiles field based solely on the generate_profile schema flag. Generic kinds inherit generate_profile: true, but the backend never adds a profiles relationship to restricted-namespace ("Core") generics, so the resulting GraphQL type has no profiles field — and the query blew up.

The fix adds an isGenericSchema guard so profiles is only selected for non-generic schemas. This mirrors the predicate the form component already relies on (isNode && generate_profile), where generics fall through to GenericObjectForm, 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: true still includes profiles in the built query, while a generic schema (used_by, generate_profile: true) does not.

How to test

cd frontend/app
pnpm test src/entities/nodes/object-item-edit/generateObjectEditFormQuery.test.ts

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

  • Backward compatibility: no schema or API changes; only the client-side query for generic kinds changes.
  • Deployment notes: safe to deploy.

Checklist

  • Tests added/updated
  • Changelog entry added
  • External docs updated (not user-facing docs)
  • Internal .md docs updated (not applicable)
  • I have reviewed AI generated content

… 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.
@github-actions github-actions Bot added the group/frontend Issue related to the frontend (React) label Jul 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

group/frontend Issue related to the frontend (React)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant