Object ownership, tenancy and allowing multiples of. #1874

New Issue

adam · 2025-12-29T17:19:58+01:00

adam commented

2025-12-29 17:19:58 +01:00

Originally created by @LukeDRussell on GitHub (Jul 26, 2018).

Issue type

[x] Feature request
[ ] Bug report
[ ] Documentation
[ ] Housekeeping

Environment

Python version: 3.6
NetBox version: always latest stable

Description

Carrying on conversation from NTC Slack netbox channel, more appropriate here.

inet.0

Has there been any interest/discussion around being able to have multiple tenants assigned to a device/site etc?

LukeRussell:

We're interested enough we implemented it internally, but we are keen to push it upstream.

jstretch:

here's my take on multitenancy:
tenancy in NetBox is intended to represent that an object belongs to a particular entity (tenant)
when you find yourself wanting to assign an object to multiple tenants, you're probably not indicating ownership, but rather dependency (edited)
e.g. device X is assigned to tenants A, B, and C, because there are some resources on device X (prefixes, VLANs, etc.) which belong to these tenants
in this case, you're using the device tenancy as a shortcut for those other relationships
you're also duplicating data which is not validated by any means. for example, there is nothing to say that tenant A actually has any objects on device X, or that tenant D does not. it's completely arbitrary
therefore, I think it makes more sense to device a method for returning all tenants which have a resource related to a given object, rather than manually and unreliably defining the additional relationships
of course, that's relatively expensive to do in bulk
at any rate, the model in NetBox applies to ownership, not dependency, which are two different relationships that I don't want to conflate
in the absence of a more programmatic approach, I suggest using tags (v2.4) to identify dependencies on objects. you can very easily create tags like customer:abc123 and assign them to whatever objects

So fundamentally I agree that ownership != dependency. They are two different concepts. My main contention could be considered semantics, but I believe it's significant enough to raise here.

In my mind, my "tenant" is an individual or group who rents, consumes or uses an asset that I own, usually in exchange for some form of compensation. As you put it, they "depend" on my asset. I own a house that is tenanted by 1 family, and I own an apartment block that is tenanted by many families. I still own both assets, but different relationship types exist in each case.

"Owner" means the actual legal owner of an asset, while "Tenant" refers to the user of the asset.

In our case as a network operator we "own" the vast majority of the network equipment we operate. However, the vast majority of those assets are "tenanted" by multiple customers. I can also imagine cases where managed service providers operate equipment that is both owned and tenanted by a customer, alongside equipment that is owned by the MSP but tenanted by the customer. There are likely many other combination scenarios.

In every context I've experienced in IT when we talk about tenants and multi-tenancy, we are referring to some sort of shared infrastructure, platform or software that is used by many different customers. For example, Cisco's ACI and Juniper's Contrail both refer to tenant as a separate group of users with distinct and isolated infrastructure.

Here is my rough proposal:

Rename the existing "Tenant" object to "Owner". Keep 1toM to object relationships to physical objects (Region, Site, Rack, Device). Documentation to emphasise this means the owner of the asset.
Add a new primary object "Tenant" that supports MtoM object relationships to most (all?) of the other object types (Region, Site, Rack, Device, VRF, Prefix, VLAN, IP, carriage, etc, etc).
Use the Reports feature to validate business rules (confirm that for every tenant on device X, there is a prefix configured).

I'm on the fence about the best place for carriage and region, they could be both

e.g. device X is assigned to tenants A, B, and C, because there are some resources on device X (prefixes, VLANs, etc.) which belong to these tenants
in this case, you're using the device tenancy as a shortcut for those other relationships
you're also duplicating data which is not validated by any means. for example, there is nothing to say that tenant A actually has any objects on device X, or that tenant D does not. it's completely arbitrary
therefore, I think it makes more sense to device a method for returning all tenants which have a resource related to a given object, rather than manually and unreliably defining the additional relationships
of course, that's relatively expensive to do in bulk

