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

Custom fields with default values appear as applied filters in object list views #5920

New Issue
Closed
opened 2025-12-29 19:34:15 +01:00 by adam · 8 comments
adam commented 2025-12-29 19:34:15 +01:00
Owner
Copy Link

Originally created by @jasonyates on GitHub (Jan 11, 2022).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

3.1.2

Python version

3.8

Steps to Reproduce

Create a 'Selection' custom field with no default value applied to DCIM -> Sites
Visit /dcim/sites

Filter tab aways shows [1] filter applied. No filter shows applied on the table view itself

Screenshot 2022-01-11 at 16 00 11

Apply an actual filter, i.e. Status: Active
2 filters show applied. The one actually applied + the phantom custom field with an empty value

Screenshot 2022-01-11 at 16 02 29

Expected Behavior

Custom field filter should not be applied by default?

Observed Behavior

Filter tab aways shows [1] filter applied. No filter shows applied on the table view itself

Originally created by @jasonyates on GitHub (Jan 11, 2022). Originally assigned to: @jeremystretch on GitHub. ### NetBox version 3.1.2 ### Python version 3.8 ### Steps to Reproduce Create a 'Selection' custom field with no default value applied to DCIM -> Sites Visit /dcim/sites Filter tab aways shows [1] filter applied. No filter shows applied on the table view itself <img width="478" alt="Screenshot 2022-01-11 at 16 00 11" src="https://user-images.githubusercontent.com/242483/148977634-ac3d47c1-d0a8-48d9-a654-f643f3a7e172.png"> Apply an actual filter, i.e. Status: Active 2 filters show applied. The one actually applied + the phantom custom field with an empty value <img width="574" alt="Screenshot 2022-01-11 at 16 02 29" src="https://user-images.githubusercontent.com/242483/148977694-6e297667-fa88-42d9-8181-d0c71ec7d253.png"> ### Expected Behavior Custom field filter should not be applied by default? ### Observed Behavior Filter tab aways shows [1] filter applied. No filter shows applied on the table view itself
adam added the type: bugstatus: accepted labels 2025-12-29 19:34:15 +01:00
adam closed this issue 2025-12-29 19:34:15 +01:00
adam commented 2025-12-29 19:34:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 11, 2022):

Create a 'Selection' custom field with no default value applied to DCIM -> Sites

What name are you assigning to the field?

@jeremystretch commented on GitHub (Jan 11, 2022): > Create a 'Selection' custom field with no default value applied to DCIM -> Sites What name are you assigning to the field?
adam commented 2025-12-29 19:34:17 +01:00
Author
Owner
Copy Link

@jasonyates commented on GitHub (Jan 11, 2022):

It's a pretty basic custom field with no validation rules and 5 selection options configured as below. Name is 'SD-WAN Deployment Type'

Screenshot 2022-01-11 at 18 57 40
@jasonyates commented on GitHub (Jan 11, 2022): It's a pretty basic custom field with no validation rules and 5 selection options configured as below. Name is 'SD-WAN Deployment Type' <img width="1512" alt="Screenshot 2022-01-11 at 18 57 40" src="https://user-images.githubusercontent.com/242483/149004501-258242c3-6532-4b29-bfb8-f9e920be977f.png">
adam commented 2025-12-29 19:34:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 11, 2022):

Name is 'SD-WAN Deployment Type'

This name should fail validation when attempting to save the custom field, as only alphanumeric characters and underscores are permitted as of v3.1.1 (see #8030).

At any rate, I'm not able to reproduce this on v3.1.5, even using the same exact field name (by bypassing validation).

@jeremystretch commented on GitHub (Jan 11, 2022): > Name is 'SD-WAN Deployment Type' This name should fail validation when attempting to save the custom field, as only alphanumeric characters and underscores are permitted as of v3.1.1 (see #8030). At any rate, I'm not able to reproduce this on v3.1.5, even using the same exact field name (by bypassing validation).
adam commented 2025-12-29 19:34:17 +01:00
Author
Owner
Copy Link

@jasonyates commented on GitHub (Jan 11, 2022):

This name should fail validation when attempting to save the custom field, as only alphanumeric characters and underscores are permitted as of v3.1.1 (see #8030).

At any rate, I'm not able to reproduce this on v3.1.5, even using the same exact field name (by bypassing validation).

Are there any debug logs worth collecting before I try and re-save the custom field without the - in the name? I'm able to replicate the behaviour across user accounts and browsers.

Even hitting 'Clear All' still results in Filter [1] showing in the tab.

@jasonyates commented on GitHub (Jan 11, 2022): > This name should fail validation when attempting to save the custom field, as only alphanumeric characters and underscores are permitted as of v3.1.1 (see #8030). > > At any rate, I'm not able to reproduce this on v3.1.5, even using the same exact field name (by bypassing validation). Are there any debug logs worth collecting before I try and re-save the custom field without the - in the name? I'm able to replicate the behaviour across user accounts and browsers. Even hitting 'Clear All' still results in Filter [1] showing in the tab.
adam commented 2025-12-29 19:34:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 11, 2022):

See if you can reproduce it on the demo instance (which is running v3.1.5): https://demo.netbox.dev/

@jeremystretch commented on GitHub (Jan 11, 2022): See if you can reproduce it on the demo instance (which is running v3.1.5): https://demo.netbox.dev/
adam commented 2025-12-29 19:34:17 +01:00
Author
Owner
Copy Link

@jasonyates commented on GitHub (Jan 11, 2022):

See if you can reproduce it on the demo instance (which is running v3.1.5): https://demo.netbox.dev/

I can immediately replicate this on the demo instance once I add the same custom field, even once complying with the new name requirements.

Screenshot 2022-01-11 at 19 36 34
@jasonyates commented on GitHub (Jan 11, 2022): > See if you can reproduce it on the demo instance (which is running v3.1.5): https://demo.netbox.dev/ I can immediately replicate this on the demo instance once I add the same custom field, even once complying with the new name requirements. <img width="1015" alt="Screenshot 2022-01-11 at 19 36 34" src="https://user-images.githubusercontent.com/242483/149009565-5d3c8c31-856a-40a7-a28f-0a88e1fb325d.png">
adam commented 2025-12-29 19:34:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 11, 2022):

Looks like this only occurs when you've defined a default value for the custom field. Again, this is why it's so important to note every step taken to reproduce the issue when opening a bug report: It saves a lot of time.

@jeremystretch commented on GitHub (Jan 11, 2022): Looks like this only occurs when you've defined a default value for the custom field. Again, this is why it's so important to note **every step** taken to reproduce the issue when opening a bug report: It saves a lot of time.
adam commented 2025-12-29 19:34:18 +01:00
Author
Owner
Copy Link

@jasonyates commented on GitHub (Jan 11, 2022):

Looks like this only occurs when you've defined a default value for the custom field. Again, this is why it's so important to note every step taken to reproduce the issue when opening a bug report: It saves a lot of time.

My mistake. When I looked at the custom field when creating the report, I assumed N/A meant no default value as opposed to the fact I'd actually set it to N/A.

@jasonyates commented on GitHub (Jan 11, 2022): > Looks like this only occurs when you've defined a default value for the custom field. Again, this is why it's so important to note **every step** taken to reproduce the issue when opening a bug report: It saves a lot of time. My mistake. When I looked at the custom field when creating the report, I assumed N/A meant no default value as opposed to the fact I'd actually set it to N/A.
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: bug
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#5920
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?