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

Add primary key to global search #8214

New Issue
Closed
opened 2025-12-29 20:33:52 +01:00 by adam · 11 comments
adam commented 2025-12-29 20:33:52 +01:00
Owner
Copy Link

Originally created by @DanSheps on GitHub (Jun 19, 2023).

NetBox version

3.5.3

Feature type

Data model extension

Proposed functionality

Add the primary key as an additional indexed field to be searched.

Use case

With the ability to move cables, we are currently using the primary key to track cables. However, the primary key is currently not searchable.

Database changes

Add the primary key for each model as a search field

External dependencies

None

Originally created by @DanSheps on GitHub (Jun 19, 2023). ### NetBox version 3.5.3 ### Feature type Data model extension ### Proposed functionality Add the primary key as an additional indexed field to be searched. ### Use case With the ability to move cables, we are currently using the primary key to track cables. However, the primary key is currently not searchable. ### Database changes Add the primary key for each model as a search field ### External dependencies None
adam added the type: feature label 2025-12-29 20:33:52 +01:00
adam closed this issue 2025-12-29 20:33:52 +01:00
adam commented 2025-12-29 20:33:52 +01:00
Author
Owner
Copy Link

@martinum4 commented on GitHub (Jun 19, 2023):

This might also close https://github.com/netbox-community/netbox/issues/12705 if implemented for all searches

@martinum4 commented on GitHub (Jun 19, 2023): This might also close https://github.com/netbox-community/netbox/issues/12705 if implemented for *all* searches
adam commented 2025-12-29 20:33:53 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 20, 2023):

I knew I saw it somewhere, thanks for that @martinum4

@DanSheps commented on GitHub (Jun 20, 2023): I knew I saw it somewhere, thanks for that @martinum4
adam commented 2025-12-29 20:33:53 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jun 20, 2023):

Do you mean add the pk to the filtersets or to the global search? Because I don't think it makes sense for the global search.

@kkthxbye-code commented on GitHub (Jun 20, 2023): Do you mean add the pk to the filtersets or to the global search? Because I don't think it makes sense for the global search.
adam commented 2025-12-29 20:33:53 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 21, 2023):

To the global search (and filterset too IMO,, I can see both).

@DanSheps commented on GitHub (Jun 21, 2023): To the global search (and filterset too IMO,, I can see both).
adam commented 2025-12-29 20:33:53 +01:00
Author
Owner
Copy Link

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

So searching for e.g. 123 would return all objects with that primary key? I can't imagine that being useful.

@jeremystretch commented on GitHub (Jun 21, 2023): So searching for e.g. 123 would return all objects with that primary key? I can't imagine that being useful.
adam commented 2025-12-29 20:33:53 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 21, 2023):

I guess the shorter PK's would cause a problem, especially is searching for an addrerss or similar with the same number sequence. For example, my PK's for devices are in the 5 digits. My cables are almost 6 digits now.

Not sure how feasible it is, but perhaps only make it use it as a search key when there is no label/name associated with the item? The only thing is that brings with it it's own set of issues in that you don't have a consistently defined behaviour.

@DanSheps commented on GitHub (Jun 21, 2023): I guess the shorter PK's would cause a problem, especially is searching for an addrerss or similar with the same number sequence. For example, my PK's for devices are in the 5 digits. My cables are almost 6 digits now. Not sure how feasible it is, but perhaps only make it use it as a search key when there is no label/name associated with the item? The only thing is that brings with it it's own set of issues in that you don't have a consistently defined behaviour.
adam commented 2025-12-29 20:33:54 +01:00
Author
Owner
Copy Link

@martinum4 commented on GitHub (Jun 21, 2023):

Maybe implement it context-specific then, e.g. when there are object types selected search in those object types, this would solve aforementioned #12705 and might help with other selectors (e.h. PK of site when in the dialogue for adding a new device)

I don't really share the inconsistency-concern, since unnamed devices are displayed with the PK in the elevations views, so it should be possible to search a displayed value.
Especially for people new to NetBox the current behavior seems counterintuitive IMHO.

