CustomObject reverse viewable #6951

New Issue

adam · 2025-12-29T19:47:07+01:00

adam commented

2025-12-29 19:47:07 +01:00

Originally created by @PieterL75 on GitHub (Sep 8, 2022).

NetBox version

v3.3.2

Feature type

Change to existing functionality

Proposed functionality

a Custom(Multi)Object is linked from one object to another.
Currently only the model where the CF is applied on, will show the linked object.
Well work with this example: a Cluster can have a CustomObject of the IPAddress type.

When viewing the Cluster object, the IPAddresses are displayed
On the other side, when looking at the IPAddress object, there is no reference visible to the Cluster object.

It would benefit, if this relation could be visualized on both Objects.
The IP Address side, then would present a view-only to the Cluster object,

Use case

In the case of the example, you can easily see that the IPAddress is already linked to another Netbox object.
This prevents extra work to find the Cluster and check that the IP is there
(still working with an example of Cluster and IPAddress. There are more examples in the netbox slack channel, like 2 vlans that can be linked to eachother)

Database changes

No response

External dependencies

No response

Originally created by @PieterL75 on GitHub (Sep 8, 2022). ### NetBox version v3.3.2 ### Feature type Change to existing functionality ### Proposed functionality a Custom(Multi)Object is linked from one object to another. Currently only the model where the CF is applied on, will show the linked object. Well work with this example: a Cluster can have a CustomObject of the IPAddress type. When viewing the Cluster object, the IPAddresses are displayed On the other side, when looking at the IPAddress object, there is no reference visible to the Cluster object. It would benefit, if this relation could be visualized on both Objects. The IP Address side, then would present a view-only to the Cluster object, ### Use case In the case of the example, you can easily see that the IPAddress is already linked to another Netbox object. This prevents extra work to find the Cluster and check that the IP is there (still working with an example of Cluster and IPAddress. There are more examples in the netbox slack channel, like 2 vlans that can be linked to eachother) ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature status: under review labels 2025-12-29 19:47:07 +01:00

adam closed this issue

2025-12-29 19:47:07 +01:00

adam commented

2025-12-29 19:47:07 +01:00

@jeremystretch commented on GitHub (Sep 15, 2022):

IMO this is getting a little too far into what should be purpose-built relationships in the database. At some point you're just fabricating a schema without actually employing one in the database. The next iteration on this proposal would be controlling one-to-one versus many-to-one relationships; it's just a bridge too far. The object and multi-object custom fields types were (I think) a reasonable compromise between the flexibility of custom fields and the friction effected by the introduction of custom schema, however true reverse relationships will require the later in some form.

Honestly, plugins are the better approach here, considering that you'll likely often need to apply more constraints to the relationship than a plain foreign key (e.g. for uniqueness), and you'll need some way of displaying the reverse relationship in a way that makes sense anyway.

@jeremystretch commented on GitHub (Sep 15, 2022): IMO this is getting a little too far into what should be purpose-built relationships in the database. At some point you're just fabricating a schema without actually employing one in the database. The next iteration on this proposal would be controlling one-to-one versus many-to-one relationships; it's just a bridge too far. The object and multi-object custom fields types were (I think) a reasonable compromise between the flexibility of custom fields and the friction effected by the introduction of custom schema, however true reverse relationships will require the later in some form. Honestly, plugins are the better approach here, considering that you'll likely often need to apply more constraints to the relationship than a plain foreign key (e.g. for uniqueness), and you'll need some way of displaying the reverse relationship in a way that makes sense anyway.

adam commented

2025-12-29 19:47:08 +01:00

@ryanmerolle commented on GitHub (Oct 22, 2022):

I agree plugins are likely the better approach long term for users for all the reasons you mentioned. Let me walk through a few more common use case of I can think of:

Site to be associated an optional provider (Equinix can be a "circuit" provider and facility owner)
Device to be associated to an optional provider to track gear managed by a provider for the purposes of a service/circuit (skips tenant model I know).
Instead of associating a device to a provider directly, Tenant associated to a provider, thus you have a linkage from device to tenant to provider.
IPAM objects associated to racks, locations, devices, for modeling/abstraction purposes
Really just thinking out loud here trying to understand where the line should be drawn.

Users not as familiar with Python or data modeling will not really understand the impact to the underlying schemas. It is even harder to push back against that given nautobot treats custom relationships in the exact same way this feature request is looking for. Here is the doc for reference.

@ryanmerolle commented on GitHub (Oct 22, 2022): I agree plugins are likely the better approach long term for users for all the reasons you mentioned. Let me walk through a few more common use case of I can think of: - Site to be associated an optional provider (Equinix can be a "circuit" provider and facility owner) - Device to be associated to an optional provider to track gear managed by a provider for the purposes of a service/circuit (skips tenant model I know). - Instead of associating a device to a provider directly, Tenant associated to a provider, thus you have a linkage from device to tenant to provider. - IPAM objects associated to racks, locations, devices, for modeling/abstraction purposes Really just thinking out loud here trying to understand where the line should be drawn. Users not as familiar with Python or data modeling will not really understand the impact to the underlying schemas. It is even harder to push back against that given nautobot treats custom relationships in the exact same way this feature request is looking for. [Here is the doc for reference.](https://docs.nautobot.com/projects/core/en/stable/models/extras/relationship/?h=relations#via-relationship-associations-endpoint)

adam commented

2025-12-29 19:47:08 +01:00

@jeremystretch commented on GitHub (Oct 22, 2022):

Closing this out as I don't think there's anything actionable here.

@jeremystretch commented on GitHub (Oct 22, 2022): Closing this out as I don't think there's anything actionable here.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#6951