Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Fields results in main Object search #6003

Closed
akballow opened this issue Mar 17, 2021 · 7 comments
Closed

Custom Fields results in main Object search #6003

akballow opened this issue Mar 17, 2021 · 7 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@akballow
Copy link

NetBox version

2.9.10

Feature type

Change to existing functionality

Proposed functionality

Right now I add custom fields like Device Owner Email in Devices or IP address Owner Email in IPAM. When you search in the custom field search box specifically it works, but If i wanted to search an email across all objects in the main search bar it does not find the emails in the custom fields. It would be nice to have the option for custom fields to return results from the main object search. It could be a check box to enable it.

Use case

Having common custom fields entries searchable across objects for a single search result instead of having to go into each object to search for it.

Database changes

No response

External dependencies

No response

@akballow akballow added the type: feature Introduction of new functionality to the application label Mar 17, 2021
@jeremystretch
Copy link
Member

This would be possible to implement in a primitive way by appending Q(custom_field_data__icontains=value) to the queryset for the search() method on custom field model filtersets. However, it would not behave the same as the individual custom field filters, which look at each individual custom field and apply the specified filtering logic (loose versus strict).

For example, suppose you have a custom field which stores phone numbers, which you intend to match only when a complete number matches. Taking the shotgun approach here would mean that objects would match on any matching set of digits, such as an AS number. This will likely result in frequent irrelevant search results, and dilutes the value of the global search function.

The alternative approach would be to retrieve the applicable custom fields for each model, and carefully extend the queryset filter to apply each one as intended, however this would introduce a substantial amount of overhead, especially considering that the global search currently defaults to querying for 19 different models. We might be better off deferring this feature until we can come up with a more robust search solution.

@candlerb
Copy link
Contributor

Some approaches in #1190 (comment)

@jeremystretch jeremystretch added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label May 21, 2021
@netbox-community netbox-community deleted a comment from qfaure Jul 12, 2021
@netbox-community netbox-community deleted a comment from patrick7 Jul 12, 2021
@jeremystretch jeremystretch added status: blocked Another issue or external requirement is preventing implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Sep 9, 2021
@jeremystretch
Copy link
Member

Blocked by #7016

@emil-nasso
Copy link

emil-nasso commented Mar 17, 2022

@jeremystretch Does #7016 make this issue "obsolete", as in this not being a problem anymore?

About the approach of retrieving the applicable custom fields for each model and extending the query, perhaps that would be easier if the user could choose whether or not a custom field should be "searchable" or not. A "simple" checkbox when configuring/creating a custom field. :)

That way the query could be extended with only those fields and it would be up to the user to choose how much overhead to add to searching. Some fields might be relevant for searching, some might make zero sense to search for. A custom field containing an external reference number would be great to be able to search for in the global search. A field containing the number of network interfaces on a device, maybe doesn't make sense to query in the global search (maybe a bad example...).

@tea-zup
Copy link

tea-zup commented Jul 26, 2022

I have a similar problem. I have a custom field 'administrator' in IPAM -> IP Addresses. If I use the 'all object' search the administrator is not found. If I use the 'quick search' in the IPAM -> IP Addresses page the administrator is also not found. The only way to find the administrator is to go to IPAM -> IP Addresses -> Filters -> Administrator.

I saw that similar problems have been mentioned in #1190. Have there been any updates on solving this issue?

Finding custom fields through the main (all object) search would be very helpful to me. Thank you.

@netbox-community netbox-community deleted a comment from cyr0nk0r Aug 8, 2022
@jeremystretch
Copy link
Member

I recently opened #10560 to capture work being done on a new search engine for NetBox v3.4. This FR will likely get wrapped up in that initiative, but I'll keep this issue open for now.

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: blocked Another issue or external requirement is preventing implementation labels Oct 12, 2022
@jeremystretch jeremystretch self-assigned this Oct 12, 2022
@jeremystretch jeremystretch added this to the v3.4 milestone Oct 12, 2022
@jeremystretch
Copy link
Member

Preliminary work for this has been completed in 31c2463, but will be folded into #10560 as mentioned above.

jeremystretch added a commit that referenced this issue Oct 21, 2022
* Initial work on new search backend

* Clean up search backends

* Return only the most relevant result per object

* Clear any pre-existing cached entries on cache()

* #6003: Implement global search functionality for custom field values

* Tweak field weights & document guidance

* Extend search() to accept a lookup type

* Move get_registry() out of SearchBackend

* Enforce object permissions when returning search results

* Add indexers for remaining models

* Avoid calling remove() on non-cacheable objects

* Use new search backend by default

* Extend search backend to filter by object type

* Clean up search view form

* Enable specifying lookup logic

* Add indexes for value field

* Remove object type selector from search bar

* Introduce SearchTable and enable HTMX for results

* Enable pagination

* Remove legacy search backend

* Cleanup

* Use a UUID for CachedValue primary key

* Refactoring search methods

* Define max search results limit

* Extend reindex command to support specifying particular models

* Add clear() and size to SearchBackend

* Optimize bulk caching performance

* Highlight matched portion of field value

* Performance improvements for reindexing

* Started on search tests

* Cleanup & docs

* Documentation updates

* Clean up SearchIndex

* Flatten search registry to register by app_label.model_name

* Clean up search backend classes

* Clean up RestrictedGenericForeignKey and RestrictedPrefetch

* Resolve migrations conflict
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

5 participants