Cable path trace without PathEndpoint #6653

New Issue

adam · 2025-12-29T19:43:31+01:00

adam commented

2025-12-29 19:43:31 +01:00

Originally created by @DanSheps on GitHub (Jul 14, 2022).

NetBox version

3.3.0

Feature type

Change to existing functionality

Proposed functionality

Currently, path traces are only available from concrete path start/end points (Interfaces, Console, etc). The proposal would be to allow cable path traces to be initiated from the following:

PathEndpoints
FrontPorts with no link (the corresponding rear-port may or may not have a link)

This proposal won't cover the following:

RearPorts
FrontPorts with a link (the assumption would be that it should be initiated further "upstream")

The goal with this FR will be to change the cablepath and pathendpoint/passthrough port model as little as possible. To that end, there are a couple of options:

Do not cache the path but instead simply initiate a trace from the origin point to the destination when tracing from a FrontPort
Update the model to allow CablePaths as a valid origin for FrontPort and allow the path to be cached on FrontPorts
Update the model as above but remove caching of CablePaths

Use case

Currently, you cannot trace your current cable plant unless it is connected to a PathEndpoint. There is a use case to be able to trace from un-attached front ports to assist in managing a cabling plant that isn't nessacarily connected to interfaces or other PathEndpoints:

Splice documentation
Fiber management/repair
Patch repair (Location start/endpoint determination)

The big one here is obviously splice documentation for building out a fiber network and using NetBox as the planning tool.

This is a often desired feature, requested in the following FR's or BR's:

