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

Removal of an option in a CustomFieldChoice does not update objects with the choiceset and the option selected #17558

Closed
cruse1977 opened this issue Sep 20, 2024 · 5 comments · Fixed by #17591
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@cruse1977
Copy link
Member

cruse1977 commented Sep 20, 2024

Deployment Type

NetBox Cloud

NetBox Version

v4.1.1

Python Version

3.12

Steps to Reproduce

  • Create a CustomFieldChoices with some options (A,B,C)
image
  • Create a Device Z
  • Create a custom field of type selection with the CustomFieldChoices
  • Assign the custom field to Device
  • On Device Z, on the custom field, assign choice B
image
  • In the CustomFieldChoiceSet delete option B
image
  • View Device Z

Expected Behavior

The selected option on the choiceset attached to device Z should be null/none, due to the option removal

Observed Behavior

Option B remains until the object is edited or saved, despite no longer existing.

image

Note - Due to the options inherent within ChoiceSets (eg: Non Null, default etc) but I'm trying to ascertain if this is a bug (ie: NetBox should warn/error on Objects with this choice selected) or expected behaviour - hence requesting feedback

@cruse1977 cruse1977 added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Sep 20, 2024
@arthanson arthanson added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation severity: low Does not significantly disrupt application functionality, or a workaround is available and removed status: needs triage This issue is awaiting triage by a maintainer labels Sep 23, 2024
@arthanson
Copy link
Collaborator

This should throw a validation error if you try to delete a choice and there are items assigned to that choice.

@goteamkor
Copy link

goteamkor commented Sep 23, 2024

just my 0.02 cents, I prefer the exiting method.
You should be able to remove options from a choice set, and objects currently referencing that option should maintain their selection until the next time you attempt to edit that object.

Removing a choice set doesn't make the choices selection on each object automatically invalid. It just means it's no longer available as a selection.

@arthanson arthanson 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 Sep 23, 2024
@arthanson arthanson self-assigned this Sep 23, 2024
@bctiemann
Copy link
Contributor

bctiemann commented Sep 24, 2024

I think I agree with @goteamkor -- I can think of a lot of use cases where you would want to retain the data from a time when an option was available, but have that option not be available to select anymore. Like if you had a list of "Supported Devices" and you had previously assigned a value from that list to a "device" field on some other model; and then that device becomes no longer supported, so you remove it from the list. I'd much rather have the device field stay filled in, to preserve the history of that object, and allow the freedom to define the custom field choices such that that device is no longer offered as "supported".

@jeremystretch
Copy link
Member

Removing a choice set doesn't make the choices selection on each object automatically invalid.

It does, by definition. Attempting to re-save an object with a selected choice that is no longer available will fail (or nullify that choice, depending on the mechanism). Allowing invalid choices to be defined would defeat the purpose of defining a set of choices in the first place.

@goteamkor
Copy link

goteamkor commented Sep 24, 2024

We're not talking about opening the object and trying to save it again with the same value that is no longer a valid option. I'm talking specifically about the FR here, which is to alter the behavior of what happens when removing an option from a choice set.

The proposed change would make the removal of an option from a choiceset set fail when trying to save because there are objects out there that still reference that option.
My statement was that just because an option has been removed from a choice set and there are objects that still have that option set shouldn't make the removal of the option from the choiceset fail.

You shouldn't have to go remove every reference to the option before netbox will let you remove the option from the choice set.

Basically what I'm advocating here is that existing behavior is maintained. I disagree with @arthanson that a validation error should be thrown when trying to remove an option from a choice set when objects reference that option. And I also disagree with @cruse1977 that when removing the option, all objects that reference that option should change to "null/none"

EDIT: I see there is already a pull request created. (#17591) I hope this doesn't get merged.

jeremystretch added a commit that referenced this issue Sep 30, 2024
bctiemann pushed a commit that referenced this issue Oct 11, 2024
jeremystretch added a commit to alehaa/netbox that referenced this issue Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants