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

Allow strict filtering of cables by tenant #4108

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

Originally created by @m384wwn on GitHub (Sep 17, 2020).

Environment

  • Python version: 3.8.2
  • NetBox version: 2.9.3

Proposed Functionality

On the cables page, when you filter by tenant(s) you will get a list of cables which connect on both sides to the selected tenant(s) as well as one side only. I am proposing, perhaps a checkbox next to the Tenant filter that says "strict". When enabled it will only show cables which connect on both sides to the selected tenant(s).

Use Case

We often have facilities which some of the inter-room/site, cabling is managed by another company (tenant). We always provide patch cables to their patch panels but never the other way around. We also keep track of their cabling for troubleshooting and so that things 'connect' in netbox.

We can currently generate a list of our cables (as we patch to their panels) but we can't generate a list of their cables.

Database Changes

none

External Dependencies

none

Originally created by @m384wwn on GitHub (Sep 17, 2020). ### Environment * Python version: 3.8.2 * NetBox version: 2.9.3 ### Proposed Functionality On the cables page, when you filter by tenant(s) you will get a list of cables which connect on both sides to the selected tenant(s) as well as one side only. I am proposing, perhaps a checkbox next to the Tenant filter that says "strict". When enabled it will only show cables which connect on both sides to the selected tenant(s). ### Use Case We often have facilities which some of the inter-room/site, cabling is managed by another company (tenant). We always provide patch cables to their patch panels but never the other way around. We also keep track of their cabling for troubleshooting and so that things 'connect' in netbox. We can currently generate a list of our cables (as we patch to their panels) but we can't generate a list of their cables. ### Database Changes none ### External Dependencies none
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 18:33:10 +01:00
adam closed this issue 2025-12-29 18:33:10 +01:00
adam commented 2025-12-29 18:33:10 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Sep 26, 2020):

I feel this is somewhat related in spirit to #4944. I get your use case but it seems very specific and requires us to implement a type of filtering logic we have never done before.

Perhaps we could allow separate filters for both the A and B sides of the termination.

@lampwins commented on GitHub (Sep 26, 2020): I feel this is somewhat related in spirit to #4944. I get your use case but it seems very specific and requires us to implement a type of filtering logic we have never done before. Perhaps we could allow separate filters for both the A and B sides of the termination.
adam commented 2025-12-29 18:33:10 +01:00
Author
Owner
Copy Link

@m384wwn commented on GitHub (Sep 28, 2020):

separate filters for both the A and B sides of the termination

Sounds like that would also achieve the same result, even gives a bit more specificity.

@m384wwn commented on GitHub (Sep 28, 2020): > separate filters for both the A and B sides of the termination Sounds like that would also achieve the same result, even gives a bit more specificity.
adam commented 2025-12-29 18:33:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 14, 2020):

The major impediment to implementing this (even for a specific side; A or B) is that the termination fields are GenericForeignKeys which can point to (currently) nine different models. Tenancy is determined by referencing device__tenant for device components, whereas circuit__tenant is used for circuit terminations. Additionally, PowerFeed has no concept of tenancy.

I'm marking this as needs owner in case someone wants to dig into it and see if they can come up with something clever. Otherwise, it's probably not going to be implemented.

@jeremystretch commented on GitHub (Oct 14, 2020): The major impediment to implementing this (even for a specific side; A or B) is that the termination fields are GenericForeignKeys which can point to (currently) nine different models. Tenancy is determined by referencing `device__tenant` for device components, whereas `circuit__tenant` is used for circuit terminations. Additionally, PowerFeed has no concept of tenancy. I'm marking this as `needs owner` in case someone wants to dig into it and see if they can come up with something clever. Otherwise, it's probably not going to be implemented.
adam commented 2025-12-29 18:33:11 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Nov 28, 2020):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Nov 28, 2020): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:33:11 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 13, 2020):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Dec 13, 2020): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: needs owner 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#4108
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?