Regarding the above, I think it makes more sense to have a "Top-Down" approach, as opposed to "Bottom-Up". By that I mean, business requirements will determine the site data. Base on site and tenant data (where it is, how many users it needs to support, what availability is needed, what carriages are available), we determine devices, racks, VRFs, and prefixes.

Hypothetically a site could be "owned" by customer "A", and the router is "owned" by me as the SP. That site could be tenanted by both tenants "A" and "B". I don't want to rely on iterating through Prefixes on that router to determine which tenants are dependant on the site or router. I want a tenancy list explicitly defined that can be verified or even populated in Netbox by non-technical people (Service Managers, Project Managers, etc). That tenant list will be used to decide what Prefixes should be on the router.

Originally created by @LukeDRussell on GitHub (Jul 26, 2018). ### Issue type [x] Feature request  [ ] Bug report  [ ] Documentation  [ ] Housekeeping  ### Environment * Python version: 3.6 * NetBox version: always latest stable ### Description _Carrying on conversation from NTC Slack netbox channel, more appropriate here._ inet.0 > Has there been any interest/discussion around being able to have multiple tenants assigned to a device/site etc? LukeRussell: > We're interested enough we implemented it internally, but we are keen to push it upstream. jstretch: > here's my take on multitenancy: tenancy in NetBox is intended to represent that an object _belongs_ to a particular entity (tenant) when you find yourself wanting to assign an object to multiple tenants, you're probably not indicating ownership, but rather dependency (edited) e.g. device X is assigned to tenants A, B, and C, because there are some resources on device X (prefixes, VLANs, etc.) which belong to these tenants in this case, you're using the device tenancy as a shortcut for those other relationships you're also duplicating data which is not validated by any means. for example, there is nothing to say that tenant A actually has any objects on device X, or that tenant D does not. it's completely arbitrary therefore, I think it makes more sense to device a method for returning all tenants which have a resource related to a given object, rather than manually and unreliably defining the additional relationships of course, that's relatively expensive to do in bulk > at any rate, the model in NetBox applies to ownership, not dependency, which are two different relationships that I don't want to conflate in the absence of a more programmatic approach, I suggest using tags (v2.4) to identify dependencies on objects. you can very easily create tags like `customer:abc123` and assign them to whatever objects So fundamentally I agree that ownership != dependency. They are two different concepts. My main contention could be considered semantics, but I believe it's significant enough to raise here. In my mind, my "tenant" is an individual or group who rents, consumes or uses an asset that I own, usually in exchange for some form of compensation. As you put it, they "depend" on _my_ asset. I own a house that is tenanted by 1 family, and I own an apartment block that is tenanted by many families. I still own both assets, but different relationship types exist in each case. "Owner" means the actual legal owner of an asset, while "Tenant" refers to the user of the asset. In our case as a network operator we "own" the vast majority of the network equipment we operate. However, the vast majority of those assets are "tenanted" by multiple customers. I can also imagine cases where managed service providers operate equipment that is both owned and tenanted by a customer, alongside equipment that is owned by the MSP but tenanted by the customer. There are likely many other combination scenarios. In every context I've experienced in IT when we talk about tenants and multi-tenancy, we are referring to some sort of shared infrastructure, platform or software that is used by many different customers. For example, Cisco's ACI and Juniper's Contrail both refer to tenant as a separate group of users with distinct and isolated infrastructure. *Here is my rough proposal*: 1) Rename the existing "Tenant" object to "Owner". Keep 1toM to object relationships to physical objects (Region, Site, Rack, Device). Documentation to emphasise this means the owner of the asset. 2) Add a new primary object "Tenant" that supports MtoM object relationships to most (all?) of the other object types (Region, Site, Rack, Device, VRF, Prefix, VLAN, IP, carriage, etc, etc). 3) Use the Reports feature to validate business rules (confirm that for every tenant on device X, there is a prefix configured). _I'm on the fence about the best place for carriage and region, they could be both_ > e.g. device X is assigned to tenants A, B, and C, because there are some resources on device X (prefixes, VLANs, etc.) which belong to these tenants in this case, you're using the device tenancy as a shortcut for those other relationships you're also duplicating data which is not validated by any means. for example, there is nothing to say that tenant A actually has any objects on device X, or that tenant D does not. it's completely arbitrary therefore, I think it makes more sense to device a method for returning all tenants which have a resource related to a given object, rather than manually and unreliably defining the additional relationships of course, that's relatively expensive to do in bulk Regarding the above, I think it makes more sense to have a "Top-Down" approach, as opposed to "Bottom-Up". By that I mean, business requirements will determine the site data. Base on site and tenant data (where it is, how many users it needs to support, what availability is needed, what carriages are available), we determine devices, racks, VRFs, and prefixes. Hypothetically a site could be "owned" by customer "A", and the router is "owned" by me as the SP. That site could be tenanted by both tenants "A" and "B". I don't want to rely on iterating through Prefixes on that router to determine which tenants are dependant on the site or router. I want a tenancy list explicitly defined that can be verified or even populated in Netbox by non-technical people (Service Managers, Project Managers, etc). That tenant list will be used to decide what Prefixes should be on the router.

