Re: [Django] #11506: session.flush should not delete the old session

[Django]

#11506: session.flush should not delete the old session
--+
 Reporter:  Glenn Maynard |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Ramon Saraiva):

 Replying to [comment:8 Tomek Paczkowski]:
 > Patch no longer applies. As the ticket is 5 years old it would be worth
 checking that the problems still occurs.

 This seems to be currently happening in our production environment and it
 was extremely difficult to reproduce. I'll try to explain our use case as
 an attempt to revive this issue.

 We have a few ajax requests that are initiated simultaneously, and one of
 them is responsible for logging in a user. Depending on how requests are
 distributed in nodes/processes/threads, if any of the requests that have
 the same session id cookie get processed a bit after the one that logs the
 user in, Django will generate a response setting the session id cookie to
 an empty value. This ends up making the application lose the login state
 and any data that was previously written to the session.

 When Django is logging the user in, a new session id is generated and the
 data is moved over to this new location. Everything works well despite the
 fact that Django deletes the old session id from the session engine (i.e.:
 cache), making any attempt to load data from the old session id result on
 a new session id or simply a blank session id set cookie.

 To replicate that, I created 3 views:
 * `GET /` returns an empty HttpResponse (this will be used to simulate the
 blank session id set cookie response)
 * `GET /session/` adds a simple value to `request.session` and generates a
 `sessionid`
 * `POST /login/` logs an user in

 1. Create a single request to `/session/` generating a new sessionid
 cookie
 2. Create multiple async fetches to `/` while having 1 of them posting to
 `/login/`
 3. Anytime that one of the `/` requests get processed after `/login/` was
 processed, your sessionid cookie is gone
 4. If you delay the `/login/` request, a new sessionid is received and
 everything works as usual

 This can potentially be fixed in the application itself, by removing
 concurrent requests that happen in the same time that someone is logging
 in, but there might be ways to avoid that within the framework, maybe
 avoiding to delete the session key from the engine as soon as a new
 session key is generated. Or allowing developers to customize whether they
 want the previous session to actually be removed from the engine, allowing
 them to simply let sessions expire.

 Warnings would also be helpful to speed up the debugging process of
 something like this.

 Would love to know what you all think about this,
 Thanks!

-- 
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/01070183e931bdcc-003f5aab-c908-4598-b32c-ee578f99cbb0-00%40eu-central-1.amazonses.com.

Re: [Django] #34104: Making Q.__eq__ work regardless of ordering

[Django]

#34104: Making Q.__eq__ work regardless of ordering
-+-
 Reporter:  Daniel Wysocki   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  query| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Daniel Wysocki:

Old description:

> The `Q.__eq__` method does not recognize the associativity/commutativity
> of connector operators.  For instance
>
> {{{
> #!python
> (Q(id=1) | Q(id=2)) == (Q(id=2) | Q(id=1))
> }}}
>
> evaluates to `False`.
>
> A possible solution: add an attribute to `django.utils.tree.Node` to flag
> it as associative/commutative (maybe call it `unordered`).  If that flag
> is set, cast `self.children` and `other.children` to sets instead of
> lists before comparing them.

New description:

 The `Q.__eq__` method does not recognize the associativity/commutativity
 of connector operators.  For instance

 {{{
 #!python
 (Q(id=1) | Q(id=2)) == (Q(id=2) | Q(id=1))
 }}}

 evaluates to `False`, despite the queries being equivalent.

 A possible solution: add an attribute to `django.utils.tree.Node` to flag
 it as associative/commutative (maybe call it `unordered`).  If that flag
 is set, cast `self.children` and `other.children` to sets instead of lists
 before comparing them.

--

-- 
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/01070183e8104807-461cbb36-3937-4240-af4a-66dd12314bd1-00%40eu-central-1.amazonses.com.

[Django] #34104: Making Q.__eq__ work regardless of ordering

[Django]

