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]

Failing reproduction test opened in draft PR #34 (/bug-tdd step of the pipeline).

[polmichel]

Fix pushed to #34 (/bug-fix step). Backend now defaults CoreAccountGroup and CoreGeneratorGroup to group_type=internal, completing the backend half of the dropdown filter — reproduction test passes.

[polmichel]

/bug-analyze

[test-bug-pipeline]

✅ Bug analyst agent completed successfully!

[test-bug-pipeline]

Root cause analysis for #33

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

Root cause

CoreAccountGroup and CoreGeneratorGroup inherit the generic group_type attribute, whose default is "default", so they are never classified as internal and therefore slip past the dropdown's group_type__values: ["default"] filter.

Affected files

• backend/infrahub/core/schema/definitions/core/group.py -- lines 34-41: the generic Core/Group (CoreGroup) defines group_type with enum=["default", "internal"] and default_value="default". Every group kind that does not redefine this attribute inherits "default".
• backend/infrahub/core/schema/definitions/core/group.py -- lines 77-90 (core_generator_group / CoreGeneratorGroup): inherits from GENERICGROUP and never overrides group_type, so generator groups (auto-created, not user-assignable) get group_type="default".
• backend/infrahub/core/schema/definitions/core/permission.py -- lines 159-182 (core_account_group / CoreAccountGroup): inherits from GENERICGROUP and never overrides group_type, so permission groups get group_type="default".
• frontend/app/src/entities/groups/ui/add-group-form.tsx -- line 70: the node-detail "manage groups" picker already filters correctly with filterQuery: { group_type__values: ["default"] }. This is the consumer of the classification, not the bug. (The bulk toolbar variant in object-table/.../groups/toolbar-add-to-groups-action.tsx:52 and the read-side card filter in object-profiles-groups-card.tsx:200 apply the same internal exclusion.)

Explanation

The frontend half of this bug was already fixed in commit 04770a938 ("fix(frontend): hide internal groups from add-to-group selectors", opsmill#9394): the add-to-group selectors now request only groups with group_type=default, mirroring the existing read-side filter that excludes group_type=internal.

That filter only works if a group kind that should be hidden actually carries group_type="internal". The filtering is value-based, not kind-based — there is no blocklist of kinds. CoreAccountGroup (permission management) and CoreGeneratorGroup/CoreGeneratorAwareGroup (generator-managed) are system-managed and should never be user-assignable targets, yet they inherit the generic default group_type="default" and are returned by the filter.

Inheritance confirms the override mechanism: in backend/infrahub/core/schema/node_inheritance_handler.py:42, an inherited attribute is skipped when the node already defines a local attribute of the same name (if attribute.name in node.valid_local_names: continue). So redefining group_type locally on a node schema with default_value="internal" correctly overrides the inherited default without touching the generic.

Affected files (summary of where the fix belongs)

The classification gap is in the backend schema definitions, not the frontend. The frontend is already correct.

Fix strategy

Approach: On the CoreAccountGroup (backend/infrahub/core/schema/definitions/core/permission.py) and the generator group node schemas (backend/infrahub/core/schema/definitions/core/group.py), redefine the group_type attribute locally with default_value="internal" (same kind="Text", same enum=["default", "internal"], optional=False). Because a locally-defined attribute shadows the inherited one (NodeInheritanceHandler), this changes only these kinds' default. New nodes created by create_accounts_group and by generator runs will then be internal automatically (neither call site passes group_type explicitly, so they take the schema default).

Scope: Small. Add a local group_type attribute definition (a few lines) to each affected node schema. Apply to core_account_group, core_generator_group, and — for consistency, since it is the branch-aware sibling — core_generator_aware_group. A schema/data migration is also required for the value backfill (see Notes).

Do NOT:

• Do NOT change the generic CoreGroup default to "internal" — that would flip CoreStandardGroup (the user-assignable kind) and every user-defined group to internal, hiding exactly the groups that should appear.
• Do NOT add a kind-based blocklist in the frontend or in the GraphQL filter — the design is value-based on group_type. Adding a parallel kind list duplicates the source of truth and rots.
• Do NOT rely on changing the schema default_value alone to fix already-initialized instances — default_value only applies at node creation; existing rows keep their stored "default" value. A migration is needed (see Notes).
• Do NOT hardcode group_type="internal" only at the create_accounts_group / generator call sites instead of in the schema — that leaves the attribute default inconsistent and misses nodes created through other paths (GraphQL, SDK).

Notes for downstream steps

• Migration is the non-obvious part. Changing a schema attribute's default_value does not rewrite existing data. Instances already initialized (and the demo data referenced in the repro) will still have CoreAccountGroup/CoreGeneratorGroup rows with group_type="default", so the dropdown stays polluted on upgrade until those values are backfilled. A data migration under backend/infrahub/core/migrations/ must set group_type="internal" on existing nodes of these kinds. The test-writer should cover both a freshly created node (schema default) and the migration/backfill of a pre-existing node.
• group_type is optional=False with an enum of exactly ["default", "internal"]; the override must keep these constraints so existing validation and the group_type__values filter continue to work.
• Consider the other auto-managed group kinds (CoreGraphQLQueryGroup, CoreRepositoryGroup) — they are also system-created and arguably should be internal, but the issue only reports CoreAccountGroup and CoreGeneratorGroup. Flagging for the fixer to decide; keeping the reported scope avoids scope creep, but the reasoning ("system-managed, not user-assignable") applies to them too.
• Test angle: assert on the resolved group_type value of the node schemas / created nodes, not on the frontend dropdown alone — the frontend filter is already covered by existing tests (add-group-form.test.tsx, toolbar-add-to-groups-action.test.tsx). The new coverage belongs on the backend classification.

AGENT_ANALYSIS_COMPLETE

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