netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
15.77k stars 2.54k forks source link

Add ability to assign contact groups to an object #17050

Open goteamkor opened 1 month ago

goteamkor commented 1 month ago

NetBox version

v4.0.7

Feature type

New functionality

Proposed functionality

Currently it is only possible to add a specific contact to an object (vm, ip, circuit, etc.). Please allow the ability to add a contact group rather than only a single contact.

EDIT: as part of this same request, please add the ability to have a contact group have the same data associated with it as a contact. IE: telephone number, email address, etc.

Use case

In many cases, objects (routers for example), are managed by an entire team. If I have a team of 5 network engineers, I want to let the rest of the users of netbox know that the network engineering 'team' is a technical contact for a switch/router. I don't want to have to add each team member. And if I replace a network engineer I've got hundreds/thousands of objects I need to update.

This has been discussed before here: https://github.com/netbox-community/netbox/discussions/8359 here: https://github.com/netbox-community/netbox/discussions/15064 and here: https://github.com/netbox-community/netbox/discussions/9088 but it doesn't appear it ever made it into a FR (I searched beforehand, but couldn't find anything)

Database changes

I do not believe a new model is required, but objects are very likely configured to reference a contact id specifically, rather than a group_id.

External dependencies

No response

goteamkor commented 1 month ago

Right now, the workaround that I use, and I imagine most everyone else is using too is to create a 'contact' that just has the first name and last name as the name of the group/team you want to reference.

This works, but in my opinion is messy. It would make more sense to be able to leverage the contact groups model that already exists.

alehaa commented 1 month ago

My assumption was that contact groups categorize contacts, e.g. "External" or "HR".

I somehow think this FR might get complicated. You might as well assign all switches to a tenant "NOC" and add the contacts to that tenant. However, this could result in conflicts when a device is managed by tenant A but managed for tenant B. And it would be hard to distinguish between contact groups and tenants.

goteamkor commented 1 month ago

Your assumption is correct. Contact groups categorize contacts.

If I have 5 network engineer contacts in the contact group "Network Engineering" which is a child group of the contact group "IT Operations" which is a child group of "Internal"

Internal

Vendors

This is an example of how my contact groups are laid out. I'm not sure why you brought tenants into the conversation. This FR scope is not to alter existing methodologies of tenants, tags, or anything else. NetBox already has contact groups. The FR is simply to add the functionality to assign not only contacts to an object (when the use case calls for an individual that is responsible for an object), but also a contact group (when the use case calls for multiple people that have a shared responsibility for an object).

Can you add the multiple people with the shared responsibility already? Sure you can. But if one of those people leaves and you hire a new network engineer, I've got hundreds or thousands of objects to update. If it's the contact group that is assigned, I only have 1 object to change (the contact group)

Since NetBox's intent is to model the real world, objects are sometimes managed not by any 1 person, or multiple named people, but by a group/team/department. Adding 5 people, 10 people, or 15 people inside a NOC or network engineer team onto hundreds of router objects is a bit burdensome.

goteamkor commented 1 month ago

I've found another work around. If you create a custom field as type 'object', and associate it with the related object type of 'tenancy > contact group' you sort of get most of the capability of this FR.

The problem though is you lose other valuable metadata for the contact association like 'role', 'priority', etc.