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 users to override the search scope #4485

New Issue
Closed
opened 2025-12-29 18:36:31 +01:00 by adam · 4 comments
adam commented 2025-12-29 18:36:31 +01:00
Owner
Copy Link

Originally created by @cpmills1975 on GitHub (Jan 21, 2021).

Environment

  • Python version: 2.10.3
  • NetBox version: 3.9

Proposed Functionality

Allow users/administrators to configure the scope of the search functionality in NetBox

In an ideal world, users will be able to access an advanced search page where they can select specific models to be included within the scope of the search. These choices will be saved as part of the user preferences in the same way as table columns now are. Ideally, the administrator/application administrator of the NetBox instance will be able to configure the default selection of models to be included via the configuration.py file. The main search box in the header would use the user's choice of scope, defaulting to the scope set by the administrator in configuration.py, when performing searches.

I see that the search scope is already defined as a constant in constants.py, so effectively this FR is seeking to move this to configuration.py and/or provide a front end allowing individual users to modify it (and store the selection as a preference item) for themselves as and when they wish.

Use Case

My users want to be able to search for inventory items and devices via one screen. Currently, because inventory items are not included in the search scope (due to efficiency concerns I believe), given an asset tag, they need first to search for this in the main search box and, assuming it returns no results, search again for it in the inventory items page. This is unwieldy. While it is understandable that some instances of NetBox will have many many thousands of inventory items and therefore searching them all every time is inefficient, this should be for the application administrator and/or the user to decide based on the types and quantities of data stored in their own instance.

Database Changes

Storage of search preferences for the user?

External Dependencies

None.

Originally created by @cpmills1975 on GitHub (Jan 21, 2021). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please start a discussion instead: https://github.com/netbox-community/netbox/discussions NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 2.10.3 * NetBox version: 3.9 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Allow users/administrators to configure the scope of the search functionality in NetBox In an ideal world, users will be able to access an advanced search page where they can select specific models to be included within the scope of the search. These choices will be saved as part of the user preferences in the same way as table columns now are. Ideally, the administrator/application administrator of the NetBox instance will be able to configure the default selection of models to be included via the configuration.py file. The main search box in the header would use the user's choice of scope, defaulting to the scope set by the administrator in configuration.py, when performing searches. I see that the search scope is already defined as a constant in constants.py, so effectively this FR is seeking to move this to configuration.py and/or provide a front end allowing individual users to modify it (and store the selection as a preference item) for themselves as and when they wish. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case My users want to be able to search for inventory items and devices via one screen. Currently, because inventory items are not included in the search scope (due to efficiency concerns I believe), given an asset tag, they need first to search for this in the main search box and, assuming it returns no results, search again for it in the inventory items page. This is unwieldy. While it is understandable that some instances of NetBox will have many many thousands of inventory items and therefore searching them all every time is inefficient, this should be for the application administrator and/or the user to decide based on the types and quantities of data stored in their own instance. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes Storage of search preferences for the user? <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None.
adam added the type: featurepending closurestatus: under review labels 2025-12-29 18:36:31 +01:00
adam closed this issue 2025-12-29 18:36:31 +01:00
adam commented 2025-12-29 18:36:31 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Feb 21, 2021):

Desperate for the ability to search inventory items in a seamless way, I've done some work on this and, when I've tidied up my code, I'd like to submit a PR that implements this. Would one of the admins consider assigning this to me?

I've reworked the search functionality such that the search box that appears on the home page now has a (hidden until expanded) multi select field for object types field that defaults to all object types. The main /search page also has a multi select field for object types. If, through either of these forms, the user selects a custom set of object types, this is stored in their preferences for subsequent searches.

The search field in the nav bar has been refactored as a custom tag which includes a hidden obj_type field which again uses the user preference for object types to search. Using a hidden obj_type field, this form does not offer the ability for the user to change the set of types being searched, so I've changed the placeholder text to 'Quick Search' to differentiate the capabilities here.

In all cases, if the user has not performed a search resulting in a saved preference, or clears the multi select obj_type field, the search is performed against all types currently defined in netbox/constants.py. I've added inventoryitem to this list as searching for inventory items in a seamless way is the whole reason I embarked on this piece of work!

I'll attach screenshots to demo the reworked search fields in the coming days.

