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

Move providers to organization #10608

New Issue
Closed
opened 2025-12-29 21:33:38 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:33:38 +01:00
Owner
Copy Link

Originally created by @mlebreuil on GitHub (Jan 5, 2025).

NetBox version

v4.1.10

Feature type

Change to existing functionality

Triage priority

N/A

Proposed functionality

Move the "Providers" MenuGroup to the ORGANIZATION_MENU.
Move the related class and update the related path.

Use case

This allows to use the same model for more than simply circuits.
For the netbox-contract plugin I had to create another model to extend the concept to other types of providers: maintenance, license, service providers. At the same time, I was asked to make it possible to link contracts to circuit providers. This makes the code convoluted and, for the user experience this solution is not ideal.
More generally speaking, this opens possibilities for other plugins.

Database changes

no database change required originally.

External dependencies

none

Originally created by @mlebreuil on GitHub (Jan 5, 2025). ### NetBox version v4.1.10 ### Feature type Change to existing functionality ### Triage priority N/A ### Proposed functionality Move the "Providers" MenuGroup to the ORGANIZATION_MENU. Move the related class and update the related path. ### Use case This allows to use the same model for more than simply circuits. For the netbox-contract plugin I had to create another model to extend the concept to other types of providers: maintenance, license, service providers. At the same time, I was asked to make it possible to link contracts to circuit providers. This makes the code convoluted and, for the user experience this solution is not ideal. More generally speaking, this opens possibilities for other plugins. ### Database changes no database change required originally. ### External dependencies none
adam added the type: feature label 2025-12-29 21:33:38 +01:00
adam closed this issue 2025-12-29 21:33:39 +01:00
adam commented 2025-12-29 21:33:39 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Jan 5, 2025):

I support this. Having the same model in different plugins could lead to confusion. In netbox-inventory there's a similar situation with the Supplier model, which is also just an external entity providing a service. Whether the external entity provides a virtual service (circuit), fulfills a contract, or delivers hardware shouldn't make much difference.

I volunteer to work on this FR if accepted.

@alehaa commented on GitHub (Jan 5, 2025): I support this. Having the same model in different plugins could lead to confusion. In netbox-inventory there's a similar situation with the `Supplier` model, which is also just an external entity providing a service. Whether the external entity provides a virtual service (circuit), fulfills a contract, or delivers hardware shouldn't make much difference. I volunteer to work on this FR if accepted.
adam commented 2025-12-29 21:33:39 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jan 6, 2025):

In our environment, we also use the Provider/ProviderAccount models through custom fields on the Site and Location models to track property owners and co-location providers. That gets a little weird when we are provided a service identifier, as the only way to really track that today is through a "Circuit" and not through a more general model. I know Service is already used in the IPAM application, so I'm not sure what else to call it, as that's the name that is normally used.

@sleepinggenius2 commented on GitHub (Jan 6, 2025): In our environment, we also use the Provider/ProviderAccount models through custom fields on the Site and Location models to track property owners and co-location providers. That gets a little weird when we are provided a service identifier, as the only way to really track that today is through a "Circuit" and not through a more general model. I know Service is already used in the IPAM application, so I'm not sure what else to call it, as that's the name that is normally used.
adam commented 2025-12-29 21:33:40 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Jan 9, 2025):

Manufacturers also exist under DCIM, what are your thoughts on including this under the same umbrella model?

@tyler-8 commented on GitHub (Jan 9, 2025): Manufacturers also exist under DCIM, what are your thoughts on including this under the same umbrella model?
adam commented 2025-12-29 21:33:40 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jan 9, 2025):

I think it makes sense to include Manufacturers in the same umbrella model, just as long as they can be filtered to only include that type where they are referenced today. I know that is an issue I've seen with the object selector, where it completely overrides any set query_params, but I'm only seeing regular select boxes used for Manufacturer fields today, so I don't think that will be an issue there. Interestingly, the Provider field on Circuits does use an object selector today, so that one might have an issue with an umbrella model. Looking at the object selector for that in more detail, there seems to be something weird going on with the fields that are being displayed and I don't really see a compelling reason for that one to be using an object selector in the first place. Some way to use the object selector and still enforce query_params would be amazing in general, but a separate FR.

@sleepinggenius2 commented on GitHub (Jan 9, 2025): I think it makes sense to include Manufacturers in the same umbrella model, just as long as they can be filtered to only include that type where they are referenced today. I know that is an issue I've seen with the object selector, where it completely overrides any set `query_params`, but I'm only seeing regular select boxes used for Manufacturer fields today, so I don't think that will be an issue there. Interestingly, the Provider field on Circuits does use an object selector today, so that one might have an issue with an umbrella model. Looking at the object selector for that in more detail, there seems to be something weird going on with the fields that are being displayed and I don't really see a compelling reason for that one to be using an object selector in the first place. Some way to use the object selector and still enforce `query_params` would be amazing in general, but a separate FR.
adam commented 2025-12-29 21:33:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 20, 2025):

This allows to use the same model for more than simply circuits.

The Provider model has always been intended for use solely in the context of circuits. If you need to represent some organization for other purposes (e.g. maintenance, licenses, etc.) you'll need to introduce a separate model for that use case.

@jeremystretch commented on GitHub (Feb 20, 2025): > This allows to use the same model for more than simply circuits. The Provider model has always been intended for use solely in the context of circuits. If you need to represent some organization for other purposes (e.g. maintenance, licenses, etc.) you'll need to introduce a separate model for that use case.
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 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#10608
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?