Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom fields only showing by Role, Type or tags #11367

Closed
chesronw opened this issue Jan 3, 2023 · 3 comments
Closed

Custom fields only showing by Role, Type or tags #11367

chesronw opened this issue Jan 3, 2023 · 3 comments
Labels
type: feature Introduction of new functionality to the application

Comments

@chesronw
Copy link

chesronw commented Jan 3, 2023

NetBox version

V3.3.5

Feature type

New functionality

Proposed functionality

It would be nice that we can define the custom fields based on for example the type or role of a device.
At this moment you can add a custom field only to a specific module in Netbox.

If there is a possibility to add an extra filter on the custom field that will be very helpful to add an custom field only for specific modules where needed.

Use case

In this use case we want to add a custom field to define the support level of a switch.
To add this custom field we can add a custom field for the module "Device" (See example below)

The problem with this is that this custom field is add to all another devices that are created.
Not every device needs this custom field. Or for other departments than the network team needs that custom field.

That is the reason that it would be nice if we have an sub filter to only show the custom field based by the role or something like that.

image

Database changes

No response

External dependencies

No response

@chesronw chesronw added the type: feature Introduction of new functionality to the application label Jan 3, 2023
@candlerb
Copy link
Contributor

Custom fields are generic - a given custom field can be linked to almost any type of object - so I don't think it makes sense to filter on Device Role or Device Type (unless "Role" were to be made completely generic and shared by all objects - there are quite a few which have some sort of "Role" already).

However, tags are also generic. Therefore, it should in principle be straightforward to bind a custom field to tags as well as object types, so that it's only displayed if an object has a particular tag present.

I'm not sure what should happen to CF data if the tag is subsequently removed from an object. Either you always display non-empty CF data; or you have to delete the custom field data when the tag is removed (dangerous); or you have to prevent the removal of the tag from an object if there is non-empty related CF data present (probably the safest option).

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions github-actions bot added the pending closure Requires immediate attention to avoid being closed for inactivity label Apr 21, 2023
@jeremystretch
Copy link
Member

I'm not sure what should happen to CF data if the tag is subsequently removed from an object. Either you always display non-empty CF data; or you have to delete the custom field data when the tag is removed (dangerous); or you have to prevent the removal of the tag from an object if there is non-empty related CF data present (probably the safest option).

The need to conditionally enable or disable custom fields based on some other object attribute is a clear signal that you've outgrown the functionality provided by custom fields, and should instead pursue a purpose-built extension to NetBox's data model via a custom plugin. Trying to hack something together using custom fields is only going to ultimately cost you more time and effort while delivering a subpar solution.

@jeremystretch jeremystretch closed this as not planned Won't fix, can't repro, duplicate, stale May 2, 2023
@jeremystretch jeremystretch removed the pending closure Requires immediate attention to avoid being closed for inactivity label May 2, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

3 participants