@martinum4 commented on GitHub (Jun 21, 2023): Maybe implement it context-specific then, e.g. when there are object types selected search in those object types, this would solve aforementioned #12705 and might help with other selectors (e.h. PK of site when in the dialogue for adding a new device) I don't really share the inconsistency-concern, since unnamed devices are displayed with the PK in the elevations views, so it should be possible to search a displayed value. Especially for people new to NetBox the current behavior seems counterintuitive IMHO.
adam commented 2025-12-29 20:33:54 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 21, 2023):

I think like @kkthxbye-code mentioined, #12705 would actually be fixed at the filterset level.

That does nothing with my desire to be able to type 343334 into the Global Search field and be brought to Cable with PK 343334.

We could do like I said, put in the label/name or if both are none where it shows the PK then we add that to the search it would be added if it were a label (for example, displaying a cable with PK 343334 it is shown in the UI as "#343334"), so we could add that to the search index as the label.

Maybe that is the ultimate FR here, in that it is not so much the PK be added but where we use the PK as a label/name when those fields are null we add that to the Search Index

@DanSheps commented on GitHub (Jun 21, 2023): I think like @kkthxbye-code mentioined, #12705 would actually be fixed at the filterset level. That does nothing with my desire to be able to type 343334 into the Global Search field and be brought to Cable with PK 343334. We could do like I said, put in the label/name or if both are none where it shows the PK then we add that to the search it would be added if it were a label (for example, displaying a cable with PK 343334 it is shown in the UI as "#343334"), so we could add that to the search index as the label. Maybe that is the ultimate FR here, in that it is not so much the PK be added but where we use the PK as a label/name when those fields are null we add that to the Search Index
adam commented 2025-12-29 20:33:54 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jun 22, 2023):

We could do like I said, put in the label/name or if both are none where it shows the PK then we add that to the search it would be added if it were a label (for example, displaying a cable with PK 343334 it is shown in the UI as "#343334"), so we could add that to the search index as the label.

I really just think that if you choose to not have a label for a cable, or choose not to have a name for a device, it's because it's not inherently searchable and that it is not needed to search for it.

Let's say you stumble upon a cable in the datacenter and you want to see where it goes, wouldn't you search for the label that's on the cable? How do you get the primary key in that case? If there really is no label, wouldn't you follow it to one end and look up what it is connected to instead?

Same with a device, if it doesn't have a name, wouldn't you find it by going to the rack in netbox and looking at the position?

I guess I just don't understand the use case properly, could you explain more about what the actual workflow is here?

And lastly, I really don't think the primary key should be relied on by our users. It's inherently a backend thing imo. While probably unlikely, we could change the pk to something like an UUID in the future.

@kkthxbye-code commented on GitHub (Jun 22, 2023): > We could do like I said, put in the label/name or if both are none where it shows the PK then we add that to the search it would be added if it were a label (for example, displaying a cable with PK 343334 it is shown in the UI as "#343334"), so we could add that to the search index as the label. I really just think that if you choose to not have a label for a cable, or choose not to have a name for a device, it's because it's not inherently searchable and that it is not needed to search for it. Let's say you stumble upon a cable in the datacenter and you want to see where it goes, wouldn't you search for the label that's on the cable? How do you get the primary key in that case? If there really is no label, wouldn't you follow it to one end and look up what it is connected to instead? Same with a device, if it doesn't have a name, wouldn't you find it by going to the rack in netbox and looking at the position? I guess I just don't understand the use case properly, could you explain more about what the actual workflow is here? And lastly, I really don't think the primary key should be relied on by our users. It's inherently a backend thing imo. While probably unlikely, we could change the pk to something like an UUID in the future.
adam commented 2025-12-29 20:33:54 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Aug 25, 2023):

If that helps with the cable primary key use case, I created a little plugin to help with that:
https://github.com/jsenecal/netbox-cable-labels

@jsenecal commented on GitHub (Aug 25, 2023): If that helps with the cable primary key use case, I created a little plugin to help with that: https://github.com/jsenecal/netbox-cable-labels
adam commented 2025-12-29 20:33:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 13, 2023):

I'm going to close this out as it doesn't seem we've found any real justification for its implementation.

@jeremystretch commented on GitHub (Oct 13, 2023): I'm going to close this out as it doesn't seem we've found any real justification for its implementation.
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#8214
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?