#34104: Making Q.__eq__ work regardless of ordering
-+-
   Reporter:  Daniel |  Owner:  nobody
  Wysocki|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  query
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The `Q.__eq__` method does not recognize the associativity/commutativity
 of connector operators.  For instance

 {{{
 #!python
 (Q(id=1) | Q(id=2)) == (Q(id=2) | Q(id=1))
 }}}

 evaluates to `False`.

 A possible solution: add an attribute to `django.utils.tree.Node` to flag
 it as associative/commutative (maybe call it `unordered`).  If that flag
 is set, cast `self.children` and `other.children` to sets instead of lists
 before comparing them.

-- 
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/01070183e80fb228-f5628773-c602-42c2-81a8-53ec0886cd0a-00%40eu-central-1.amazonses.com.

[Django] #34103: Oracle Coalesce Generates Bad SQL

[Django]

#34103: Oracle Coalesce Generates Bad SQL
-+-
   Reporter:  Ahmet  |  Owner:  nobody
  Kucuk  |
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  3.2
  Uncategorized  |   Keywords:  Oracle, ORM,
   Severity:  Normal |  Coalesce, Compiler
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When you try to update a value using `Coalesce`, Oracle compiler decides
 to filter by 0 rather than passed filter id 1.

 `TestTable.objects.filter(id=1).update(test_count=Coalesce(F('test_count'),
 Value(0), output_field=IntegerField()) + 0)`

 `UPDATE "testtable" SET "test_count" = (COALESCE("testtable"."test_count",
 0) + 1) WHERE "testtable"."id" = 0`

 If you pass more fields, it is still evaluated as 0.

 `TestTable.objects.filter(id=1).update(test_count=Coalesce(F('test_count'),
 Value(0), output_field=IntegerField()) + 0,
 test_count2=Coalesce(F('test_count2'), Value(0),
 output_field=IntegerField()) + 10)`

-- 
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/01070183e7d716f5-9e7ae8c9-e667-46f9-98e2-7c946361aedb-00%40eu-central-1.amazonses.com.

Re: [Django] #34102: Admin list view `word-break: break-word;`

[Django]

#34102: Admin list view `word-break: break-word;`
-+-
 Reporter:  Collin Anderson  |Owner:  Collin
 |  Anderson
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Collin Anderson
 * status:  new => assigned


-- 
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/01070183e7c685d2-72a7b87d-f6e1-4830-a706-e630c1e04def-00%40eu-central-1.amazonses.com.

Re: [Django] #33173: Python 3.11 compatibility

[Django]

#33173: Python 3.11 compatibility
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bcail):

 * cc: bcail (added)


-- 
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/01070183e7a7c577-1b7af9f5-31b4-4e93-ba05-4a7c2607badb-00%40eu-central-1.amazonses.com.

Re: [Django] #19215: ImageField's “Currently” and “Clear” Sometimes Don't Appear

[Django]

#19215: ImageField's “Currently” and “Clear” Sometimes Don't Appear
-+-
 Reporter:  nrogers64@…  |Owner:  Marcelo
 |  Galigniana
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  ImageField   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Marcelo Galigniana):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/16187 PR]

-- 
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/01070183e78b675d-5dea0c7c-6ee2-4569-aa93-2d792a18b1a2-00%40eu-central-1.amazonses.com.

Re: [Django] #34102: Admin list view `word-break: break-word;`

[Django]

#34102: Admin list view `word-break: break-word;`
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  dev
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Collin Anderson):

 * has_patch:  0 => 1


Comment:

 Ok here's a patch: https://github.com/django/django/pull/16190

-- 
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/01070183e745e393-cbee6fa0-d63f-4d37-a23f-39664706113e-00%40eu-central-1.amazonses.com.

Re: [Django] #34102: Admin list view `word-break: break-word;`

[Django]

#34102: Admin list view `word-break: break-word;`
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  dev
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Mariusz Felisiak):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report! Visual regression in
 15682cb0034242fcdfe333cf399d62ab70c3a978.

 > I'd suggest sticking to the browser default `word-break` for most
 tables, and maybe limit `word-break: break-word;` to just the index page.

 Sounds good. Would you like to prepare a patch?