adam closed this issue

2025-12-29 17:19:58 +01:00

adam commented

2025-12-29 17:19:58 +01:00

@mmahacek commented on GitHub (Jul 27, 2018):

I agree with @jeremystretch 's description of owner vs tenant. We are a K12 organization that acts as an ISP for other school districts. In our Netbox deployment, we are using the Tenant designation to imply who owns the record. We are entering in sites that belong to a different organization, but have devices/circuits/IPs/etc at those sites that belong to us, and the current Tenant field works well for us.

Given we have many sites that are occupied by multiple organizations, I could see a benefit in breaking Owner and Tenant apart at a site level, but think it may get tedious to carry that down to device or IP/prefix level.

Edit: We do have a use case where, as an ISP, we have a device that connects other districts to us. The individual SFP units technically have different tenants, which currently are indicated through the description field of an inventory item.

@mmahacek commented on GitHub (Jul 27, 2018): I agree with @jeremystretch 's description of owner vs tenant. We are a K12 organization that acts as an ISP for other school districts. In our Netbox deployment, we are using the Tenant designation to imply who owns the record. We are entering in sites that belong to a different organization, but have devices/circuits/IPs/etc at those sites that belong to us, and the current Tenant field works well for us. Given we have many sites that are occupied by multiple organizations, I could see a benefit in breaking Owner and Tenant apart at a site level, but think it may get tedious to carry that down to device or IP/prefix level. Edit: We do have a use case where, as an ISP, we have a device that connects other districts to us. The individual SFP units technically have different tenants, which currently are indicated through the description field of an inventory item.

adam commented

2025-12-29 17:19:59 +01:00

@mmahacek commented on GitHub (Jul 27, 2018):

In @LukeRussell 's analogy about house/vs apartment, while a house (typically) has one tenant and one owner, the apartment block has an owner but the block itself does not necessarily have a tenant. The apartment block is split into units that are then are assigned to different tenants (Site with one device that is a chassis with each slot's device having a different tenant).

@mmahacek commented on GitHub (Jul 27, 2018): In @LukeRussell 's analogy about house/vs apartment, while a house (typically) has one tenant and one owner, the apartment block has an owner but the block itself does not necessarily have a tenant. The apartment block is split into units that are then are assigned to different tenants (Site with one device that is a chassis with each slot's device having a different tenant).

adam commented

2025-12-29 17:19:59 +01:00

@LukeDRussell commented on GitHub (Jul 30, 2018):

I grant that the house / apartment analogy has limits, like all analogies.

@mmahacek If the Netbox UI swapped the word "Tenant" with "Owner" what affect would that have on your use case?

Given we have many sites that are occupied by multiple organizations, I could see a benefit in breaking Owner and Tenant apart at a site level, but think it may get tedious to carry that down to device or IP/prefix level.

