[Django] #34216: django admin when field is autocomplete it overrides ModelForm filter

2022-12-17 Thread Django 
#34216: django admin when field is autocomplete it overrides ModelForm filter
-+-
   Reporter:  sahaliyev  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  4.1
  contrib.admin  |   Keywords:  autocomplete,
   Severity:  Normal |  filter
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 having issue on django admin. I want one of my foreign key field to be
 searchable and I achieved that making it autocomplete.


 {{{
 class CollectionAdmin(VersionAdmin, admin.ModelAdmin):
 form = CollectionForm
 autocomplete_fields = ["task"]
 }}}


 I also filter that foreign key in ModelForm.


 {{{
 class CollectionForm(forms.ModelForm):
 class Meta:
 model = Collection
 fields = "__all__"

 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)

 if self.fields.get("task"):
 self.fields["task"].queryset =
 self.fields["task"].queryset.filter(
 status=TaskStatus.ASSIGNED
 )
 }}}


 When task is not autocomplete field in Collection my filter works as
 expected. However, when task is autocomplete field in Collection, filter
 does not work. Instead of my filter in form, task admin get_queryset
 method is called which is not what I want.

 TaskAdmin get_queryset method just filters by user, however I want more
 filter as you see above, for TaskStatus as well.


 {{{
 def get_queryset(self, request):
 qs = super().get_queryset(request)
 if
 request.user.groups.filter(name=settings.COPYWRITER_GROUP).exists():
 return qs.filter(assigned_to=request.user)
 return qs
 }}}


 Repeating, form init filter works if field is not autocomplete.

 I tried removing task from autocomplete of Collection and it worked. I
 want my form filter not overridden if field is autocomplete.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018521f5f028-dfe9ef0b-e934-4db0-96cd-5e854922313e-00%40eu-central-1.amazonses.com.

Re: [Django] #34170: Mitigate the BREACH attack

2022-12-17 Thread Django 
#34170: Mitigate the BREACH attack
-+-
 Reporter:  Andreas Pelme|Owner:  Andreas
 |  Pelme
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  breach, htb, gzip| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"ab7a85ac297464df82d8363455609979ca3603db" ab7a85ac]:
 {{{
 #!CommitTicketReference repository=""
 revision="ab7a85ac297464df82d8363455609979ca3603db"
 Fixed #34170 -- Implemented Heal The Breach (HTB) in GzipMiddleware.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070185217c212d-eb2aca7e-4718-4e0a-9eb9-11ea6c4a73a4-00%40eu-central-1.amazonses.com.

Re: [Django] #28358: LazyObject defines attribute that don't exist on wrapped object

2022-12-17 Thread Django 
#28358: LazyObject defines attribute that don't exist on wrapped object
-+-
 Reporter:  Andrey Fedoseev  |Owner:  Theofilos
 |  Alexiou
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cfbolz):

 hi everyone! PyPy dev here. So after some investigation (you can find the
 gory details on this CPython issue:
 https://github.com/python/cpython/issues/98148 ) it turns out that this
 bug also exists in CPython, if you run coverage in pure python mode. The
 bug occurs only if you: 1) use `super` 2) define `__class__` in the class
 body yourself 3) use a pure python trace hook, or call locals() in the
 class body.

 At this point there has been no reaction from CPython yet, but the way I
 see things from the PyPy side it'll be on the tricky to fix this so it
 might take a while (I'm waiting for CPy feedback because the two
 implementations use exactly the same approaches here, to the point of
 ending up with exactly the same bug).

 I was wondering whether Django might be open to a PR that works around the
 bug for the time being? A pragmatic approach would be to stop using super
 in `LazyObject.__getattribute__`, which was introduced in
 97d7990abde3fe4b525ae83958fd0b52d6a1d13f, and just call
 `object.__getattribute__` instead. If that sounds like a reasonable
 solution, I am happy to work on the PR. (there would be some trickiness to
 how to unit test this, but I can probably think of something). Please let
 me know!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701852108a0d6-2ab224aa-e28c-460b-97ad-631de0c1aeea-00%40eu-central-1.amazonses.com.