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

Allow more than 1 Account per provider #6301

New Issue
Closed
opened 2025-12-29 19:39:06 +01:00 by adam · 8 comments
adam commented 2025-12-29 19:39:06 +01:00
Owner
Copy Link

Originally created by @ryanmerolle on GitHub (Apr 6, 2022).

Originally assigned to: @DanSheps on GitHub.

NetBox version

v3.2.0

Feature type

New functionality

Proposed functionality

Create an account model allowing more than one account per provider. The model could include:

  • Account Name (where to track where account numbers result due to regional entities being different IE Network Client UK vs Network Client US for only billing/AP purposes) - mandatory
  • Account ID- mandatory
  • Account Description ( add any additional useful context) - optional

Use case

Sometimes providers require a different account and circuit id per region, sometimes your firm may have different billed entities per region for AP purposes and the provider cannot link the accounts all together, etc

Database changes

No response

External dependencies

No response

Originally created by @ryanmerolle on GitHub (Apr 6, 2022). Originally assigned to: @DanSheps on GitHub. ### NetBox version v3.2.0 ### Feature type New functionality ### Proposed functionality Create an account model allowing more than one account per provider. The model could include: - Account Name (where to track where account numbers result due to regional entities being different IE Network Client UK vs Network Client US for only billing/AP purposes) - mandatory - Account ID- mandatory - Account Description ( add any additional useful context) - optional ### Use case Sometimes providers require a different account and circuit id per region, sometimes your firm may have different billed entities per region for AP purposes and the provider cannot link the accounts all together, etc ### Database changes _No response_ ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:39:06 +01:00
adam closed this issue 2025-12-29 19:39:07 +01:00
adam commented 2025-12-29 19:39:07 +01:00
Author
Owner
Copy Link

@bryanward-net commented on GitHub (Aug 3, 2022):

I would ask for the ability to relate "Contact" objects to accounts, as each account may have a different admin/technical/stakeholder. An arbitrary number of Contacts should be allowed to relate to an Account (as there may be multiple stakeholders who need to be notified for outages, or an escalation path for technical contacts). The relation of a Contact to an Account should include a Contact Type (i.e. Billing, Technical, Landlord, etc.)

And just to explicitly say it, Circuits should then be related to an Account object instead of directly to a Provider.

@bryanward-net commented on GitHub (Aug 3, 2022): I would ask for the ability to relate "Contact" objects to accounts, as each account may have a different admin/technical/stakeholder. An arbitrary number of Contacts should be allowed to relate to an Account (as there may be multiple stakeholders who need to be notified for outages, or an escalation path for technical contacts). The relation of a Contact to an Account should include a Contact Type (i.e. Billing, Technical, Landlord, etc.) And just to explicitly say it, Circuits should then be related to an Account object instead of directly to a Provider.
adam commented 2025-12-29 19:39:07 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Aug 3, 2022):

I am not against a new account model because that does model real world usage. The challenge with this is the migrations and impact to users to remove the provider to circuit direct relationship.

@ryanmerolle commented on GitHub (Aug 3, 2022): I am not against a new account model because that does model real world usage. The challenge with this is the migrations and impact to users to remove the provider to circuit direct relationship.
adam commented 2025-12-29 19:39:08 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Dec 20, 2022):

might be nice to add to 3.5

@ryanmerolle commented on GitHub (Dec 20, 2022): might be nice to add to 3.5
adam commented 2025-12-29 19:39:08 +01:00
Author
Owner
Copy Link

@jbakklund commented on GitHub (Feb 17, 2023):

Ref @bryanward-net

And just to explicitly say it, Circuits should then be related to an Account object instead of directly to a Provider.

The Rack model could use a similar relation.

@jbakklund commented on GitHub (Feb 17, 2023): Ref @bryanward-net > And just to explicitly say it, Circuits should then be related to an Account object instead of directly to a Provider. The Rack model could use a similar relation.
adam commented 2025-12-29 19:39:08 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Feb 17, 2023):

@jbakklund - There's no relation between racks and providers. If you meant in a general sense, racks already have tenant group -> tenant.

@kkthxbye-code commented on GitHub (Feb 17, 2023): @jbakklund - There's no relation between racks and providers. If you meant in a general sense, racks already have tenant group -> tenant.
adam commented 2025-12-29 19:39:08 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Mar 4, 2023):

I think @jbakklund is talking about changing the rack model to relate to providers given some providers provide colocation services and telecom services. Its sort of a pain to duplicate data and leverage tenants or the facility field to signify a provider/landlord.

It is also a pain point with the netbox circuit maintenance plugin given it can be used to parse colocation provider maintenance that could impact specific site, and right now there is no easy way to model that relationship besides leveraging tenants where it does not always make sense.

Regardless, @jbakklund that would be a separate well thought out feature request.

@ryanmerolle commented on GitHub (Mar 4, 2023): I think @jbakklund is talking about changing the rack model to relate to providers given some providers provide colocation services and telecom services. Its sort of a pain to duplicate data and leverage tenants or the facility field to signify a provider/landlord. It is also a pain point with the netbox circuit maintenance plugin given it can be used to parse colocation provider maintenance that could impact specific site, and right now there is no easy way to model that relationship besides leveraging tenants where it does not always make sense. Regardless, @jbakklund that would be a separate well thought out feature request.
adam commented 2025-12-29 19:39:09 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Mar 16, 2023):

+1 to @ jbakklund's request.
(offtopic, some additional context)
Another example is that we may have racks in a cage in a DC. That cage is directly assigned to us and billed to us by the DC.
We may also have racks in a cage owned by an ISP or some other company in the same DC. In this case a tenant is still not exactly correct, from an operations POV etc its a completely different account/contacts/access process for those racks. than the rest of the objects in that site/dc

@ITJamie commented on GitHub (Mar 16, 2023): +1 to @ jbakklund's request. (offtopic, some additional context) Another example is that we may have racks in a cage in a DC. That cage is directly assigned to us and billed to us by the DC. We may also have racks in a cage owned by an ISP or some other company in the same DC. In this case a tenant is still not exactly correct, from an operations POV etc its a completely different account/contacts/access process for those racks. than the rest of the objects in that site/dc
adam commented 2025-12-29 19:39:09 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Mar 16, 2023):

+1 to @ jbakklund's request.
(offtopic, some additional context)
Another example is that we may have racks in a cage in a DC. That cage is directly assigned to us and billed to us by the DC.
We may also have racks in a cage owned by an ISP or some other company in the same DC. In this case a tenant is still not exactly correct, from an operations POV etc its a completely different account/contacts/access process for those racks. than the rest of the objects in that site/dc

Another off topic item. I’m not saying this is not necessarily needed or useful, but I’m say this is outside of the scope of this accepted FR. Please submit a Feature Request to address the problem you touched on.

@ryanmerolle commented on GitHub (Mar 16, 2023): > +1 to @ jbakklund's request. > (offtopic, some additional context) > Another example is that we may have racks in a cage in a DC. That cage is directly assigned to us and billed to us by the DC. > We may also have racks in a cage owned by an ISP or some other company in the same DC. In this case a tenant is still not exactly correct, from an operations POV etc its a completely different account/contacts/access process for those racks. than the rest of the objects in that site/dc Another off topic item. I’m not saying this is not necessarily needed or useful, but I’m say this is outside of the scope of this accepted FR. Please submit a Feature Request to address the problem you touched on.
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 status: accepted 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#6301
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?