starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add ability to assign contact groups to an object #10033

New Issue
Open
opened 2025-12-29 21:26:02 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:26:02 +01:00
Owner
Copy Link

Originally created by @ghost on GitHub (Aug 1, 2024).

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

Originally created by @ghost on GitHub (Aug 1, 2024). ### 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_
adam added the type: featurecomplexity: mediumnetboxstatus: backlog labels 2025-12-29 21:26:02 +01:00
adam commented 2025-12-29 21:26:02 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 1, 2024):

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.

@ghost commented on GitHub (Aug 1, 2024): 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.
adam commented 2025-12-29 21:26:03 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Aug 2, 2024):

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.

@alehaa commented on GitHub (Aug 2, 2024): 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.
adam commented 2025-12-29 21:26:03 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 2, 2024):

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

  • IT Operations
    -- Network Engineering
    -- Systems Engineering
  • Human Resources
    -- Payroll

Vendors

  • Palo Alto
  • Cisco

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.

@ghost commented on GitHub (Aug 2, 2024): 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 - IT Operations -- Network Engineering -- Systems Engineering - Human Resources -- Payroll Vendors - Palo Alto - Cisco 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.
adam commented 2025-12-29 21:26:03 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 10, 2024):

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.

@ghost commented on GitHub (Aug 10, 2024): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: medium netbox status: backlog type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10033
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?