Allow plugin models to use trace() #8163

Closed
opened 2025-12-29 20:33:16 +01:00 by adam · 1 comment
Owner

Originally created by @rixx on GitHub (Jun 5, 2023).

NetBox version

v3.5.2

Feature type

Change to existing functionality

Proposed functionality

It would be cool if plugin models could be part of the "trace" mechanic. As I understand it (and please correct me if I'm wrong), the major obstacle towards that, from a plugin author's perspective, is that CABLE_TERMINATION_MODELS is hard-coded, so that plugin models cannot provide a CableTermination even when they inherit and implement CabledObjectModel or PathEndpoint interfaces.

(I realise I'm probably missing other problems with this suggested implementation, this is just the route I took with a prototype, and where I finally failed.)

Use case

Allow non-standard netbox objects from plugins to be traceable.

Database changes

External dependencies

Originally created by @rixx on GitHub (Jun 5, 2023). ### NetBox version v3.5.2 ### Feature type Change to existing functionality ### Proposed functionality It would be cool if plugin models could be part of the "trace" mechanic. As I understand it (and please correct me if I'm wrong), the major obstacle towards that, from a plugin author's perspective, is that `CABLE_TERMINATION_MODELS` is hard-coded, so that plugin models cannot provide a `CableTermination` even when they inherit and implement `CabledObjectModel` or `PathEndpoint` interfaces. (I realise I'm probably missing other problems with this suggested implementation, this is just the route I took with a prototype, and where I finally failed.) ### Use case Allow non-standard netbox objects from plugins to be traceable. ### Database changes - ### External dependencies -
adam added the type: feature label 2025-12-29 20:33:16 +01:00
adam closed this issue 2025-12-29 20:33:16 +01:00
Author
Owner

@jeremystretch commented on GitHub (Jun 5, 2023):

I'm afraid what you're describing would not be feasible to implement due to the complexities of the cable tracing system. And given that we have so few people today interested in even pursuing bugs in the existing cable tracing functionality, I'm not open to introducing yet more complexity. I have to decline your proposal us untenable at this time.

@jeremystretch commented on GitHub (Jun 5, 2023): I'm afraid what you're describing would not be feasible to implement due to the complexities of the cable tracing system. And given that we have so few people today interested in even pursuing bugs in the existing cable tracing functionality, I'm not open to introducing yet more complexity. I have to decline your proposal us untenable at this time.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#8163