starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Change filter value for null choices #2161

New Issue
Closed
opened 2025-12-29 17:22:50 +01:00 by adam · 5 comments
adam commented 2025-12-29 17:22:50 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Nov 30, 2018).

Environment

  • Python version: 3.5.2
  • NetBox version: 2.4.8

Proposed Functionality

Currently, filtering for a null value uses the integer zero. For example, to find all devices not assigned to a rack, you would filter for:

/dcim/devices/?rack_id=0

I am proposing that we change this value to the string null:

/dcim/devices/?rack_id=null

This change involves removing the following two lines in settings.py (null is the default choice value):

FILTERS_NULL_CHOICE_LABEL = 'None'
FILTERS_NULL_CHOICE_VALUE = '0'

While this is a simple change, it is fairly disruptive, particularly to API consumers, and should be well communicated upon implementation.

Use Case

Using 0 to represent a null value works fine for ForeignKey fields, however it causes problems when filtering on BooleanFields, as was raised in #2357. I'm not sure why we went with 0 originally. I want to say that it was because earlier versions of the django-filter library didn't have built-in support for null filtering but I could be wrong.

Database Changes

None

External Dependencies

None

Originally created by @jeremystretch on GitHub (Nov 30, 2018). ### Environment * Python version: 3.5.2 * NetBox version: 2.4.8 ### Proposed Functionality Currently, filtering for a null value uses the integer zero. For example, to find all devices not assigned to a rack, you would filter for: ``` /dcim/devices/?rack_id=0 ``` I am proposing that we change this value to the string `null`: ``` /dcim/devices/?rack_id=null ``` This change involves removing the following two lines in `settings.py` (`null` is the default choice value): ``` FILTERS_NULL_CHOICE_LABEL = 'None' FILTERS_NULL_CHOICE_VALUE = '0' ``` While this is a simple change, it is fairly disruptive, particularly to API consumers, and should be well communicated upon implementation. ### Use Case Using `0` to represent a null value works fine for ForeignKey fields, however it causes problems when filtering on BooleanFields, as was raised in #2357. I'm not sure why we went with `0` originally. I want to say that it was because earlier versions of the django-filter library didn't have built-in support for null filtering but I could be wrong. ### Database Changes None ### External Dependencies None
adam added the status: acceptedtype: feature labels 2025-12-29 17:22:50 +01:00
adam closed this issue 2025-12-29 17:22:50 +01:00
adam commented 2025-12-29 17:22:51 +01:00
Author
Owner
Copy Link

@jvanderaa commented on GitHub (Nov 30, 2018):

This would not be disruptive to anything that I have at this moment. None is a good representation.

@jvanderaa commented on GitHub (Nov 30, 2018): This would not be disruptive to anything that I have at this moment. None is a good representation.
adam commented 2025-12-29 17:22:51 +01:00
Author
Owner
Copy Link

@mmahacek commented on GitHub (Nov 30, 2018):

I was about to ask "Why not both" until I saw the part about boolean fields. I am not using any API calls to filter for null values, so this wouldn't be an issue for me.

@mmahacek commented on GitHub (Nov 30, 2018): I was about to ask "Why not both" until I saw the part about boolean fields. I am not using any API calls to filter for null values, so this wouldn't be an issue for me.
adam commented 2025-12-29 17:22:51 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Nov 30, 2018):

I am in favor of this change. I would also say this is merely a "breaking change" to something that is already broken.

@jeremystretch pertaining to communication, do you think it is too late to squeeze this into v2.5?

@lampwins commented on GitHub (Nov 30, 2018): I am in favor of this change. I would also say this is merely a "breaking change" to something that is already broken. @jeremystretch pertaining to communication, do you think it is too late to squeeze this into v2.5?
adam commented 2025-12-29 17:22:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 30, 2018):

Yeah, let's knock it out in v2.5. It's not terribly disruptive, and should be a trivial change for situations where it causes problems. I'd like to take a look at revamping query filters in the near future, and this is a blocker for that work.

@jeremystretch commented on GitHub (Nov 30, 2018): Yeah, let's knock it out in v2.5. It's not _terribly_ disruptive, and should be a trivial change for situations where it causes problems. I'd like to take a look at revamping query filters in the near future, and this is a blocker for that work.
adam commented 2025-12-29 17:22:51 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 30, 2018):

I would say what if you deprecated it in 2.5.0 and remove it in 2.5.5 (or whatever arbitrary version) where null filters and 0 filters.

If this is not possible to deprecated (because it requires x amount of new code to check for both) then I would be in favour of just doing it in 2.5.0

@DanSheps commented on GitHub (Nov 30, 2018): I would say what if you deprecated it in 2.5.0 and remove it in 2.5.5 (or whatever arbitrary version) where null filters and 0 filters. If this is not possible to deprecated (because it requires x amount of new code to check for both) then I would be in favour of just doing it in 2.5.0
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2161
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?