I think you actually have the same use case as us. I think it makes sense to seperate object types along logical or physical boundary. VRFs, Prefixes, IPs, would all go in the new Tenant object without an Owner. While physical sites, racks and devices would have both an Owner and a list of Tenants.

@LukeDRussell commented on GitHub (Jul 30, 2018): I grant that the house / apartment analogy has limits, like all analogies. @mmahacek If the Netbox UI swapped the word "Tenant" with "Owner" what affect would that have on your use case? > Given we have many sites that are occupied by multiple organizations, I could see a benefit in breaking Owner and Tenant apart at a site level, but think it may get tedious to carry that down to device or IP/prefix level. I think you actually have the same use case as us. I think it makes sense to seperate object types along logical or physical boundary. VRFs, Prefixes, IPs, would all go in the new Tenant object without an Owner. While physical sites, racks and devices would have both an Owner and a list of Tenants.

adam commented

2025-12-29 17:19:59 +01:00

@mmahacek commented on GitHub (Jul 30, 2018):

Just swapping the words Tenant and Owner wouldn't have an effect as we are treating them the same now. Thinking about this over the weekend, I would only want to assign one tenant/owner on any record, whether it is a site, device, prefix, IP, etc. What would be beneficial would be a view that would automatically show any other related tenants. An example would be if you select a site, the view would show any other tenants attached to racks, devices, prefixes, IPs, VLANs, that were assigned to that site. A site assigned to "Tenant A" and a device at that site assigned to "Tenant B". The view would show A as the owner and B as a related tenant, indicating that tenant relies on some sort of resource at that site.
Basically, any views for multiple tenants would be auto-generated based on related records rather than manually being assigned. This wouldn't have any back end changes as it would just be a front end addition to view the data.

@mmahacek commented on GitHub (Jul 30, 2018): Just swapping the words Tenant and Owner wouldn't have an effect as we are treating them the same now. Thinking about this over the weekend, I would only want to assign one tenant/owner on any record, whether it is a site, device, prefix, IP, etc. What would be beneficial would be a view that would automatically show any other related tenants. An example would be if you select a site, the view would show any other tenants attached to racks, devices, prefixes, IPs, VLANs, that were assigned to that site. A site assigned to "Tenant A" and a device at that site assigned to "Tenant B". The view would show A as the owner and B as a related tenant, indicating that tenant relies on some sort of resource at that site. Basically, any views for multiple tenants would be auto-generated based on related records rather than manually being assigned. This wouldn't have any back end changes as it would just be a front end addition to view the data.

adam commented

2025-12-29 17:19:59 +01:00

@LukeDRussell commented on GitHub (Jul 30, 2018):

Except that is the exact recursion case I was talking about when referring to a top-down approach. If we treat "Tenant" and "Owner" to mean the same thing we are limiting Netbox's capability to represent the intended state of the network.

This Issue is exactly about removing the conflation of "ownership" with "dependance". The current "Tenant" term is being used to describe both.

While you might consider it tedium to assign ownership and tenancy separately, I expect we can make it as optional as the current Tenant object.

@LukeDRussell commented on GitHub (Jul 30, 2018): Except that is the exact recursion case I was talking about when referring to a top-down approach. If we treat "Tenant" and "Owner" to mean the same thing we are limiting Netbox's capability to represent the intended state of the network. This Issue is exactly about _removing_ the conflation of "ownership" with "dependance". The current "Tenant" term is being used to describe both. While you might consider it tedium to assign ownership and tenancy separately, I expect we can make it as optional as the current Tenant object.

adam commented

2025-12-29 17:20:00 +01:00

@jeremystretch commented on GitHub (Jul 30, 2018):

Rename the existing "Tenant" object to "Owner".

I'm not going to alter the existing functionality of the tenancy feature. It's already well established and it would be unreasonable to switch terminology and API endpoint solely because you want to re-purpose the name for something else.

