bug: when adding a node to a group using the front-end node detail page the dropdown contains irrelevant groups

[polmichel]

Copied from opsmill#4872 for end-to-end testing of the bug-fixing skill pipeline.

Component

API Server / GraphQL

Infrahub version

1.0.1

Current Behavior

When you want to add a node to a group using the front-end node detail page, in the dropdown in which you can select the group we seem to be listing CoreAccountGroup nodes and CoreGeneratorGroup nodes (and maybe others).

Should we add group_type internal to CoreAccountGroup and CoreGeneratorGroup so that they get filtered out from the available candidates?

Expected Behavior

CoreAccountGroup and CoreGeneratorGroup nodes should not be listed in the dropdown as available groups for users to add nodes to.

Steps to Reproduce

• set up an instance of infrahub
• import the demo schema / data and demo-edge repository
• create a new tag
• navigate to the node detail page of the new tag
• click the manage groups button
• the list of available dropdowns will contain CoreAccountGroups and CoreGeneratorGroups

Additional Information

No response

[polmichel]

/bug-analyze

[test-bug-pipeline]

✅ Bug analyst agent completed successfully!

[test-bug-pipeline]

Root cause analysis for #35

Issue: bug: when adding a node to a group using the front-end node detail page the dropdown contains irrelevant groups
Based on: 41c26ae42 (origin/stable)
Bug clarity: CLEAR
Code identification: RESOLVED

Root cause

The frontend group selectors already filter candidates to group_type == "default", but the backend schema never marks the system group kinds CoreAccountGroup and CoreGeneratorGroup (and siblings) as group_type="internal", so their instances inherit the generic default "default", pass the filter, and remain selectable.

Affected files

• backend/infrahub/core/schema/definitions/core/permission.py -- line 159 (core_account_group): AccountGroup inherits GENERICGROUP but does not override group_type, so every instance defaults to "default".
• backend/infrahub/core/schema/definitions/core/group.py -- line 77 (core_generator_group), line 92 (core_generator_aware_group), line 135 (core_repository_group): same gap — no group_type override, all default to "default".
• backend/infrahub/core/schema/definitions/core/group.py -- lines 34-41: the group_type attribute on the CoreGroup generic defines enum=["default","internal"] with default_value="default" — the mechanism exists, it's just not applied to system groups.
• backend/infrahub/groups/tasks.py -- line 32: reference for the correct pattern — CoreGraphQLQueryGroup instances are created with group_type="internal" here, which is exactly what the system group kinds are missing.
• frontend/app/src/entities/groups/ui/add-group-form.tsx -- line 70 (context, already correct): filterQuery: { group_type__values: ["default"] }.
• frontend/app/src/.../object-table/toolbar/actions/groups/toolbar-add-to-groups-action.tsx (context, already correct): bulk "Add to groups" toolbar also filters on group_type (added in the same commit).

Explanation