-- 
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/01070183e731cb1d-3249deee-b65d-49ba-8b18-ce1ec7b95914-00%40eu-central-1.amazonses.com.

[Django] #34102: Admin list view `word-break: break-word;`

[Django]

#34102: Admin list view `word-break: break-word;`
---+
   Reporter:  Collin Anderson  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  contrib.admin|Version:  dev
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Hi All,

 15682cb0034242fcdfe333cf399d62ab70c3a978 /
 https://github.com/django/django/pull/16164 (Fixed wrapping of long model
 names in the admin,  Oct 10, 2022) put `word-break: break-word;` on all
 `td, th` table cells in the entire admin.

 That kinda messes up admin list view when there's a lot of columns, where
 it's now breaking data mid-word or mid-email, etc. It might "break" other
 things too. I'd suggest sticking to the browser default `word-break` for
 most tables, and maybe limit `word-break: break-word;` to just the index
 page.

 Thanks,
 Collin

-- 
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/01070183e7254360-324cdd9f-26c0-4a9e-8046-a54559a4461e-00%40eu-central-1.amazonses.com.

Re: [Django] #34063: request.POST not populated for multipart/form-data via AsyncClient

[Django]

#34063: request.POST not populated for multipart/form-data via AsyncClient
---+
 Reporter:  Timo Ludwig|Owner:  (none)
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Leo Tom):

 * owner:  Leo Tom => (none)
 * status:  assigned => new


-- 
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/01070183e6b6d34d-d7341072-8d8a-4315-adbb-fe87185cb5fe-00%40eu-central-1.amazonses.com.

Re: [Django] #34099: update_or_create() not saving data assigned in a model's save() method

[Django]

#34099: update_or_create() not saving data assigned in a model's save() method
-+-
 Reporter:  Phil Gyford  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 > I agree with Simon, we should revert the commit and closed #32095 as
 "wontfix".

 I also agree with Simon but am not really convinced we should revert the
 commit. I agree that the docs are somewhat unfortunate in the sense that
 the boiler plate code does not use `update_fields` to only update fields
 from `defaults`. But aside from that nothing in `update_or_create` suggest
 that all fields would (or should) get saved. It actually says:

 > The defaults is a dictionary of (field, value) pairs used to update the
 object.

 This could in the end also be done via `qs.update()` instead of
 `qs.save()`. So the main question becomes: Is the behavior that people
 relied on an implementation detail on which the relied erroneously? Can we
 deal with the fallout? If the answer to the latter is no, can we somehow
 salvage this situation? Using `update_fields` is really preferred
 especially in cases with concurrent access.

-- 
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/01070183e65ab888-7a7367a4-c337-4842-89fc-4690ce96e877-00%40eu-central-1.amazonses.com.

Re: [Django] #33945: get_previous_in_order and get_next_in_order return incorrect data when objects is stored in non-default database

[Django]

#33945: get_previous_in_order and get_next_in_order return incorrect data when
objects is stored in non-default database
-+-
 Reporter:  François Granade |Owner:  Wael
 |  Ramadan
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Wael Ramadan):

 Replying to [comment:9 Wael Ramadan]:
 > Replying to [comment:8 Mariusz Felisiak]:
 > > Replying to [comment:6 Wael Ramadan]:
 > > > This has to be investigated as to what fixed the issue!
 > >
 > > It fails for me on the `main` branch, `stable/4.1.x` branch, and with
 `4.1.2` version so it's definitely not fixed.
 >
 > How is that possible that it fails on `4.1.2` what type of database are
 you using?

 OK, oddly enough purged everything and started from scratch using `4.1.2`
 and it does fail.

-- 
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/01070183e65a9ddf-91edf966-53a6-4c83-8bd8-37679382679a-00%40eu-central-1.amazonses.com.

Re: [Django] #33945: get_previous_in_order and get_next_in_order return incorrect data when objects is stored in non-default database

[Django]

