Display contact of parent objects

[m0nkeyc0de]

NetBox version

v4.1.7

Feature type

Other

Triage priority

N/A

Proposed functionality

When contacts are assigned to an objet which can have child objects (for example Site Group, Site, Location, ...) they don't appear in the contact list of the child objects.

A contact assigned to a Site Group is very likely valid for a Sites of the Site Group (otherwise it would be assigned to the Site itself).
The same logic can be applied for the "Site > Location", "Location > Location" relationships.

The contacts of all parent objects should be visible in the contact list of the child objects.

Use case

NetBox users will spend less time assigning Contacts and will also more quickly have access to all relevants Contacts for a Location.

Database changes

No database change is needed as it's in the GUI.

Maybe a setting could be added to enable/disable that feature.

External dependencies

No external dependencies

[alehaa]

I like this FR and think its fairly easy to implement. If accepted, I volunteer to provide a PR for this.

1. I'd change ObjectContactsView to check in get_children(), whether parent is a NestedGroupModel. If so, one can filter for all parents including the child, otherwise just the child as it does now.
2. If needed, views could extend this filterset as needed. I'm think about showing contacts of the site if a location is accessed (e.g. facility manager of a Site, also responsible for the Location).

Of course, the contacts should be sorted in a meaningful way, e.g. from most specific to least specific.

[arthanson]

@alehaa do you want me to assign this to you?

[rboucher-me]

This would also require an update in the API. Both in the API and UI we should indicate from where the contact was inherited.

[alehaa]

@arthanson you can assign this to me. However, I'm a little confused by the "needs milestone" tag. Doesn't that mean we're waiting for confirmation if and when the maintainers allow submissions?

[arthanson]

@alehaa assigned. The needs milestone means that it will cause API changes or such that can't be done in a minor point release. This would be included in the upcoming 4.3 release.

[alehaa]

@rboucher-me, can you please elaborate on what changes you think are needed for the API? Unlike the UI views, there are currently no individual contact assignment API endpoints per object type, only the generic /api/tenancy/contact-assignments/. So the logic for extending returned contacts would be different for these two concepts.