Add a new primary object "Tenant" that supports MtoM object relationships to most (all?) of the other object types

This would introduce ten additional database tables (one per model) solely for tracking these relationships. And reiterating my earlier point, in many cases you are merely duplicating the representation of relationships which already exist. For example, if a tenant is said be dependent on a site because it has a device present there, we can already query for that via the device-to-site relationship.

Use the Reports feature to validate business rules (confirm that for every tenant on device X, there is a prefix configured).

Reports are great for validating whether the data in NetBox conforms to organizational policy (e.g. each ToR switch should have two uplinks connected.) They are not a substitute for validation of data being entered into NetBox. This must be accomplished through the models at time of entry.

I don't want to rely on iterating through Prefixes on that router to determine which tenants are dependant on the site or router.

But that is precisely how dependency on an object is determined. You're trying to implement a shortcut around this to say only that Tenant A is dependent on Device X. Well, why is that? What resources belonging to Tenant A are present on Device X? Why not just define them and avoid the redundancy altogether?

@jeremystretch commented on GitHub (Jul 30, 2018): > Rename the existing "Tenant" object to "Owner". I'm not going to alter the existing functionality of the tenancy feature. It's already well established and it would be unreasonable to switch terminology and API endpoint solely because you want to re-purpose the name for something else. > Add a new primary object "Tenant" that supports MtoM object relationships to most (all?) of the other object types This would introduce ten additional database tables (one per model) solely for tracking these relationships. And reiterating my earlier point, in many cases you are merely duplicating the representation of relationships which already exist. For example, if a tenant is said be dependent on a site because it has a device present there, we can already query for that via the device-to-site relationship. > Use the Reports feature to validate business rules (confirm that for every tenant on device X, there is a prefix configured). Reports are great for validating whether the data in NetBox conforms to organizational policy (e.g. each ToR switch should have two uplinks connected.) They are _not_ a substitute for validation of data being entered into NetBox. This must be accomplished through the models at time of entry. > I don't want to rely on iterating through Prefixes on that router to determine which tenants are dependant on the site or router. But that is precisely how dependency on an object is determined. You're trying to implement a shortcut around this to say only that Tenant A is dependent on Device X. Well, why is that? What resources belonging to Tenant A are present on Device X? Why not just define them and avoid the redundancy altogether?

adam commented

2025-12-29 17:20:00 +01:00

@mmahacek commented on GitHub (Jul 30, 2018):

I totally agree with Jeremy's position on this. If I wanted to see a view of tenants assigned to a site's devices/IP, this would fall under a custom implementation either via a report or through the API. I would not expect this built in as it would get fairly intensive to iterate through all the possible related data models.

@mmahacek commented on GitHub (Jul 30, 2018): I totally agree with Jeremy's position on this. If I wanted to see a view of tenants assigned to a site's devices/IP, this would fall under a custom implementation either via a report or through the API. I would not expect this built in as it would get fairly intensive to iterate through all the possible related data models.

adam commented

2025-12-29 17:20:00 +01:00

@LukeDRussell commented on GitHub (Jul 31, 2018):

I don't want to rely on iterating through Prefixes on that router to determine which tenants are dependant on the site or router.

But that is precisely how dependency on an object is determined. You're trying to implement a shortcut around this to say only that Tenant A is dependent on Device X. Well, why is that? What resources belonging to Tenant A are present on Device X? Why not just define them and avoid the redundancy altogether?

Because dependency is determined by customer requirements through Service Managers, Service Delivery Managers and all those other not-quite-technical roles. Not IP addresses.

It's not a shortcut, it's actually a data quality check to ensure that technical implementations match up with business intent. We can't safely assume that a customer isn't dependant on a site because some network technician hasn't tied a prefix in a VRF to the device on said site. Conversely, just because there is a prefix in a VRF attached to a device at some site, doesn't mean that the customer is actually dependant on that site.

This request keeps coming up again and again as a feature for Netbox. There is clearly demand from larger network operators.