The "Manage Groups" dropdown is rendered by AddGroupForm (add-group-form.tsx). Since commit 04770a938 ("fix(frontend): hide internal groups from add-to-group selectors", opsmill#9394, already in stable), it fetches candidate groups with filterQuery: { group_type__values: ["default"] }, and the bulk toolbar action does the same. The backend GraphQL member_of_groups relationship exposes a group_type__values: [String] filter (schema/schema.graphql:458), so the filter is honored server-side.

That filter only hides a group if the group's group_type attribute value is "internal". The group_type attribute is defined once on the CoreGroup generic with default_value="default". Concrete group kinds that should be system-managed do not override that default:

• CoreAccountGroup (permission.py:159) — created during account/permission setup with no group_type argument → stored as "default".
• CoreGeneratorGroup / CoreGeneratorAwareGroup (group.py:77, group.py:92) — created by the generator framework with no group_type argument → stored as "default".

By contrast, CoreGraphQLQueryGroup instances are explicitly created with group_type="internal" in groups/tasks.py:32, which is why query groups are correctly hidden while account and generator groups are not. The result: account and generator groups have group_type="default", satisfy the ["default"] filter, and still appear in the selector — exactly the reported behavior.

The previous frontend fix established the filtering mechanism but left the data side incomplete: the groups that are supposed to be filtered out are never tagged internal.

Fix strategy

Approach: Mark the non-user-assignable system group kinds as internal at the schema level so their instances default to group_type="internal", which the already-present frontend/GraphQL filter then excludes. In each relevant NodeSchema definition, add an attributes=[Attr(name="group_type", kind="Text", enum=["default","internal"], default_value="internal", optional=False)] override (reusing the existing attribute definition from the CoreGroup generic — do not invent a new attribute). Apply to: core_account_group (permission.py), core_generator_group, core_generator_aware_group, and core_repository_group (group.py). Leave core_standard_group (group.py:62) as "default" — that is the user-assignable group. core_graphql_query_group already gets "internal" at creation, but overriding its schema default too makes it robust against other creation paths.

Alternative (narrower, less robust): set group_type="internal" at each instance-creation call site, mirroring groups/tasks.py:32. This is more fragile because it depends on every creation path remembering to pass it; prefer the schema-default override.

Scope: Small, backend-only. Two files (permission.py, group.py), one attribute override added per affected NodeSchema (≈4-5 small edits). No frontend changes — the frontend is already correct.

Do NOT:

• Do NOT modify or re-implement the frontend filter / AddGroupForm / the bulk toolbar — they already filter on group_type correctly. The defect is that the data is not tagged, not that the UI fails to filter.
• Do NOT hardcode a kind-name denylist (e.g. excluding "CoreAccountGroup"/"CoreGeneratorGroup" by __typename) anywhere; the group_type attribute is the intended, extensible mechanism.
• Do NOT add a new attribute, flag, or abstraction — reuse the existing group_type attribute and just change its default for these kinds.
• Do NOT mark CoreStandardGroup internal; it is the user-facing assignable group and must keep group_type="default".

Notes for downstream steps

• This is a schema change (the group_type default for system group kinds). Per repo guidelines, schema/migration changes are in the "Ask First" category — the fixer should flag it and may need to regenerate offline artifacts (uv run invoke backend.generate) and add/update an internal_schema migration. Changing a schema default_value only affects newly created instances; existing group instances in an already-populated database keep their stored "default" value, so a data migration may be required for upgrade scenarios. For the issue's reproduction (fresh demo-schema/data import) the new default is sufficient.
• A frontend test (frontend/app/src/entities/groups/ui/add-group-form.test.tsx) and a changelog fragment (changelog/4872.fixed.md) already describe the intended "hide internal groups" behavior; both landed with the earlier frontend-only commit 04770a938. The test mocks the API and asserts the group_type__values filter is passed — it does not verify that account/generator groups are actually tagged internal. The test-writer should add backend coverage asserting that CoreAccountGroup/CoreGeneratorGroup (and CoreGeneratorAwareGroup) instances default to group_type="internal", and ideally an integration/e2e check that such groups are absent from the candidate list returned with the ["default"] filter.
• Edge case: confirm group_type permits per-kind override (its AllowOverrideType is not NONE, so overriding default_value on inheriting nodes is allowed).
• Consider whether CoreRepositoryGroup and CoreGraphQLQueryGroup should also be covered for consistency (repository groups created via SDK tracking are not tagged internal today); the issue says "and maybe others", so treating the whole system-group family uniformly is the cleaner fix.

AGENT_ANALYSIS_COMPLETE

Generated by Bug analyst agent for issue #35 · opus48 1.5M · ◷
_{Comment /bug-analyze to run again}

[polmichel]

/bug-tdd

[test-bug-pipeline]

✅ Bug test-writer agent completed successfully!

[test-bug-pipeline]

A failing replication test was written and a draft PR opened targeting stable.

Test: backend/tests/unit/core/schema/test_group_schema_defaults.py::test_system_group_kinds_default_to_internal

It loads the core schema, processes inheritance, and asserts that the system-managed group kinds (CoreAccountGroup, CoreGeneratorGroup, CoreGeneratorAwareGroup, CoreRepositoryGroup) default to group_type="internal". On current code all four resolve to "default", so they pass the selectors' group_type__values: ["default"] filter and remain selectable — reproducing the reported bug. A guard assertion confirms CoreStandardGroup (the user-assignable group) stays "default".

Next: reviewer agent verifies the test, then /bug-fix.

Generated by Bug test-writer agent for issue #35 · opus48 2M · ◷
_{Comment /bug-tdd to run again}

[test-bug-pipeline]

🛠️ Fix implemented for #35 — pushed to PR #36.

Root cause: the system-managed group kinds inherited the CoreGroup generic default group_type="default" and never overrode it, so their instances passed the selectors' group_type__values: ["default"] filter and stayed selectable.

Fix: added a local group_type attribute override (default_value="internal") on CoreAccountGroup, CoreGeneratorGroup, CoreGeneratorAwareGroup, CoreRepositoryGroup, and CoreGraphQLQueryGroup (the reviewer-flagged sibling, included for uniform coverage). CoreStandardGroup stays "default". No front-end changes — the selectors and GraphQL filter were already correct.

Validation: the test-writer's replication test passes (5 passed, unmodified); backend.lint (ruff/ty/mypy) and the schema unit suite pass; protocols.py regenerated.

⚠️ Note for reviewers: this is a schema default_value change and only affects newly created instances — a data migration may be needed to retag pre-existing system groups in upgraded databases.

PR: #36

Generated by Bug fixer agent for issue #36 · opus48 3.7M · ◷
_{Comment /bug-fix to run again}