Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow more than 1 Account per provider #9047

Closed
ryanmerolle opened this issue Apr 6, 2022 · 8 comments · Fixed by #12057
Closed

Allow more than 1 Account per provider #9047

ryanmerolle opened this issue Apr 6, 2022 · 8 comments · Fixed by #12057
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@ryanmerolle
Copy link
Contributor

ryanmerolle commented Apr 6, 2022

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

@ryanmerolle ryanmerolle added the type: feature Introduction of new functionality to the application label Apr 6, 2022
@jeremystretch jeremystretch added the status: needs milestone Awaiting prioritization for inclusion with a future NetBox release label Apr 7, 2022
@bryanward-net
Copy link

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.

@ryanmerolle
Copy link
Contributor Author

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
Copy link
Contributor Author

might be nice to add to 3.5

@ryanmerolle ryanmerolle added this to the v3.5 milestone Jan 12, 2023
@ryanmerolle ryanmerolle removed the status: needs milestone Awaiting prioritization for inclusion with a future NetBox release label Feb 15, 2023
@jbakklund
Copy link

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.

@kkthxbye-code
Copy link
Contributor

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

@ryanmerolle
Copy link
Contributor Author

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.

@DanSheps DanSheps self-assigned this Mar 6, 2023
@DanSheps DanSheps added the status: accepted This issue has been accepted for implementation label Mar 6, 2023
@ITJamie
Copy link
Contributor

ITJamie commented 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

@ryanmerolle
Copy link
Contributor Author

+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.

DanSheps added a commit that referenced this issue Mar 21, 2023
DanSheps added a commit that referenced this issue Mar 21, 2023
DanSheps added a commit that referenced this issue Mar 22, 2023
DanSheps added a commit that referenced this issue Mar 22, 2023
DanSheps added a commit that referenced this issue Mar 22, 2023
DanSheps added a commit that referenced this issue Mar 24, 2023
DanSheps added a commit that referenced this issue Mar 24, 2023
DanSheps added a commit that referenced this issue Mar 24, 2023
DanSheps added a commit that referenced this issue Mar 28, 2023
jeremystretch added a commit that referenced this issue Mar 29, 2023
* #9047 - ProviderAccount

* #9047 - Move to new selector types

* #9047 - Re-introduce provider FK to Circuit model

* #9047 - Fix broken tests

* Misc cleanup

* Revert errant change

* Fix tests

* Update circuit filter form

---------

Co-authored-by: jeremystretch <jstretch@netboxlabs.com>
jeremystretch added a commit that referenced this issue Mar 29, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants