Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Enabled" flag is reset during editing of an interface if "802.1Q Mode" is changed #13064

Closed
derdeagle opened this issue Jul 1, 2023 · 3 comments · Fixed by #13963
Closed
Assignees
Labels
severity: medium Results in substantial degraded or broken functionality for specfic workflows status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@derdeagle
Copy link

NetBox version

v3.5.4

Python version

3.10

Steps to Reproduce

  1. edit an interface of hardware or a VM
  2. change the state of the Enabled flag, it doesn't matter if it is checked or not, it just needs to be changed
  3. change the value for the 802.1Q Mode

Expected Behavior

The set value (checked or unchecked) for the Enabled flag should be preserved during editing of an interface and not be reset to the current actual state when changing anything.

Observed Behavior

The state for the Enabled flag is reset to the current actual state when 802.1Q Mode is changed.

@derdeagle derdeagle added the type: bug A confirmed report of unexpected behavior in the application label Jul 1, 2023
@derdeagle derdeagle changed the title [BUG] "Enabled" flag is reset during editing of an interface if "802.1Q Mode" is changed "Enabled" flag is reset during editing of an interface if "802.1Q Mode" is changed Jul 1, 2023
@abhi1693 abhi1693 added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation severity: medium Results in substantial degraded or broken functionality for specfic workflows labels Jul 2, 2023
@jeremystretch
Copy link
Member

it doesn't matter if it is checked or not, it just needs to be changed

In my testing, I was only able to replicate this when unchecking the enabled field (or any other checkbox field).

This is probably due to a caveat concerning checkbox fields. When the 802.1Q field value is changed, it triggers the form to re-render. All of the current field values are passed and populated in the newly-rendered form, however unticked checkboxes are omitted from this data. This causes checkbox fields to render with their original values (whether checked or unhcecked).

Ideally we should force the inclusion of unchecked checkbox fields as well.

@jiuka
Copy link

jiuka commented Aug 4, 2023

htmx has a function shouldInclude to check if a input should be included which for a checkbox is only true if the checkbox is marked. https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js#L2344C28-L2344C35 I was therefore not successful in forcing the inclusion of the not selected checkbox.

What I was able to get working was only replacing parts of the form with the help of hx-select. To get this working i had to add an id to each field-group, extend the HTMXSelect to ad the hx-select attribute with the same value as hx-target and add a parameter to the call of HTMXSelect in InterfaceForm to only replace the 802.1q Switching filed Group.

This would work for the issue, as the whole 802.1q Group has no checkbox in it. However there could be cases where this would not work, for example if the form group which should be replaced has a checkbox in it which should be preserved.

How do you feel about this approach? If desired I can create a pr with this approach.

An other solution could be to tag all checkbox with hx-preserve to have htmx preserve them. However I was not able to figure out how to do this.

@netbox-community netbox-community deleted a comment from salfers Sep 21, 2023
@jeremystretch jeremystretch self-assigned this Oct 3, 2023
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Oct 3, 2023
jeremystretch added a commit that referenced this issue Oct 3, 2023
jeremystretch added a commit that referenced this issue Oct 4, 2023
@derdeagle
Copy link
Author

@jeremystretch Thank you!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
severity: medium Results in substantial degraded or broken functionality for specfic workflows status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
4 participants