Opened 14 months ago

Last modified 6 months ago

#34402 assigned Bug

Admin search_fields crashes for inherited model and __iexact lookup.

Reported by: Pavel Pančocha Owned by: Rahmat Faisal
Component: contrib.admin Version: 3.2
Severity: Normal Keywords:
Cc: Sarah Boyce Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Pavel Pančocha)

Hello everyone!

Let's have model Payer and we will create ExtendedPayer from it

class ExtendedPayer(Payer):
    ...

We create admin for ExtendedPayer and define search fields. We want to be able to filter by pk of Payer. So I would expect these to work the same:

class ExtendedPayerAdmin(ModelAdmin):
    ...
    search_fields = (
        "pk__iexact", ...
    )
    ...
class ExtendedPayerAdmin(ModelAdmin):
    ...
    search_fields = (
        "id__iexact", ...
    )
    ...

Guess what? The "id" variant works ok and the "pk" fails with Related Field got invalid lookup: iexact

Why? Because in construct_search (See Git) it's transformed to pk__iexact__icontains as it found out that the pk is payer_ptr which is FK.

If we want to be correct, it should be "payer_ptr__pk__iexact".

Please let me know if this behaviour is a bug or if is there any reason behind it.

Change History (10)

comment:1 by Mariusz Felisiak, 14 months ago

All cases pk, payer__ptr, and id works with the __exact lookup. Do you need __iexact?

The main difference is that id is AutoField, pk and payer_ptr are recognized as OneToOneField.

Last edited 14 months ago by Mariusz Felisiak (previous) (diff)

comment:2 by Mariusz Felisiak, 14 months ago

Triage Stage: UnreviewedAccepted

Agreed, this restriction should be documented or fixed.

Last edited 14 months ago by Tim Graham (previous) (diff)

comment:3 by Mariusz Felisiak, 14 months ago

Summary: Admin searchfields for inherited modelAdmin search_fields crashes for inherited model and __iexact lookup.

in reply to:  1 comment:4 by Pavel Pančocha, 14 months ago

Replying to Mariusz Felisiak:

All cases pk, payer__ptr, and id works with the __exact lookup. Do you need __iexact?

The main difference is that id is AutoField, pk and payer_ptr are recognized as OneToOneField.

Yes, because the exact fails in the search in the admin. When I try to search something else with chars (eg. test) and I have the lookup for pk__exact if it fails with the exception it cannot convert the test to int. It works for iexact - maybe it is a problem already fixed in newer Django version.

What is the proposed solution here? Should the resulting query be transformed to payer_ptr__pk__iexact?

comment:5 by Pavel Pančocha, 14 months ago

Description: modified (diff)

comment:6 by Rahmat Faisal, 14 months ago

let me check

comment:7 by Rahmat Faisal, 14 months ago

Owner: changed from nobody to Rahmat Faisal
Status: newassigned

comment:8 by Sarah Boyce, 8 months ago

Can you not define the search_fields here to be payer_ptr__pk__iexact (as you would when constructing a filter)?
I feel like transforming the query for the search_fields might be surprising as this error is consistent as to if you were to do this with .filter.

(If we want this transforming behaviour I have a patch ready, just not convinced it's what we want)

comment:9 by Sarah Boyce, 8 months ago

Cc: Sarah Boyce added

in reply to:  8 comment:10 by Pavel Pančocha, 6 months ago

Replying to Sarah Boyce:

Can you not define the search_fields here to be payer_ptr__pk__iexact (as you would when constructing a filter)?
I feel like transforming the query for the search_fields might be surprising as this error is consistent as to if you were to do this with .filter.

(If we want this transforming behaviour I have a patch ready, just not convinced it's what we want)

Sorry, I don't get your comment. The search fields are ("pk__iexact",.... Or what else do you propose? The issue is, that it differs in the way it works with "id" and how with "pk".

If I can help more, let me know please.

Note: See TracTickets for help on using tickets.
Back to Top