Generic Search

[kevbang]

Generic Search

This is a follow-up to the IPN sorting issue.

Hello maintainers,

In this pull request, I have attempted to address the concerns in the previous pull request linked above. I created an OrderedSearchFilter class which helps customize the search behavior by doing two things:

1. Uses DRF’s normal search filter to find matching results:

   queryset = super().filter_queryset(request, queryset, view)

2. Orders the queryset based on search_fields defined in the view:

   search_fields = getattr(view, 'search_fields', [])
   if search_fields:
       queryset = queryset.order_by(*search_fields)

   If a view has a list of fields it searches, i.e., ['name', 'description'], sort the results based on that same order. So, if
   PartList's search_fields looks like search_fields = ['name', 'description'], it will be ordered by name then by description.

Currently, I’ve only applied this to the Part API as a starting point, since I wasn’t entirely sure if this was the right direction to go. If this approach aligns with the maintainers’ vision for improving search relevance, I’d be happy to expand on this and work on this issue outside of class. Looking forward to your feedback!

[netlify]

✅ Deploy Preview for inventree-web-pui-preview canceled.

Name	Link
🔨 Latest commit	fd6f061
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-web-pui-preview/deploys/6820b949d5865500080dc190

[SchrodingersGat]

This approach will not order the search results based on which search fields provide a match. It will order the returned results simply based on the order of specified search fields. Is this intentional?

Additionally this will override the ordering specified by the client using the "order_by" query parameter

[codecov]

Codecov Report

Attention: Patch coverage is 84.61538% with 2 lines in your changes missing coverage. Please review.

Project coverage is 86.14%. Comparing base (d7c2937) to head (fd6f061).

Files with missing lines	Patch %	Lines
src/backend/InvenTree/common/api.py	81.81%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9653      +/-   ##
==========================================
- Coverage   86.35%   86.14%   -0.22%     
==========================================
  Files        1229     1229              
  Lines       53966    53978      +12     
  Branches     2260     2260              
==========================================
- Hits        46602    46499     -103     
- Misses       6792     6907     +115     
  Partials      572      572              

Flag	Coverage Δ
backend	88.05% <84.61%> (-0.27%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kevbang]

This approach will not order the search results based on which search fields provide a match. It will order the returned results simply based on the order of specified search fields. Is this intentional?

Additionally this will override the ordering specified by the client using the "order_by" query parameter

You're absolutely right. This approach doesn’t actually rank results based on relevance or match strength across search fields, and it unintentionally overrides any ordering specified by the client via the order_by parameter. That wasn’t my intention going in, and I see now how this implementation could create unintended side effects for users expecting more control or predictable relevance.

Given that, and since this solution doesn’t quite align with how search should behave more generally, I’ll go ahead and close this out. Thank you again for taking the time to review it. This was still a great learning experience, and I appreciate the feedback.

[SchrodingersGat]

@kevbang no worries!