Add ability to filter for empty string values in an "OR" fashion

[bctiemann]

NetBox version

v4.1.0

Feature type

New functionality

Proposed functionality

Currently we can filter a field on an empty string value using (for example) type__empty=true, using functionality present in BaseFilterSet.get_additional_lookups. However, this construct only allows us to apply filters with different keys in an "AND" fashion, i.e. type=foo and type__empty=true are treated as separate filter conditions that both must be true. Also this type of filter must be entered into the URL manually, it is not available in the standard FilterForm classes.

Proposal is to create a NullableMultipleChoiceFilter (patterned after the existing NullableCharFieldFilter) which treats '' as one of several possible values for the field, e.g. ['foo', 'bar', ''], any of which returns a result in the filter. This would also make it possible to add an "(unset)" option in the choices presented in a FilterForm, such that the user can select all the applicable values from the dropdown and search them all at once.

Use case

It is cumbersome and obscure to use the bespoke lookups we currently support, such as type__empty, and it lacks flexibility. With this change, a user might select 2 or 3 different values in a multiple-choice filter input in the FilterForm, including the "empty" (unset) value (which would follow the system configurable settings.FILTERS_NULL_CHOICE_VALUE).

Note that this change is narrowly targeted at matching the empty string ''; it does not address any similar treatment of other programmatically generated additional lookups (such as __gt, __iexact, etc). For that reason this might be a low-priority use case or even contribute to a pattern inconsistency. However this also might be thought of as a building block to more rich filter inputs of a similar kind later.

Database changes

N/A

External dependencies

N/A

[jeremystretch]

Marking this as blocked by #17761 temporarily.

[jeremystretch]

With the completion of #17761 for the upcoming v4.2 release, I think this work is no longer needed. @bctiemann can you confirm?

[bctiemann]

I think that's right. I'll close my PR and we can close this too.