Refactored PartList to seperate functionality and added ipn sorting

[phunprogrammer]

PR to solve #7998 and refactor filter_queryset() to seperate some responsibilities within.

Images shown below using example mentioned in original issue:
Before:

After:

[netlify]

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

Name	Link
🔨 Latest commit	cd092b5
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-web-pui-preview/deploys/6800b6291d51260008f118cf

[SchrodingersGat]

@phunprogrammer an interesting approach here, I can see the appeal.

I would like to consider whether this can be made more generic (not tied specifically to the IPN field for example). It feels very specific to your particular requirements / use-case.

[matmair]

@phunprogrammer please respond to above question so that we can move forward

[phunprogrammer]

@SchrodingersGat Perhaps more functionality could be added to the search options that are already there. Currently, those options seem pretty limited to the three options that are available. A possible solution is to add some sort of selection in those options that could select a part parameter to sort by. Another solution would be to use ipn:100 in the search to sort by IPN, the use of other tags would be made possible with this pattern. What solution do you think works best in this scenario?

[SchrodingersGat]

We would need to consider how it works not just for searching against "Part" instances - as the search also looks for other model types (e.g. sales orders, stock items, etc).

Making this fully "flexible" or "configurable" will present the user with a complex UI to allow them to finely tune their expected results. I'm not immediately sure how best to go about it.

One thing from my persepctive - as we have added more search fields (in response to user requests, mainly) I have found that the search returns too many results, and not the ones I actually want. So I am on board with the goal of what you are proposing here. However I do not want to accept an implementation that is tailored to a specific use-case or preference.

The goal here should be to allow the user to intuitively control how the search results are returned. And also not to cause the back-end DB queries to be too complex and expensive.

Getting search "right" is very hard...

[SchrodingersGat]

Thinking about this further, what if we made your approach a bit more generic. We already specify the set of "search_fields" for a given API endpoint. We could utilize this to also define the "ordering" of the returned results. For example in the PartList API:

InvenTree/src/backend/InvenTree/part/api.py

Line 1247 in afbcfe6

class PartList(PartMixin, BulkUpdateMixin, DataExportViewMixin, ListCreateAPI):

we define the search_fields:

InvenTree/src/backend/InvenTree/part/api.py

Line 1401 in afbcfe6

search_fields = [

    search_fields = [
        'name',
        'description',
        'IPN',
        'revision',
        'keywords',
        'category__name',
        'manufacturer_parts__MPN',
        'supplier_parts__SKU',
        'tags__name',
        'tags__slug',
    ]

we could potentially create a custom search filter class (to replace the DRF SearchFilter class) which orders the results based on the specified ordering of the search fields.

This would apply the approach across all searchable API endpoints

[SchrodingersGat]

If we wanted to go even further we could expose which fields are "searchable" on any given API endpoint - and then the client could potentially pass a list of fields to search when submitting a search. By default, all available fields are searched. This way, we could provision for further customization of search results in the future