How to make references (via custom fields in the referring object) to a referred-object visible from the referred object?

[menckend]

That's a terrible, title, but hopefully this will clarify somewhat:

We can use the custom-fields functionality to add an additional field to most constructs, and we can define that custom-field such that its values can only be instances of some other construct-type. We found this functionality useful when we wanted a way to map NaaS EVPLs to multiple "circuit" constructs. (Long story, but the way we're modeling the NaaS services, the physical access-ports get represented as a "circuit".) We added a custom-field to the L2VPN content-type, and defined it as type=multiple-objects and object-type=circuit.

The L2PVN table (the referring side) entries now have explicit references to circuit table entries (the referred side.) Now, when we look at the L2VPN object, we can explicitly see which "circuits" we have it associated with.

What I'm wondering is... is there any way to make that referral "visible" from the referred side? It would be "even nicer" for us, if when we looked at the "circuit" record, we could see directly from that view that one or more L2VPNs were "associated" to it. Something along the lines of having the standard content-type window render with column called "inbound references" that would be generated by: (1) querying the custom-fields table to get the "content-type" values and "name" value for any entries where the "object-type" matched the object-type of the current content-type-window; and (2) querying each retrieved "content-type" value's corresponding table to get a list of entries whose custom-field value is a match for the name of the current-content-type instance.

In my example, for instance, the "circuits" display form would query the custom-fields table, and get a list of all the "content-types" that were included in a custom-field that used the "circuits" "object-type". "L2VPNs" would be the only match (in our "NaaSProviderPorts" custom field), so then it would query the L2VPN table, searching the "NaaSProviderPorts" field for a value that matched the name of the circuit currently being displayed. If it found any matches, it would display them in a"incoming referral" table in the circuits form.

FWIW, it's not lost on me that what we're doing is pretty-much brute-forcing our own extension to the (intentionally curated) Netbox data-model. As such, I don't expect that the functionality would ever really be high on the to-do list, but am curious if anyone else was trying something similar and had a better approach. (Tagging could certainly do the trick, but would get cumbersome quite quickly.)

Any assistance greatly appreciated!

[mtinberg]

What I'm doing right now for this kind of thing is using a Custom URL to point to the query showing that is pointed to itself, eg on /modelA/1234 link /modelB/?cf_modelA_id=1234 to find all modelB's that point to modelA 1234. You could also create mutually pointing multiple-object custom fields and mark one side as read-only in the WebUI then have a custom Script update the reverse relationships periodically, to paraphrase your example if L2VPNs point to Circuits, then have a read-only custom field on Circuits that points to L2VPNs only updated by Script. That'd probably get you close enough to the UI behavior that you want, and if it becomes a core feature you can just drop your customizations. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Mencken Davidson ***@***.***> Sent: Wednesday, May 3, 2023 10:28 PM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: [netbox-community/netbox] How to make references (via custom fields in the referring object) to a referred-object visible from the referred object? (Discussion #12462) That's a terrible, title, but hopefully this will clarify somewhat: We can use the custom-fields functionality to add an additional field to most constructs, and we can define that custom-field such that its values can only be instances of some other construct-type. We found this functionality useful when we wanted a way to map NaaS EVPLs to multiple "circuit" constructs. (Long story, but the way we're modeling the NaaS services, the physical access-ports get represented as a "circuit".) We added a custom-field to the L2VPN content-type, and defined it as type=multiple-objects and object-type=circuit. The L2PVN table (the referring side) entries now have explicit references to circuit table entries (the referred side.) Now, when we look at the L2VPN object, we can explicitly see which "circuits" we have it associated with. What I'm wondering is... is there any way to make that referral "visible" from the referred side? It would be "even nicer" for us, if when we looked at the "circuit" record, we could see directly from that view that one or more L2VPNs were "associated" to it. Something along the lines of having the standard content-type window render with column called "inbound references" that would be generated by: (1) querying the custom-fields table to get the "content-type" values and "name" value for any entries where the "object-type" matched the object-type of the current content-type-window; and (2) querying each retrieved "content-type" value's corresponding table to get a list of entries whose custom-field value is a match for the name of the current-content-type instance. In my example, for instance, the "circuits" display form would query the custom-fields table, and get a list of all the "content-types" that were included in a custom-field that used the "circuits" "object-type". "L2VPNs" would be the only match (in our "NaaSProviderPorts" custom field), so then it would query the L2VPN table, searching the "NaaSProviderPorts" field for a value that matched the name of the circuit currently being displayed. If it found any matches, it would display them in a"incoming referral" table in the circuits form. FWIW, it's not lost on me that what we're doing is pretty-much brute-forcing our own extension to the (intentionally curated) Netbox data-model. As such, I don't expect that the functionality would ever really be high on the to-do list, but am curious if anyone else was trying something similar and had a better approach. (Tagging could certainly do the trick, but would get cumbersome quite quickly.) Any assistance greatly appreciated! — Reply to this email directly, view it on GitHub<#12462>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM4UL26JM5LMDNYXCELXEMO7TANCNFSM6AAAAAAXVG4AZ4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[menckend]

Thanks, Mark. Those both seem like viable strategies to me, but I think I prefer the custom-URL so far.