Allow a site to be a member of multiple site groups

[shatt79]

NetBox version

v3.3.4

Feature type

New functionality

Proposed functionality

Currently, a site can only belong to a single site group. I'd like to be able to add a site to multiple groups.

Use case

This would allow for better organization, filtering, and searching when you have sites that could belong to multiple groups.

For example, I have site groups such as "HFC Nodes" and "Commercial-Single Tenant", etc. In most cases, nodes are outdoors and have their own location. However, there are many cases where we place a node inside a building that we already have classified into another group. If searching for all sites and devices in the HFC Node group, these nodes that could be inside other locations would not appear in the results.

Database changes

I don't know enough about the database schema to know what kinds of changes would be required.

External dependencies

No response

[hagbarddenstore]

Use tagsOn 28 Oct 2022, at 15:16, shatt79 ***@***.***> wrote: NetBox version v3.3.4 Feature type New functionality Proposed functionality Currently, a site can only belong to a single site group. I'd like to be able to add a site to multiple groups. Use case This would allow for better organization, filtering, and searching when you have sites that could belong to multiple groups. For example, I have site groups such as "HFC Nodes" and "Commercial-Single Tenant", etc. In most cases, nodes are outdoors and have their own location. However, there are many cases where we place a node inside a building that we already have classified into another group. If searching for all sites and devices in the HFC Node group, these nodes that could be inside other locations would not appear in the results. Database changes I don't know enough about the database schema to know what kinds of changes would be required. External dependencies No response —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sleepinggenius2]

I would also really like to have this feature.

I agree that OP's use case sounds like it could be better implemented through tags, but my use case goes beyond what OP included and would not be able to be implemented that way. I would be happy to open a separate FR instead, but I have included more details below if we are willing to include additional use cases within the scope of this one.

The filtering abilities would be great, but the even more useful place to have this would be for VLAN groups. We have quite a few VLANs that span multiple sites to deliver MEF services to customers. It would be amazing to be able to create a group for each customer and scope it to just the sites where they have service. That would ideally include being able to assign a tenant to the VLAN group, as you can with just the VLAN itself today, but I understand that would be a separate FR. As we may have multiple customers receiving service at a given site, being able to include it in multiple groups would be needed to support this model. The implementation of #9627 would make this use case even better. Today we have tried just assigning a VLAN group to an entire market (using the Region model), but that has caused issues for customers with long haul circuits and we occasionally run into duplicate IDs being used for separate L2 domains within the same market, so they cannot be put into the same group.

We have a similar scenario with just internal departments where different groups of sites mean different things to different teams and they may not always be grouped the same. For example, the teams that serve a given site may have different service areas and would each want to create a group for just the sites that they support. If this feature is implemented, then it would also be nice to be able to assign a tenant to a site group to be able to help distinguish them and to be able to use within permissions (like you can only view or edit sites that are part of a group that belongs to the tenant for your department).

Except for the VLAN group scoping use case, I think the rest can be implemented through the use of custom fields to represent the relationships between objects, but I've found that it provides for a poor and often confusing user experience to try to explain using the similarly named custom fields and not the core model fields for what a user is trying to do, especially when the custom fields are below the fold. Hiding the core fields hasn't been a viable option, as they are still required to support the inbuilt functionality of things like VLAN group scoping in some scenarios.

[jeremystretch]

I'm going to decline this proposal because there's value in being able to succinctly convey the single group to which a site belongs, and removing this ability would disrupt many other use cases. There are numerous other mechanisms available by which sites can be categorized, including tags (as mentioned), region, tenant, and custom fields.