I've been trying to come up with a solution that will meet the needs of many Service Providers, not just us, and the best solutions all come back to permitting many Tenants per site (or rack or device, all requests I've seen relate to physical objects only).

Another reasonable possibility we've explored is to add more data types for custom fields, specifically TypedMultipleChoice, TypedChoice and MultipleChoice. This capability is generally applicable and would increase data accuracy by linking choices to existing tables. An example is a custom field called "Dependant Customers" with a TypedMultipleChoice data type pointing to the Tenant List.

When you see this in the UI though it gets confusing as to who owns the site and which tenants are at the site. It also makes it hard when you think through generating device configs from data in Netbox.

To reiterate I am trying to come up with a palatable solution that meets the requirements of a good section of Netbox's potential users. That is, Sites and Devices need to support 0, 1 or many Tenants. Possibly Racks as well. Existing users will lose nothing, they can continue to use Tenants as before. Heck, we could probably even make it the default that multiple tenant capability is turned off by default, with an option to turn on in the admin portal.

The only downside I can see is there will certainly be more tables to support the M to M relationships, but it's completely normal for any reasonably complex application to need M to M tables. The only workload for @jeremystretch will be to review and agree to an implementation design and to merge once done. We have the development capability in house to implement and support this feature for the foreseeable future.

@LukeDRussell commented on GitHub (Jul 31, 2018): >> I don't want to rely on iterating through Prefixes on that router to determine which tenants are dependant on the site or router. > But that is precisely how dependency on an object is determined. You're trying to implement a shortcut around this to say only that Tenant A is dependent on Device X. Well, why is that? What resources belonging to Tenant A are present on Device X? Why not just define them and avoid the redundancy altogether? Because dependency is determined by customer requirements through Service Managers, Service Delivery Managers and all those other not-quite-technical roles. Not IP addresses. It's not a shortcut, it's actually a data quality check to ensure that technical implementations match up with business intent. We can't safely assume that a customer isn't dependant on a site because some network technician hasn't tied a prefix in a VRF to the device on said site. Conversely, just because there is a prefix in a VRF attached to a device at some site, doesn't mean that the customer is actually dependant on that site. This request keeps coming up again and again as a feature for Netbox. There is clearly demand from larger network operators. I've been trying to come up with a solution that will meet the needs of many Service Providers, not just us, and the best solutions all come back to permitting many Tenants per site (or rack or device, all requests I've seen relate to physical objects only). Another reasonable possibility we've explored is to add more data types for custom fields, specifically `TypedMultipleChoice`, `TypedChoice` and `MultipleChoice`. This capability is generally applicable and would increase data accuracy by linking choices to existing tables. An example is a custom field called "Dependant Customers" with a TypedMultipleChoice data type pointing to the Tenant List. When you see this in the UI though it gets confusing as to who owns the site and which tenants are at the site. It also makes it hard when you think through generating device configs from data in Netbox. To reiterate I am trying to come up with a palatable solution that meets the requirements of a good section of Netbox's potential users. That is, Sites and Devices need to support 0, 1 or many Tenants. Possibly Racks as well. Existing users will lose nothing, they can continue to use Tenants as before. Heck, we could probably even make it the default that multiple tenant capability is turned off by default, with an option to turn on in the admin portal. The only downside I can see is there will certainly be more tables to support the M to M relationships, but it's completely normal for any reasonably complex application to need M to M tables. The only workload for @jeremystretch will be to review and agree to an implementation design and to merge once done. We have the development capability in house to implement _and support_ this feature for the foreseeable future.

adam commented

2025-12-29 17:20:00 +01:00

@mmahacek commented on GitHub (Jul 31, 2018):

Your use case is definitely more complex that ours. While I can see value in this for some users, it isn't something that I would expect to use in our specific deployment.
I am interested in your idea of other custom field types. Having a MultipleChoice field type would be a huge benefit. Has this been discussed on another issue?

