Closed samk-acw closed 1 month ago
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.
Hi Jeff, I've done a proof-of-concept test that worked, so I'm happy work on a PR.
rough plan is:
Hi @jeffgdotorg, just checking on the status of this. Can I provide a PR? Thanks
@samk-acw thanks for your interest, I've assigned this to you.
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.
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.
This is a good reminder that we really need to get #14656 implemented. The custom field form is a mess.
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