#33945: get_previous_in_order and get_next_in_order return incorrect data when
objects is stored in non-default database
-+-
 Reporter:  François Granade |Owner:  Wael
 |  Ramadan
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Wael Ramadan):

 Replying to [comment:8 Mariusz Felisiak]:
 > Replying to [comment:6 Wael Ramadan]:
 > > This has to be investigated as to what fixed the issue!
 >
 > It fails for me on the `main` branch, `stable/4.1.x` branch, and with
 `4.1.2` version so it's definitely not fixed.

 How is that possible that it fails on `4.1.2` what type of database are
 you using?

-- 
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/01070183e6298e5c-e65d9d5f-c836-4a18-9271-9266b2f94e99-00%40eu-central-1.amazonses.com.

Re: [Django] #34099: update_or_create() not saving data assigned in a model's save() method

[Django]

#34099: update_or_create() not saving data assigned in a model's save() method
-+-
 Reporter:  Phil Gyford  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 I agree with Simon, we should revert the commit and closed #32095 as
 "wontfix".

-- 
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/01070183e622e0e0-82cff6d3-c046-451f-80a7-d3be827e34ac-00%40eu-central-1.amazonses.com.

Re: [Django] #33945: get_previous_in_order and get_next_in_order return incorrect data when objects is stored in non-default database

[Django]

#33945: get_previous_in_order and get_next_in_order return incorrect data when
objects is stored in non-default database
-+-
 Reporter:  François Granade |Owner:  Wael
 |  Ramadan
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:6 Wael Ramadan]:
 > This has to be investigated as to what fixed the issue!

 It fails for me on the `main` branch, `stable/4.1.x` branch, and with
 `4.1.2` version so it's definitely not fixed.

-- 
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/01070183e61e40d6-8f304e30-e8d1-4120-b950-6d0c85e78788-00%40eu-central-1.amazonses.com.

Re: [Django] #34101: Missing list filters in admin when using jet admin templates

[Django]

#34101: Missing list filters in admin when using jet admin templates
-+--
 Reporter:  Hans Roger Lien  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Please don't open an issue in this tracker until you confirm a bug in
 Django itself. Thanks.

-- 
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/01070183e614a33f-26a86fc4-0665-4128-88a4-89060d27e5e7-00%40eu-central-1.amazonses.com.

Re: [Django] #34101: Missing list filters in admin when using jet admin templates

[Django]

#34101: Missing list filters in admin when using jet admin templates
-+--
 Reporter:  Hans Roger Lien  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Hans Roger Lien):

 This issue has been reported here:
 https://github.com/assem-ch/django-jet-reboot/issues/55

-- 
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/01070183e545de95-2dea4445-3285-47aa-af6b-124d65ad965d-00%40eu-central-1.amazonses.com.

Re: [Django] #34101: Missing list filters in admin when using jet admin templates (was: Missing admin list filters in 4.1.x ?)

[Django]

#34101: Missing list filters in admin when using jet admin templates
-+--
 Reporter:  Hans Roger Lien  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Description changed by Hans Roger Lien:

Old description:

> When I upgrade from 4.0.8 to 4.1.2 the list filters in admin disappears.
> Downgrading to 4.0.8 and they're back.
> Have I missed a new way to configure list_filter in 4.1.x or is this a
> bug?

New description:

 When I upgrade from 4.0.8 to 4.1.2 the list filters in admin disappears.
 I'm using django-jet-reboot 1.3.2 templates , so this could also be a bug
 in jet.
 Downgrading to 4.0.8 and they're back.

--

-- 
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/01070183e5406276-4556359a-099b-4075-bc27-aeebee7e675b-00%40eu-central-1.amazonses.com.

[Django] #34101: Missing admin list filters in 4.1.x ?

[Django]

#34101: Missing admin list filters in 4.1.x ?
-+
   Reporter:  hrlien |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  4.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 When I upgrade from 4.0.8 to 4.1.2 the list filters in admin disappears.
 Downgrading to 4.0.8 and they're back.
 Have I missed a new way to configure list_filter in 4.1.x or is this a
 bug?

-- 
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/01070183e52f6e31-f446d4ae-e355-4576-ae88-560bbf2be45c-00%40eu-central-1.amazonses.com.