@cpmills1975 commented on GitHub (Feb 21, 2021): Desperate for the ability to search inventory items in a seamless way, I've done some work on this and, when I've tidied up my code, I'd like to submit a PR that implements this. Would one of the admins consider assigning this to me? I've reworked the search functionality such that the search box that appears on the home page now has a (hidden until expanded) multi select field for object types field that defaults to all object types. The main /search page also has a multi select field for object types. If, through either of these forms, the user selects a custom set of object types, this is stored in their preferences for subsequent searches. The search field in the nav bar has been refactored as a custom tag which includes a hidden obj_type field which again uses the user preference for object types to search. Using a hidden obj_type field, this form does not offer the ability for the user to change the set of types being searched, so I've changed the placeholder text to 'Quick Search' to differentiate the capabilities here. In all cases, if the user has not performed a search resulting in a saved preference, or clears the multi select obj_type field, the search is performed against all types currently defined in netbox/constants.py. I've added inventoryitem to this list as searching for inventory items in a seamless way is the whole reason I embarked on this piece of work! I'll attach screenshots to demo the reworked search fields in the coming days.
adam commented 2025-12-29 18:36:31 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Feb 27, 2021):

Here are some screen shots of my proposed changes:

  • A reworked 'home page' search bar now has a drop down button for 'advanced search' functionality:
    Screenshot 2021-02-26 at 21 20 32

  • When clicked, the search form shows a larger multi-select widget for object types to include in the search:
    Screenshot 2021-02-26 at 21 20 46

  • Because the object type preference is stored, and the space available in the nav bar doesn't lend itself to allowing an object type field, the placeholder text is changed to "Quick Search" to give an indication of it's limitation. The object types field is actually present, but is hidden due to lack of space:
    Screenshot 2021-02-26 at 21 21 03

  • The search results page showing results for the selected object types and the search form moved to the sidebar where the user can amend the search query and/or select different object types to include in the search.
    Screenshot 2021-02-26 at 21 21 37

  • The last used object type selection is stored in user preferences. The preference is used to pre-populate the object type in the search forms. On the home page or /search page forms, the object type field is visible, in the quick search bar the field is in a hidden div.
    Screenshot 2021-02-26 at 21 39 23

At this point, it would be helpful @DanSheps or @jeremystretch if you could give me a steer on whether this FR is likely to be accepted or not. I have a PR ready to go.

@cpmills1975 commented on GitHub (Feb 27, 2021): Here are some screen shots of my proposed changes: * A reworked 'home page' search bar now has a drop down button for 'advanced search' functionality: ![Screenshot 2021-02-26 at 21 20 32](https://user-images.githubusercontent.com/1878544/109363622-eb157400-7884-11eb-9b78-2a83608a3a82.png) * When clicked, the search form shows a larger multi-select widget for object types to include in the search: ![Screenshot 2021-02-26 at 21 20 46](https://user-images.githubusercontent.com/1878544/109363686-0a140600-7885-11eb-8022-026b5c7055ed.png) * Because the object type preference is stored, and the space available in the nav bar doesn't lend itself to allowing an object type field, the placeholder text is changed to "Quick Search" to give an indication of it's limitation. The object types field is actually present, but is hidden due to lack of space: ![Screenshot 2021-02-26 at 21 21 03](https://user-images.githubusercontent.com/1878544/109363770-40518580-7885-11eb-8426-391a0b9248ed.png) * The search results page showing results for the selected object types and the search form moved to the sidebar where the user can amend the search query and/or select different object types to include in the search. ![Screenshot 2021-02-26 at 21 21 37](https://user-images.githubusercontent.com/1878544/109364033-cf5e9d80-7885-11eb-9cc6-0668452dfb69.png) * The last used object type selection is stored in user preferences. The preference is used to pre-populate the object type in the search forms. On the home page or /search page forms, the object type field is visible, in the quick search bar the field is in a hidden div. ![Screenshot 2021-02-26 at 21 39 23](https://user-images.githubusercontent.com/1878544/109364268-4d22a900-7886-11eb-988d-91726feface6.png) At this point, it would be helpful @DanSheps or @jeremystretch if you could give me a steer on whether this FR is likely to be accepted or not. I have a PR ready to go.
adam commented 2025-12-29 18:36:32 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 21, 2021):

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.

@github-actions[bot] commented on GitHub (Jul 21, 2021): 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:36:32 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 20, 2021):

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.

@github-actions[bot] commented on GitHub (Aug 20, 2021): 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: under review 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#4485
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?