@mmahacek commented on GitHub (Jul 31, 2018): Your use case is definitely more complex that ours. While I can see value in this for some users, it isn't something that I would expect to use in our specific deployment. I am interested in your idea of other custom field types. Having a `MultipleChoice` field type would be a **huge** benefit. Has this been discussed on another issue?

adam commented

2025-12-29 17:20:00 +01:00

@jeremystretch commented on GitHub (Jul 31, 2018):

Because dependency is determined by customer requirements through Service Managers, Service Delivery Managers and all those other not-quite-technical roles. Not IP addresses.

Based on what? What is the determining factor for saying "tenant X needs to be associated with this site?" If it's not a metric directly related to network resources, why do you want to store it in NetBox?

It sounds like you're wanting to open up NetBox's scope well beyond its role as an IPAM/DCIM application. While I appreciate that you're willing to commit to the additional development, I'm still not clear on exactly how this fits inside NetBox's feature set.

@jeremystretch commented on GitHub (Jul 31, 2018): > Because dependency is determined by customer requirements through Service Managers, Service Delivery Managers and all those other not-quite-technical roles. Not IP addresses. Based on what? What is the determining factor for saying "tenant X needs to be associated with this site?" If it's not a metric directly related to network resources, why do you want to store it in NetBox? It sounds like you're wanting to open up NetBox's scope well beyond its role as an IPAM/DCIM application. While I appreciate that you're willing to commit to the additional development, I'm still not clear on exactly how this fits inside NetBox's feature set.

adam commented

2025-12-29 17:20:01 +01:00

@LukeDRussell commented on GitHub (Aug 1, 2018):

The determining factor is whether there is a business requirement or not. How that requirement is communicated isn't important, just that business requirements are documented somewhere and at some point there is a mapping requirement and network intent.

I can certainly appreciate that "business requirement" may be considered outside the current scope of NetBox. Perhaps that information could also go in a CRM or an Asset management system. However, the same thing could be said about Tenancy in general the way it stands, and to a lesser extent - Regions.

I would argue that Tenancy way back in 1.4 already expanded the original scope of Netbox.

My opinion is this Feature Request is not expanding the scope further, it's improving the depth of capability for an existing feature.

@LukeDRussell commented on GitHub (Aug 1, 2018): The determining factor is whether there is a business requirement or not. How that requirement is communicated isn't important, just that business requirements are documented somewhere and at some point there is a mapping requirement and network intent. I can certainly appreciate that "business requirement" may be considered outside the current scope of NetBox. Perhaps that information could also go in a CRM or an Asset management system. However, the same thing could be said about Tenancy in general the way it stands, and to a lesser extent - Regions. I would argue that [Tenancy](https://netbox.readthedocs.io/en/latest/data-model/tenancy/) way back in [1.4](https://github.com/digitalocean/netbox/releases/tag/v1.4.0) already expanded the original scope of Netbox. My opinion is this Feature Request is not expanding the scope further, it's improving the depth of capability for an existing feature.

adam commented

2025-12-29 17:20:01 +01:00

@jeremystretch commented on GitHub (Nov 6, 2018):

This has been open for three months with no further discussion. Going to close this out as there doesn't seem to be much community interest.

@jeremystretch commented on GitHub (Nov 6, 2018): This has been open for three months with no further discussion. Going to close this out as there doesn't seem to be much community interest.

adam commented

2025-12-29 17:20:01 +01:00

@LukeDRussell commented on GitHub (Nov 7, 2018):

Plenty of people regularly ask for this in the Slack channel, and are usually not satisfied with the response.

@jeremystretch Are you against Many to Many tables for some reason? If you can answer that, it will help us figure out what to try to merge upstream, and where we can go our own way.

@LukeDRussell commented on GitHub (Nov 7, 2018): Plenty of people regularly ask for this in the Slack channel, and are usually not satisfied with the response. @jeremystretch Are you against Many to Many tables for some reason? If you can answer that, it will help us figure out what to try to merge upstream, and where we can go our own way.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#1874