Skip to content

Change: allow editing a scan config in use, and do not deselect every NVT when the families are not loaded - #5544

Open
TheBeast85 wants to merge 2 commits into
greenbone:mainfrom
TheBeast85:change/edit-scan-config-in-use
Open

Change: allow editing a scan config in use, and do not deselect every NVT when the families are not loaded#5544
TheBeast85 wants to merge 2 commits into
greenbone:mainfrom
TheBeast85:change/edit-scan-config-in-use

Conversation

@TheBeast85

Copy link
Copy Markdown

What

  • Fix: build trend/select only once the config and the family list have arrived, and leave the family part out of the request while the selection is unknown
  • Change: show the full edit dialog for a scan config a task refers to, and for a policy an audit refers to, instead of the "only name and comment" notice

Why

The edit dialog fetches the config and the list of NVT families in parallel and builds trend/select once, as soon as the config has arrived. When the config arrives first, families is still undefined, createTrendAndSelect returns empty objects, and the guard keeps them that way. Saving then sends only the bare trend parameter, gsad turns that into a family_selection element without a single family, and gvmd reads that as "no family selected" and clears every fully selected family of the config. GEA-1698 fixed the case where the parent dialog held a stale value for one family; this is the case where it holds no family at all.

The in-use notice replaced families, scanner preferences and NVT preferences, and the component cut the request down to name, comment and id. gvmd no longer refuses those changes (greenbone/gvmd#3099), so the dialog can show the full form.

References

GEA-1698, greenbone/gvmd#3099

Checklist

  • Tests

The edit dialog fetches the config and the list of NVT families in parallel
and builds trend and select from both, once, as soon as the config has
arrived. When the config arrived first the family list was still undefined,
so the selection came out empty and stayed that way. Saving then sent a
family selection covering no family, which gsad turns into a family_selection
element without a single family, and gvmd reads that as "deselect
everything": every fully selected family of the config was cleared.

Wait for both requests before building the selection, and leave the family
part out of the request while the selection is unknown, so a save can no
longer send an empty one.
@TheBeast85
TheBeast85 requested a review from a team as a code owner August 19, 2026 07:27
@greenbonebot
greenbonebot enabled auto-merge (rebase) August 19, 2026 07:27
@TheBeast85 TheBeast85 changed the title Allow editing a scan config in use, and stop an unloaded family list from deselecting every NVT Change: allow editing a scan config in use, and do not deselect every NVT when the families are not loaded Aug 19, 2026
The edit dialog replaced families, scanner preferences and NVT preferences
with a notice as soon as a task referred to the config, and the component
cut the request down to name, comment and id. The same applied to a policy
that an audit refers to.

gvmd no longer refuses these changes, so the dialog shows the full form and
sends everything the user edited.
@bjoernricks

Copy link
Copy Markdown
Contributor

Please split such things into two different PRs. As I mentioned in your other PRs the "in use" changes have no chance of being applied at the moment. This is nothing we are going to change anytime soon. It has a serious use case.

If you want the fix for the trend/select stuff merged feel free to adapt this PR and force push or to close it and create a new PR.

auto-merge was automatically disabled August 19, 2026 07:48

Head branch was pushed to by a user without write access

@TheBeast85
TheBeast85 force-pushed the change/edit-scan-config-in-use branch from cd237a1 to db6fa1b Compare August 19, 2026 07:48
@greenbonebot
greenbonebot enabled auto-merge (rebase) August 19, 2026 07:48
@bjoernricks

Copy link
Copy Markdown
Contributor

@TheBeast85 The allow editing a scan config in use has no chance of being merged. Please read my comment above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants