Contact Objects

[Bill-Irvine]

Issue type: Feature Request

This may well be out of scope for Netbox as a technical application but thought i'd gauge interest in this feature.

I find myself managing several sites with the same contact. When that contact for example changes an email address, phone number, or someone takes over their role i am updating all the sites with that contact listed.

If this is changed to a contact object that we then attach to these sites we have a central place to manage these people without duplicating the data in separate sites.

From here we could add functionality such as adding several contacts to a site (primary, secondary), we could stipulate between a business contact or a technical contact, add which company they work for, have an api get request that lists contacts for a child object such as devices (useful for managing outages and notifications).

Let me know your thoughts.

[modir]

Not only would it be useful to have several contacts for sites, but for providers as well. There we often have as well a technical contact and a business contact.

[SzymonKurowski]

I have similar business needs in my organization (multiple contacts per site). I like the approach described above.

Is there anyone who is currently working on that? I would like to offer my contribution.

[SzymonKurowski]

There is a one key point to discuss. How to deal with current contact information added to Site model.

To implement this feature it is necessary to add new model (i.e. Contact) and then if we move contact from Site to the Contact model – it will break a backward-compatibility.

For the first iteration, I would leave Site contact fields (it can be treat as a main contact to the site) and add Contact model for any specific contacts. Additionally, each contact from Contact model can refer to more than one site.

Please let me know if you have any thoughts.

[mtbutler07]

+1 For adding multiple sources for contact information for sites.

[ryanmerolle]

I say for backwards compatibility, I would implement the way in which @SzymonKurowski mentions with one alteration:

• If no legacy site contact is recorded for a site, then netbox can default to showing the new contact fields.
• If a legacy site contact is recorded for a site, netbox will show the contact with a note directing the user to the new model.

[ryanmerolle]

It would also be useful to apply the contact object relationship to:

• Sites
• Regions
• Tenants
• Manufacturers
• Providers

You could argue for contacts to be linked to devices, racks, rack groups, and etc, but that would shift this tool to more of a CMDB for everything, and I am not sure we want to do that.

[adamkf]

@ryanmerolle: I agree this relationship might be useful across multiple object relationships. We managed a couple thousand internal subnets in our org and currently use custom fields to assign ownership responsibility for given subnets (eg: Network Team, Dev Team 1, Dev Team 88, Individual Person 23, etc) so when our security group reaches out and says "who owns this infected machine" we have a starting point.

This FR has been around since 2017. Has anyone made progress toward it? I'm happy to throw my time at as we have a need internally.

[athompson-merlin]

FWIW, I don't need extended contact capabilities on Sites, but I do desperately need Contacts on Tenants instead.
Having an optional Contact[s] object attachable to every top-level object would be ideal, who knows where I might need to hang contact information someday.

[jorp]

Would it be too much of a hassle to be able to bring contact information in from LDAP? Setting a contact as a specific user or group would be pretty beneficial.

[pisaniej]

What kind of relationship would a Contact have to an object?

For example, would virtualization.VirtualMachine be able to have multiple Contacts? I could see this being useful for an internal contact relating to an object, along with adding another for external vendor information.

[jeremystretch]

There are several themes in the discussion above that are important to identify individually:

1. Being able to reuse contact information for multiple objects without duplication
2. Being able to assign a contact to objects other than sites
3. Being able to assign multiple contacts for a single object
4. Conveying the nature of an assigned contact as it relates to the object (e.g. technical contact vs organizational owner)

I also want to highlight something @ryanmerolle pointed out:

You could argue for contacts to be linked to devices, racks, rack groups, and etc, but that would shift this tool to more of a CMDB for everything, and I am not sure we want to do that.

It's important to recognize that NetBox's function is not to serve as a corporate directory. Our goal here is to efficiently convey contact information for a subset of existing object types within NetBox and nothing more.

In the interest of moving forward with this feature, I'd like to propose an implementation. First, we would introduce a new Contact model within the tenancy app, with the following fields:

• Name
• Title
• Address
• Phone number
• Email
• Comments

Because we want to be able to reuse contacts among objects, and because we want the ability to associate multiple contacts with an object, it makes sense to model these as many-to-many relationships with an interim "through" model indicating the nature of the relationship. Although not the best-performing option, this will grant us the greatest amount of flexibility.

Then, there's the open question of which NetBox models can have contacts associated with them. We could take a more liberal approach and enable contact assignment for all primary and organizational models (essentially the "meat" of NetBox). However, we also need to bear in mind the imposed overhead, particularly because we're dealing with many-to-many relationships: Each relationships between the Contact model and another model effects a new SQL table to track the M2M assignments. There are performance implications for the REST API as well, if we decide to return associated contacts for each object.

[tb-killa]

One idea would be:
add Contacts and Contact-Group Model.
Contacts would be Persons like Jeremy mentioned. For another easier way it would be great if Contacts also selectable Users from NetBox.
Contact-Groups are Groups who could be Named and who could be filled with needing Contacts.
For the best affort it would be great if we could assign Contacts and or Groups to All needing Models inside Netbox.

[jeremystretch]

So, I burned an entire day on this, but here's what I ended up doing:

• ContactGroup - Self-nesting organizational model for contacts (similar to SiteGroup)
• Contact - Represents a reusable set of contact info (name, title, phone, email, etc.)
• ContactRole - Functional role of the relationship between a contact and an object in NetBox
• ContactAssignment - Binds a mapping of object, contact, and role; also conveys priority

Contact assignments employ generic foreign keys (similar to image attachments) to avoid imposing too much overhead. This allows us to assign contacts to a bunch of models without needing to create additional tables.

I'm sure it still needs a bit of cleanup, but I feel this is a reasonable approach that fulfills all four use cases I identified in my previous comment. The biggest hindrance at the moment is probably that you can't create and assign a contact in one go: the contact must be created first, and can then be assigned to objects. I'm sure we can accommodate a more convenient workflow, but it may require refactoring the generic ObjectEditView first.

[DanSheps]

And here I was thinking I was going to take care of contact objects. Guess you beat me too it...