#8277 (3 "thumbs up" on comments)
Widgets move when clicking the netbox home button (#7951)
#7294 / #7279 (not directly a BR on point but does include attempting to initiate from a front port)
#5857 (Multiple comments about missing feature)
#5863 (Multiple comments about missing feature)

Database changes

Depending on the options chose, there may be required database updates but non yet decided.

External dependencies

No response

Originally created by @DanSheps on GitHub (Jul 14, 2022). ### NetBox version 3.3.0 ### Feature type Change to existing functionality ### Proposed functionality Currently, path traces are only available from concrete path start/end points (Interfaces, Console, etc). The proposal would be to allow cable path traces to be initiated from the following: * PathEndpoints * FrontPorts with no link (the corresponding rear-port may or may not have a link) This proposal won't cover the following: * RearPorts * FrontPorts with a link (the assumption would be that it should be initiated further "upstream") The goal with this FR will be to change the cablepath and pathendpoint/passthrough port model as little as possible. To that end, there are a couple of options: * Do not cache the path but instead simply initiate a trace from the origin point to the destination when tracing from a FrontPort * Update the model to allow CablePaths as a valid origin for FrontPort and allow the path to be cached on FrontPorts * Update the model as above but remove caching of CablePaths ### Use case Currently, you cannot trace your current cable plant unless it is connected to a PathEndpoint. There is a use case to be able to trace from un-attached front ports to assist in managing a cabling plant that isn't nessacarily connected to interfaces or other PathEndpoints: * Splice documentation * Fiber management/repair * Patch repair (Location start/endpoint determination) The big one here is obviously splice documentation for building out a fiber network and using NetBox as the planning tool. This is a often desired feature, requested in the following FR's or BR's: * #8277 (3 "thumbs up" on comments) * #7951 * #7294 / #7279 (not directly a BR on point but does include attempting to initiate from a front port) * #5857 (Multiple comments about missing feature) * #5863 (Multiple comments about missing feature) ### Database changes Depending on the options chose, there may be required database updates but non yet decided. ### External dependencies _No response_

adam added the type: feature pending closure status: under review labels 2025-12-29 19:43:31 +01:00

adam closed this issue

2025-12-29 19:43:31 +01:00

adam commented

2025-12-29 19:43:32 +01:00

@DanSheps commented on GitHub (Jul 14, 2022):

Updating the view to allow a manual trace if no cable path exists may be the simplest option. It would need the least amount of effort of simply updating the views, SVG rendering and editing the "from_origin" to do this:

    @classmethod
    def from_origin(cls, terminations, manual=True):
        """
        Create a new CablePath instance as traced from the given termination objects. These can be any object to which a
        Cable or WirelessLink connects (interfaces, console ports, circuit termination, etc.). All terminations must be
        of the same type and must belong to the same parent object.
        """
        from circuits.models import CircuitTermination

        path = []
        position_stack = []
        is_complete = False
        is_active = True
        is_split = False

        logger.debug(terminations)

        if len(terminations) == 1 terminations[0].link == None and isinstance(terminations[0], FrontPort) and manual:
            path.append([
                object_to_path_node(t) for t in terminations
            ])
            rear_ports = RearPort.objects.filter(
                pk__in=[t.rear_port_id for t in terminations]
            )
            terminations = rear_ports

This would allow generating the cable trace on demand.

Edit: Diving into this more, there may be more required work for the SVG portion, however that should not be too difficult

@DanSheps commented on GitHub (Jul 14, 2022): Updating the view to allow a manual trace if no cable path exists may be the simplest option. It would need the least amount of effort of simply updating the views, SVG rendering and editing the "from_origin" to do this: ```python @classmethod def from_origin(cls, terminations, manual=True): """ Create a new CablePath instance as traced from the given termination objects. These can be any object to which a Cable or WirelessLink connects (interfaces, console ports, circuit termination, etc.). All terminations must be of the same type and must belong to the same parent object. """ from circuits.models import CircuitTermination path = [] position_stack = [] is_complete = False is_active = True is_split = False logger.debug(terminations) if len(terminations) == 1 terminations[0].link == None and isinstance(terminations[0], FrontPort) and manual: path.append([ object_to_path_node(t) for t in terminations ]) rear_ports = RearPort.objects.filter( pk__in=[t.rear_port_id for t in terminations] ) terminations = rear_ports ``` This would allow generating the cable trace on demand. Edit: Diving into this more, there may be more required work for the SVG portion, however that should not be too difficult

adam commented

2025-12-29 19:43:32 +01:00

@jeremystretch commented on GitHub (Jul 14, 2022):

3.3.0-dev

v3.3.0-dev is not a release. This needs to be tied to either a v3.2.x release or, more practically, one of the v3.3 releases when they become available. I can tell you that we're not going to take on any new work on cabling outside the scope of #9102 during the beta period, as it has taken me months of work just to resolve #9102. This may be something we can revisit for v3.4.

Currently, you cannot trace your current cable plant unless it is connected to a PathEndpoint. This is a often desired feature, requested in the following FR's or BR's:

I appreciate that related FRs have been opened, however this still needs to cite at least one specific, concrete use case that people can refer back to when discussing the proposal's implementation.

Do not cache the path but instead simply initiate a trace from the origin point to the destination when tracing from a FrontPort

Some brief consideration should reveal that this is a nonstarter. Without cached paths, it would be impossible to efficiently list the connected endpoint(s) of each interface on a device.

@jeremystretch commented on GitHub (Jul 14, 2022): > 3.3.0-dev v3.3.0-dev is not a release. This needs to be tied to either a v3.2.x release or, more practically, one of the v3.3 releases when they become available. I can tell you that we're not going to take on any new work on cabling outside the scope of #9102 during the beta period, as it has taken me months of work just to resolve #9102. This may be something we can revisit for v3.4. > Currently, you cannot trace your current cable plant unless it is connected to a PathEndpoint. This is a often desired feature, requested in the following FR's or BR's: I appreciate that related FRs have been opened, however this still needs to cite at least one specific, concrete use case that people can refer back to when discussing the proposal's implementation. > Do not cache the path but instead simply initiate a trace from the origin point to the destination when tracing from a FrontPort Some brief consideration should reveal that this is a nonstarter. Without cached paths, it would be impossible to efficiently list the connected endpoint(s) of each interface on a device.

adam commented

2025-12-29 19:43:32 +01:00

@DanSheps commented on GitHub (Jul 14, 2022):

v3.3.0-dev is not a release. This needs to be tied to either a v3.2.x release or, more practically, one of the v3.3 releases when they become available. I can tell you that we're not going to take on any new work on cabling outside the scope of #9102 during the beta period, as it has taken me months of work just to resolve #9102. This may be something we can revisit for v3.4.

Wasn't planning on taking this on in the beta period. I definitely think we can put this off until 3.4. I moved it to 3.2 for now and will update it once 3.3 is released.

I appreciate that related FRs have been opened, however this still needs to cite at least one specific, concrete use case that people can refer back to when discussing the proposal's implementation.

Updated it, sometimes I don't finish my thoughts cleanly.

Some brief consideration should reveal that this is a nonstarter. Without cached paths, it would be impossible to efficiently list the connected endpoint(s) of each interface on a device.

Sorry, I don't think I was clear, this was referring to the FrontPorts with no existing CablePath. Since there is no existing CablePath, there is no link peer. Instead, this would simply allow the initation of a manual trace of the path.

@DanSheps commented on GitHub (Jul 14, 2022): > v3.3.0-dev is not a release. This needs to be tied to either a v3.2.x release or, more practically, one of the v3.3 releases when they become available. I can tell you that we're not going to take on any new work on cabling outside the scope of #9102 during the beta period, as it has taken me months of work just to resolve #9102. This may be something we can revisit for v3.4. Wasn't planning on taking this on in the beta period. I definitely think we can put this off until 3.4. I moved it to 3.2 for now and will update it once 3.3 is released. > I appreciate that related FRs have been opened, however this still needs to cite at least one specific, concrete use case that people can refer back to when discussing the proposal's implementation. Updated it, sometimes I don't finish my thoughts cleanly. > Some brief consideration should reveal that this is a nonstarter. Without cached paths, it would be impossible to efficiently list the connected endpoint(s) of each interface on a device. Sorry, I don't think I was clear, this was referring to the FrontPorts with no existing CablePath. Since there is no existing CablePath, there is no link peer. Instead, this would simply allow the initation of a manual trace of the path.

adam commented

2025-12-29 19:43:33 +01:00

@tnn2 commented on GitHub (Aug 10, 2022):

Hi! I cobbled together a PoC which can trace FrontPorts and RearPorts without PathEndpoints. This is implementation does not cover all corner cases (Netbox codebase is unfamiliar to me) and is not suitable to merge as-is so I'll just link the repo instead of sending a pull request.
Maybe someone more familiar with the code can use it as a starting point for a proper PR. Our field engineers need this feature somewhat urgently and people might be interested in having an interim solution until a proper solution exists.

@tnn2 commented on GitHub (Aug 10, 2022): Hi! I cobbled together a PoC which can trace FrontPorts and RearPorts without PathEndpoints. This is implementation does not cover all corner cases (Netbox codebase is unfamiliar to me) and is not suitable to merge as-is so I'll just [link the repo](https://github.com/tnn2/netbox/tree/issue9718) instead of sending a pull request. Maybe someone more familiar with the code can use it as a starting point for a proper PR. Our field engineers need this feature somewhat urgently and people might be interested in having an interim solution until a proper solution exists.

adam commented

2025-12-29 19:43:33 +01:00

@DanSheps commented on GitHub (Aug 23, 2022):

@tnn2 I have yet to review the POC but I will when I have time. Thanks for giving it a go and I will let you know.

@DanSheps commented on GitHub (Aug 23, 2022): @tnn2 I have yet to review the POC but I will when I have time. Thanks for giving it a go and I will let you know.

adam commented

2025-12-29 19:43:33 +01:00

@github-actions[bot] commented on GitHub (Oct 23, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Oct 23, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 19:43:33 +01:00

@github-actions[bot] commented on GitHub (Feb 8, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Feb 8, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 19:43:34 +01:00

@hans-peter123 commented on GitHub (Feb 9, 2023):

Hello together,
we would like to document a fiber optic installation in our village.
For this it would be very helpful if we could track cables even if they don't have an installed endpoint yet.
Would be awesome if this feature request would be implemented.

@hans-peter123 commented on GitHub (Feb 9, 2023): Hello together, we would like to document a fiber optic installation in our village. For this it would be very helpful if we could track cables even if they don't have an installed endpoint yet. Would be awesome if this feature request would be implemented.

adam commented

2025-12-29 19:43:34 +01:00

@LHBL2003 commented on GitHub (Feb 9, 2023):

I am also in favour of this function. It doesn't matter whether it's multiple bridged fibre optic lines or fully documented network outlets. I don't want to create a dummy device for each room so that I can track everything from the patch panel to the outlet. :)

Even devices without a heart deserve good documentation ;)

@LHBL2003 commented on GitHub (Feb 9, 2023): I am also in favour of this function. It doesn't matter whether it's multiple bridged fibre optic lines or fully documented network outlets. I don't want to create a dummy device for each room so that I can track everything from the patch panel to the outlet. :) Even devices without a heart deserve good documentation ;)

adam commented

2025-12-29 19:43:34 +01:00

@tolasws commented on GitHub (Feb 10, 2023):

Im also searching on how to get this possible, is there any info about will it be possible in next editions?

@tolasws commented on GitHub (Feb 10, 2023): Im also searching on how to get this possible, is there any info about will it be possible in next editions?

adam commented

2025-12-29 19:43:34 +01:00

@jeremystretch commented on GitHub (Mar 17, 2023):

Despite the amount of interest in this idea, the discussion has unfortunately not yielded a proposed implementation, so I'm going to close this FR. I encourage anyone who would like to brainstorm on potential implementations to open a discussion to share their ideas and collaborate with others. Once a functioning implementation has been fleshed out, it can be proposed in a new feature request.

@jeremystretch commented on GitHub (Mar 17, 2023): Despite the amount of interest in this idea, the discussion has unfortunately not yielded a proposed implementation, so I'm going to close this FR. I encourage anyone who would like to brainstorm on potential implementations to open a [discussion](https://github.com/netbox-community/netbox/discussions/new/choose) to share their ideas and collaborate with others. Once a functioning implementation has been fleshed out, it can be proposed in a new feature request.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#6653