netbox icon indicating copy to clipboard operation
netbox copied to clipboard

Allow more than 1 Account per provider

Open ryanmerolle opened this issue 2 years ago • 2 comments

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) - optional
  • Account Number - 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

ryanmerolle avatar Apr 06 '22 03:04 ryanmerolle

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 avatar Aug 03 '22 13:08 bryanward-net

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 avatar Aug 03 '22 14:08 ryanmerolle

might be nice to add to 3.5

ryanmerolle avatar Dec 20 '22 03:12 ryanmerolle

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 avatar Feb 17 '23 11:02 jbakklund

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

kkthxbye-code avatar Feb 17 '23 11:02 kkthxbye-code

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 avatar Mar 04 '23 03:03 ryanmerolle

+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 avatar Mar 16 '23 17:03 ITJamie

+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 avatar Mar 16 '23 20:03 ryanmerolle