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

Custom fields - Allow use of query params for filtering object selection #9927

New Issue
Closed
opened 2025-12-29 21:24:31 +01:00 by adam · 7 comments
adam commented 2025-12-29 21:24:31 +01:00
Owner
Copy Link

Originally created by @samk-acw on GitHub (Jul 2, 2024).

Originally assigned to: @samk-acw on GitHub.

NetBox version

v4.0.6

Feature type

Change to existing functionality

Proposed functionality

Object type custom fields are very useful for creating new relationships between objects, but it has no ability to filter the selection list, any object of that type can be selected which may not be desirable depending on the intended purpose of the custom field.

The DynamicModelChoice mixins already support filtering the API requests using the query_params dict, I propose that this be added as an option to specify in the custom field definition.

Use case

Allowing filtering of the object choice selection would allow additional business logic to be applied and provide a more intuitive experience for the end user who is using the field.
For example, I have a custom field defined on Circuits to select an IP Address - with a query params definition I could limit it to show only 'active' IP addresses, and chain it to tenant field with $tenant to only list IPs that are assigned to the tenant of that circuit.

Database changes

CustomField model will need an additional field to store the parameter

External dependencies

none

Originally created by @samk-acw on GitHub (Jul 2, 2024). Originally assigned to: @samk-acw on GitHub. ### NetBox version v4.0.6 ### Feature type Change to existing functionality ### Proposed functionality Object type custom fields are very useful for creating new relationships between objects, but it has no ability to filter the selection list, any object of that type can be selected which may not be desirable depending on the intended purpose of the custom field. The DynamicModelChoice mixins already support filtering the API requests using the query_params dict, I propose that this be added as an option to specify in the custom field definition. ### Use case Allowing filtering of the object choice selection would allow additional business logic to be applied and provide a more intuitive experience for the end user who is using the field. For example, I have a custom field defined on Circuits to select an IP Address - with a query params definition I could limit it to show only 'active' IP addresses, and chain it to tenant field with $tenant to only list IPs that are assigned to the tenant of that circuit. ### Database changes CustomField model will need an additional field to store the parameter ### External dependencies none
adam added the status: acceptedtype: featurecomplexity: low labels 2025-12-29 21:24:31 +01:00
adam closed this issue 2025-12-29 21:24:31 +01:00
adam commented 2025-12-29 21:24:32 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jul 3, 2024):

Thanks for your interest in helping improve NetBox.

Your proposal and use case look good enough to work with, so I'm moving your issue along to needs owner status. If you or another developer with the requisite skills and capacity would like to work it through to a PR, please say so and a maintainer will assign the issue to you.

@jeffgdotorg commented on GitHub (Jul 3, 2024): Thanks for your interest in helping improve NetBox. Your proposal and use case look good enough to work with, so I'm moving your issue along to `needs owner` status. If you or another developer with the requisite skills and capacity would like to work it through to a PR, please say so and a maintainer will assign the issue to you.
adam commented 2025-12-29 21:24:32 +01:00
Author
Owner
Copy Link

@samk-acw commented on GitHub (Jul 4, 2024):

Hi Jeff, I've done a proof-of-concept test that worked, so I'm happy work on a PR.

rough plan is:

  1. add a JSONField to customfield model called "object choice filter"
  2. add field to customfield form, template, and api serializer
  3. modify to_form_field() function to load field value into query_params
  4. add to documentation
@samk-acw commented on GitHub (Jul 4, 2024): Hi Jeff, I've done a proof-of-concept test that worked, so I'm happy work on a PR. rough plan is: 1. add a JSONField to customfield model called "object choice filter" 2. add field to customfield form, template, and api serializer 3. modify to_form_field() function to load field value into query_params 4. add to documentation
adam commented 2025-12-29 21:24:32 +01:00
Author
Owner
Copy Link

@samk-acw commented on GitHub (Jul 18, 2024):

Hi @jeffgdotorg, just checking on the status of this. Can I provide a PR?
Thanks

@samk-acw commented on GitHub (Jul 18, 2024): Hi @jeffgdotorg, just checking on the status of this. Can I provide a PR? Thanks
adam commented 2025-12-29 21:24:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 18, 2024):

@samk-acw thanks for your interest, I've assigned this to you.

@jeremystretch commented on GitHub (Jul 18, 2024): @samk-acw thanks for your interest, I've assigned this to you.
adam commented 2025-12-29 21:24:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 26, 2024):

It appears this FR was tagged for implementation prematurely. Introducing a new field on a model can only be done in a new minor release: This should have been tagged for milestone assignment. Unfortunately we're in the process of rolling up the last pieces of open work for v4.1 right now.

@samk-acw if you'd like to rebase your PR #16957 off of the feature branch for the upcoming v4.1 release, we can try to slip it in, but I can't make any promises. Apologies for the confusion.

@jeremystretch commented on GitHub (Jul 26, 2024): It appears this FR was tagged for implementation prematurely. Introducing a new field on a model can only be done in a new minor release: This should have been tagged for milestone assignment. Unfortunately we're in the process of rolling up the last pieces of open work for v4.1 right now. @samk-acw if you'd like to rebase your PR #16957 off of the `feature` branch for the upcoming v4.1 release, we can try to slip it in, but I can't make any promises. Apologies for the confusion.
adam commented 2025-12-29 21:24:33 +01:00
Author
Owner
Copy Link

@samk-acw commented on GitHub (Jul 26, 2024):

Hi @jeremystretch, thanks for clarifying, I've deleted my original branch and done a new PR based from the feature branch now.
Made a bit of a mess while trying to rebase it on the original, hopefully I've cleaned that all up.

@samk-acw commented on GitHub (Jul 26, 2024): Hi @jeremystretch, thanks for clarifying, I've deleted my original branch and done a new PR based from the feature branch now. Made a bit of a mess while trying to rebase it on the original, hopefully I've cleaned that all up.
adam commented 2025-12-29 21:24:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 26, 2024):

This is a good reminder that we really need to get #14656 implemented. The custom field form is a mess.

@jeremystretch commented on GitHub (Jul 26, 2024): This is a good reminder that we really need to get #14656 implemented. The custom field form is a mess.
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 complexity: low 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#9927
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?