Re: [Django] #31283: "collecstatic --clear" could take ignored patterns into consideration

[Django]

#31283: "collecstatic --clear" could take ignored patterns into consideration
-+-
 Reporter:  Mateusz Papiernik|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Carlton Gibson):

 The existing text seems clear enough to me:

 > --clear, -c
 > Clear the existing files before trying to copy or link the original
 file.

 If you want to propose an adjustment, we're always happy to look at it.

-- 
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/066.5c299d2c8c56e623b9dddbf550883e18%40djangoproject.com.

Re: [Django] #31285: Inherited model doesn't correctly order by "-pk" when specified on Parent.Meta.ordering

[Django]

#31285: Inherited model doesn't correctly order by "-pk" when specified on
Parent.Meta.ordering
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   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 Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/12470

 > I also wonder if `ordering = ('pk',)` should be special cased to order
 by the ''local'' child class primary key which would be
 `"myapp_child"."parent_ptr_id"` in this case since it should result in the
 same resulset because of foreign key integrity and avoid an unnecessary
 `JOIN` in the cases where no parent fields are involved.

 Interesting enough, ordering by `["-id"]` was already doing that. So I
 agree that "-pk" should behave the same.

-- 
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/067.b684a5ad050e5c0aa3a31e161e1734f0%40djangoproject.com.

Re: [Django] #31285: Inherited model doesn't correctly order by "-pk" when specified on Parent.Meta.ordering

[Django]

#31285: Inherited model doesn't correctly order by "-pk" when specified on
Parent.Meta.ordering
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (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
-+-
Changes (by Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 Interesting `ordering` is effectively one of the rare `Meta`
 [https://docs.djangoproject.com/en/3.0/topics/db/models/#meta-and-multi-
 table-inheritance attribute preserved during MTI inheritance].

 I also wonder if `ordering = ('pk',)` should be special cased to order by
 the ''local'' child class primary key which would be
 `"myapp_child"."parent_ptr_id"` in this case since it should result in the
 same resulset because of foreign key integrity and avoid an unnecessary
 `JOIN` in the cases where no parent fields are involved.

-- 
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/067.b2381ab102ac6c065cb5334b97973988%40djangoproject.com.

[Django] #31285: Inherited model doesn't correctly order by "-pk" when specified on Parent.Meta.ordering

[Django]

#31285: Inherited model doesn't correctly order by "-pk" when specified on
Parent.Meta.ordering
-+-
   Reporter:  Jon|  Owner:  nobody
  Dufresne   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Given the following model definition:

 {{{
 from django.db import models

 class Parent(models.Model):
 class Meta:
 ordering = ["-pk"]

 class Child(Parent):
 pass
 }}}

 Querying the `Child` class results in the following:

 {{{
 >>> print(Child.objects.all().query)
 SELECT "myapp_parent"."id", "myapp_child"."parent_ptr_id" FROM
 "myapp_child" INNER JOIN "myapp_parent" ON ("myapp_child"."parent_ptr_id"
 = "myapp_parent"."id") ORDER BY "myapp_parent"."id" ASC
 }}}

 The query is ordered `ASC` but I expect the order to be `DESC`.

-- 
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/052.31fc33f5e9d06db10fd3595da0ea7e27%40djangoproject.com.

Re: [Django] #29205: MultiValueField ignores a required value of a sub field

[Django]

#29205: MultiValueField ignores a required value of a sub field
+---
 Reporter:  Takayuki Hirai  |Owner:  David Smith
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  1.11
 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 David Smith):

 I've done some investigation into this. Here are some notes which explain
 the behaviour outlined in the ticket.

 **is_valid()**

 The
 
[https://github.com/django/django/blob/49275c548887769cd70bbd85a3b125491f0c4062/django/forms/fields.py#L1006
 clean] method of MultiValueField is driving the validation behaviour
 explained in the original ticket.

 The example in the ticket shows `required=False` being set on the
 `MultiValueField`. When the fields are all blank (or two empty strings)
 the logic follows this if statement and therefore doesn't raise a
 validation error and `return self.compress([])`
 {{{
if not value or isinstance(value, (list, tuple)):
 if not value or not [v for v in value if v not in
 self.empty_values]:
 if self.required:
 raise ValidationError(self.error_messages['required'],
 code='required')
 else:
 return self.compress([])
 }}}

 In the case where one of the fields has some data, it skips this `if`
 statement. The next section of clean loops over `fields` and therefore
 raises an error as one of them contains `required=True`

 **Required attribute**

 The notes above also explain that is the field is `required=True` (default
 setting) then whilst is_valid() gives the expected output both of the
 fields input html tags both become `required`. This is due to this piece
 of code in
 
[https://github.com/django/django/blob/b9cf764be62e77b4777b3a75ec256f6209a57671/django/forms/boundfield.py#L221
 boundfield.py]. This code looks at the field required status rather than
 subwidgets. Therefore all of the inputs for subwidgets are treated the
 same, irrespective of each subwidgets `required` attribute.

 I therefore think that the two areas above are where we should be looking
 at for a potential fix. However, I'm not quite sure what is intended to
 happen where some widgets are required and others are not. Some questions,
 appreciate thoughts.

 - Should inputs have required html attributes (all, some, none)
 - How should the help / validation text work. (e.g. 'this field is
 required')

-- 
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/064.d9b537034ed3af715338049c9f6aeffb%40djangoproject.com.

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  Moses
 |  Mugisha
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Moses Mugisha):

 * owner:  nobody => Moses Mugisha
 * 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/067.aa5684a45893b104c6efe3ac1b8f0a46%40djangoproject.com.

Re: [Django] #26601: DEP5 implementation: Improved middleware

[Django]

#26601: DEP5 implementation: Improved middleware
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 |  Graham
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  master
 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 Carlton Gibson ):

 In [changeset:"4d973f593932285cd2f765400d915305d8e7333a" 4d973f59]:
 {{{
 #!CommitTicketReference repository=""
 revision="4d973f593932285cd2f765400d915305d8e7333a"
 Refs #26601 -- Deprecated passing None as get_response arg to middleware
 classes.

 This is the new contract since middleware refactoring in Django 1.10.

 Co-authored-by: Carlton Gibson 
 Co-authored-by: Mariusz Felisiak 
 }}}

-- 
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/067.5aa903bcca4663a6a7ff21d6698cc9c1%40djangoproject.com.

Re: [Django] #31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the field the relation points to is acceptable for one-to-many relations.

[Django]

#31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the
field the relation points to is acceptable for one-to-many relations.
-+-
 Reporter:  Yu Li|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Release blocker  |   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 Carlton Gibson ):

 In [changeset:"7deb87c93e5f45ded3ccd1e6162bed6a3af8" 7deb87c9]:
 {{{
 #!CommitTicketReference repository=""
 revision="7deb87c93e5f45ded3ccd1e6162bed6a3af8"
 [2.2.x] Fixed #31282 -- Corrected RelatedManager docs for using
 add/remove/set with PKs.

 Backport of 3bbf9a489afc689eff2f4a0b84af196aa1ef51e7 from master
 }}}

-- 
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/066.5d74470c0fb7c136a89179ad4b17a341%40djangoproject.com.

Re: [Django] #31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the field the relation points to is acceptable for one-to-many relations.

[Django]

#31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the
field the relation points to is acceptable for one-to-many relations.
-+-
 Reporter:  Yu Li|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Release blocker  |   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 Carlton Gibson ):

 In [changeset:"611d1c114835310a0cd963e20f3e9782c34db847" 611d1c11]:
 {{{
 #!CommitTicketReference repository=""
 revision="611d1c114835310a0cd963e20f3e9782c34db847"
 [3.0.x] Fixed #31282 -- Corrected RelatedManager docs for using
 add/remove/set with PKs.

 Backport of 3bbf9a489afc689eff2f4a0b84af196aa1ef51e7 from master
 }}}

-- 
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/066.e4eedf7ea1fd5e690aa985018e0dba31%40djangoproject.com.

Re: [Django] #31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the field the relation points to is acceptable for one-to-many relations.

[Django]

#31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the
field the relation points to is acceptable for one-to-many relations.
-+-
 Reporter:  Yu Li|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Release blocker  |   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
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"3bbf9a489afc689eff2f4a0b84af196aa1ef51e7" 3bbf9a48]:
 {{{
 #!CommitTicketReference repository=""
 revision="3bbf9a489afc689eff2f4a0b84af196aa1ef51e7"
 Fixed #31282 -- Corrected RelatedManager docs for using add/remove/set
 with PKs.
 }}}

-- 
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/066.9caf06ebbdc3c374c70d552c6b3ef09b%40djangoproject.com.

Re: [Django] #31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the field the relation points to is acceptable for one-to-many relations.

[Django]

#31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the
field the relation points to is acceptable for one-to-many relations.
-+-
 Reporter:  Yu Li|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Release blocker  |   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 Carlton Gibson ):

 In [changeset:"a34cb5a6d408203f4fbdb364fc9768c026eda224" a34cb5a]:
 {{{
 #!CommitTicketReference repository=""
 revision="a34cb5a6d408203f4fbdb364fc9768c026eda224"
 Refs #31282 -- Clarified M2O add/remove/set with PK behaviour.

 Improved error message for remove() and added tests.
 }}}

-- 
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/066.62c96830426c0e4c30009ff81fc30802%40djangoproject.com.

Re: [Django] #31275: Optimize MariaDB/MySQL sql_flush

[Django]

#31275: Optimize MariaDB/MySQL sql_flush
-+-
 Reporter:  Adam (Chainz)|Owner:  jonatron
  Johnson|
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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
-+-
Changes (by jonatron):

 * owner:  nobody => jonatron
 * 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/068.afbdb2f77121db44eb7cad061b625045%40djangoproject.com.

Re: [Django] #31276: Add 'flush' option to only clear non-empty tables

[Django]

#31276: Add 'flush' option to only clear non-empty tables
-+-
 Reporter:  Adam (Chainz)|Owner:  jonatron
  Johnson|
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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
-+-
Changes (by jonatron):

 * owner:  nobody => jonatron
 * 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/068.075db9835075a1625ada7ca4d4d93cca%40djangoproject.com.

Re: [Django] #31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the field the relation points to is acceptable for one-to-many relations.

[Django]

#31282: Docs for RelatedManager.set()/add()/remove() incorrectly states that the
field the relation points to is acceptable for one-to-many relations.
-+-
 Reporter:  Yu Li|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  3.0
 Severity:  Release blocker  |   Resolution:
 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
-+-
Changes (by felixxm):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/12466 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/066.110837fb8ae7f7137978ecba793c08b8%40djangoproject.com.

Re: [Django] #29724: Admin date_hierarchy filter by month displays an extra day at timezone boundary.

[Django]

#29724: Admin date_hierarchy filter by month displays an extra day at timezone
boundary.
---+--
 Reporter:  Lavrenov Ivan  |Owner:  Hasan Ramezani
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Changes (by Hasan Ramezani):

 * owner:  Alexander Holmbäck => Hasan Ramezani
 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


-- 
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/067.f61d9106b9682106f11e50677a838ed3%40djangoproject.com.

Re: [Django] #31283: "collecstatic --clear" could take ignored patterns into consideration

[Django]

#31283: "collecstatic --clear" could take ignored patterns into consideration
-+-
 Reporter:  Mateusz Papiernik|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Mateusz Papiernik):

 Hi Carlton,

 thanks for your reply. Fair enough, I understand the logic and the
 complexity to merit ratio. How about updating the docs on collectstatic to
 have a remark on that behaviour? It is now not obvious from the flags
 description that `clear` (which actually first clears and then copies, not
 just clears) is using ignore patterns only for the latter part of its job.
 I gathered how it behaves by reading the command code and not just docs.
 I'd be happy to make a patch for that.

-- 
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/066.8cd0d3c27be7151d7307ced811760d16%40djangoproject.com.

Re: [Django] #31283: "collecstatic --clear" could take ignored patterns into consideration

[Django]

#31283: "collecstatic --clear" could take ignored patterns into consideration
-+-
 Reporter:  Mateusz Papiernik|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Carlton Gibson):

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


Comment:

 Hi Mateusz.

 I suspect this change wouldn't merit the code it would take to implement.
 Static root is meant to be a empty folder specifically for Django to put
 files into. Like the case in #22891 with the S3 bucket, putting files in
 there yourself isn't really supported. And I'm sceptical that it's a wide-
 enough use-case to be worth supporting.

 Rather I'd point you to subclassing the `collectstatic.Command` and
 overriding `clear_dir()`. At that point you can implement whatever logic
 you need.

 I hope that makes sense.

-- 
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/066.3f14ba6f8437efa7cb5fd48f85f73f87%40djangoproject.com.

Re: [Django] #31284: Bootstrap-Integration

[Django]

#31284: Bootstrap-Integration
-+--
 Reporter:  RJamesMaier  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Packaging|  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Bootstrap,   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

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


Comment:

 Such integration is out of scope for Django itself. (For one, there are
 many options beyond Bootstrap, such that we could possibly cover them
 all.)

 Check out the `--template` option to the
 [https://docs.djangoproject.com/en/3.0/ref/django-admin/#startproject
 startproject command].

-- 
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/069.0883d4df6b7ce2b05dc745682b355b09%40djangoproject.com.

[Django] #31284: Bootstrap-Integration

[Django]

#31284: Bootstrap-Integration
---+
   Reporter:  RJamesMaier  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  Packaging|Version:  3.0
   Severity:  Normal   |   Keywords:  Bootstrap,
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Upon creating a new django-project, the current released version of
 Bootstrap is added as default to the project dependencies. This can speed
 up development time.

-- 
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/054.96c3684afe278c75532c76b4f8472b6e%40djangoproject.com.

Re: [Django] #16055: Filtering over generic relations with TextField/CharField object_id breaks in postgres

[Django]

#16055: Filtering over generic relations with TextField/CharField object_id 
breaks
in postgres
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  1.3
 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 Nekmo):

 I have made a hack for Django-guardian. In my case, this query is the one
 that fails:


 {{{
 from customers.models import CustomerMemberObjectPermission

 
CustomerMemberObjectPermission.objects.filter(service_api__service__service_name='foo')
 # Raise DatabaseError
 }}}

 My models:

 {{{
 class CustomerMemberObjectPermission(UserObjectPermission):
 objects = CustomerMemberObjectPermissionManager()


 class ServiceApi(Model):
 customer_permissions = GenericRelation(CustomerMemberObjectPermission,
 object_id_field='object_pk',
 related_query_name='service_api')
 }}}

 This is the wrong sql:
 {{{
 SELECT "guardian_userobjectpermission"."id",
 "guardian_userobjectpermission"."permission_id",
 "guardian_userobjectpermission"."content_type_id",
 "guardian_userobjectpermission"."object_pk",
 "guardian_userobjectpermission"."user_id" FROM
 "guardian_userobjectpermission" INNER JOIN "services_serviceapi" ON
 ("guardian_userobjectpermission"."object_pk" = "services_serviceapi"."id"
 AND ("guardian_userobjectpermission"."content_type_id" = 22)) INNER JOIN
 "services_service" ON ("services_serviceapi"."service_id" =
 "services_service"."id") INNER JOIN "customers_customer" ON
 ("services_service"."customer_id" = "customers_customer"."id") WHERE
 "customers_customer"."customer_code" = BCL
 }}}

 The error is in the inner join. Django-guardian uses a field of type
 string for object_pk. But my id is a integer type:
 {{{
 "guardian_userobjectpermission"."object_pk" = "services_serviceapi"."id"
 }}}

 The solution is to use a cast:
 {{{
 CAST("guardian_userobjectpermission"."object_pk" AS integer) =
 "services_serviceapi"."id"
 }}}

 Although I know it is not the best, my solution has been this hack thanks
 to Simon Charette:
 {{{
 class CustomJoin(Join):
 def as_sql(self, compiler, connection):
 sql, params = super(CustomJoin, self).as_sql(compiler, connection)
 sql = sql.replace('"guardian_userobjectpermission"."object_pk"',
 'CAST("guardian_userobjectpermission"."object_pk" AS integer)')
 return sql, params


 class CustomSQLCompiler(SQLCompiler):
 def compile(self, node, select_format=False):
 if isinstance(node, Join):
 node = CustomJoin(
 node.table_name, node.parent_alias, node.table_alias,
 node.join_type,
 node.join_field, node.nullable, node.filtered_relation
 )
 return super(CustomSQLCompiler, self).compile(node, select_format)


 class CustomQuery(Query):
 def get_compiler(self, using=None, connection=None):
 original_compiler = super(CustomQuery,
 self).get_compiler(using=using, connection=connection)
 return CustomSQLCompiler(original_compiler.query,
 original_compiler.connection, original_compiler.using)
 # return super(CustomQuery, self).get_compiler(using=using,
 connection=connection)


 class CustomerMemberObjectPermissionQuerySet(CustomerQuerySet):
 def __init__(self, model=None, query=None, using=None, hints=None):
 if not query:
 query = CustomQuery(model)
 super(CustomerMemberObjectPermissionQuerySet, self).__init__(
 model=model, query=query, using=using, hints=hints
 )


 class CustomerMemberObjectPermissionManager(CustomerManager,
 UserObjectPermissionManager):
 def get_queryset(self):
 return CustomerMemberObjectPermissionQuerySet(self.model,
 using=self._db)
 }}}

-- 
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/067.40cc091896a93c381ca26cf22c8a759b%40djangoproject.com.

Re: [Django] #31271: Logged queries may interpolate parameters in the wrong order on Oracle.

[Django]

#31271: Logged queries may interpolate parameters in the wrong order on Oracle.
-+-
 Reporter:  Hans Aarne Liblik|Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  oracle sql log   | Triage Stage:  Accepted
  debug logging  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"2448b3182c75cce5d22dd80be0fb5cba6104c364" 2448b31]:
 {{{
 #!CommitTicketReference repository=""
 revision="2448b3182c75cce5d22dd80be0fb5cba6104c364"
 [3.0.x] Fixed #31271 -- Preserved ordering when unifying query parameters
 on Oracle.

 This caused misplacing parameters in logged SQL queries.

 Regression in 79065b55a70cd220820a260a1c54851b7be0615a.

 Thanks Hans Aarne Liblik for the report.
 Backport of 2a038521c4eabdc5f6d5026d3dd6d22868e329cd from master
 }}}

-- 
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/073.deb62bc1a85411e61c9d501b227f2a19%40djangoproject.com.

Re: [Django] #31271: Logged queries may interpolate parameters in the wrong order on Oracle.

[Django]

#31271: Logged queries may interpolate parameters in the wrong order on Oracle.
-+-
 Reporter:  Hans Aarne Liblik|Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  oracle sql log   | Triage Stage:  Accepted
  debug logging  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"2a038521c4eabdc5f6d5026d3dd6d22868e329cd" 2a038521]:
 {{{
 #!CommitTicketReference repository=""
 revision="2a038521c4eabdc5f6d5026d3dd6d22868e329cd"
 Fixed #31271 -- Preserved ordering when unifying query parameters on
 Oracle.

 This caused misplacing parameters in logged SQL queries.

 Regression in 79065b55a70cd220820a260a1c54851b7be0615a.

 Thanks Hans Aarne Liblik for the report.
 }}}

-- 
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/073.0c14b9bb9510a0f949d9e52d5aa18117%40djangoproject.com.

Re: [Django] #31278: Schema Editor Action: Pull Field Up

[Django]

#31278: Schema Editor Action: Pull Field Up
-+-
 Reporter:  awiebe   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  pullup schemaeditor  | Triage Stage:
  runpython refactor inheritance |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 I think this kind of composite operation is out-of-scope for the core
 framework.

 What you describe sounds right: create the new field, do a data migration,
 delete the old field.
 But I don't think we'd ship operations to do that for you.

 I might say yes to a documentation example, but, beyond basics (and moving
 to a custom user model) I don't see that we catalogue various migration
 scenarios.
 It would make a good blog topic I think.

 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/064.2fc4044371274244541edf95d34c6ef8%40djangoproject.com.

[Django] #31283: "collecstatic --clear" could take ignored patterns into consideration

[Django]

#31283: "collecstatic --clear" could take ignored patterns into consideration
---+
   Reporter:  maticomp |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  contrib.staticfiles  |Version:  master
   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 calling `collectstatic --clear` all files from `STATIC_ROOT` are
 cleared, as per documentation (see #22891), which is understandable.

 However, `collectstatic` has `--ignore PATTERN` option as well as the
 possibility to configure ignored patterns through `StaticFilesConfig` and
 `ignore_patterns` variable. This is a handy feature that by default
 ignores some auxiliary files **['CVS', '.*', '*~']** during collecting
 process.

 The documentation is lax about that, but `--clear` is not taking those
 patterns into account, while I think it could.

 The most obvious scenario I've run into was with a project that had
 `static` folder commited to the repository with `.gitkeep` and/or
 `.gitignore` file inside, to make sure the directory is present, clearly
 visible from the outset in the project tree and accounted for.

 Running `collectstatic --clear` clears all the directory contents,
 including `.gitkeep` that would be matched by **['CVS', '.*', '*~']** if
 pattern ignores were considered during clearing. As a result, Git will
 start treating this directory as untracked one, and missing `.git*` as a
 uncommited changeset.

 Ideally, the `--clear` option would respect `--ignore` and
 `StaticFilesConfig`, hence the feature proposal. Otherwise, the
 documentation could be a bit more verbose that it's not the case.

-- 
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/051.9b33350df44eb9c881ba4d0f9888ce7f%40djangoproject.com.

Re: [Django] #31228: DISTINCT with GROUP_CONCAT() and multiple expressions raises NotSupportedError on SQLite.

[Django]

#31228: DISTINCT with  GROUP_CONCAT() and multiple expressions raises
NotSupportedError on SQLite.
-+-
 Reporter:  Andy Terra   |Owner:  Hongtao
 |  Ma
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sqlite   | 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:"cbb6531e5bef7ffe0c46d6c44d598d7bcdf9029e" cbb6531]:
 {{{
 #!CommitTicketReference repository=""
 revision="cbb6531e5bef7ffe0c46d6c44d598d7bcdf9029e"
 Fixed #31228 -- Reallowed aggregates to be used with multiple expressions
 and no DISTINCT on SQLite.

 Regression in bc05547cd8c1dd511c6b6a6c873a1bc63417b111.

 Thanks Andy Terra for the report.
 }}}

-- 
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/067.e9590946c6f0658ac2e17ef0b1145060%40djangoproject.com.

Re: [Django] #31228: DISTINCT with GROUP_CONCAT() and multiple expressions raises NotSupportedError on SQLite.

[Django]

#31228: DISTINCT with  GROUP_CONCAT() and multiple expressions raises
NotSupportedError on SQLite.
-+-
 Reporter:  Andy Terra   |Owner:  Hongtao
 |  Ma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite   | 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 felixxm):

 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


-- 
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/067.a71e0be37112204b724ea8ca2a171cb3%40djangoproject.com.

Re: [Django] #31260: Enable cookie security if HTTPS is explicity indicated in settings.

[Django]

#31260: Enable cookie security if HTTPS is explicity indicated in settings.
-+-
 Reporter:  Adam Yala|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  ssl https cookie | Triage Stage:
  settings   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 Sorry 

-- 
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/066.f2c0c8bae0ad22e488ec5293ccfa55b0%40djangoproject.com.

Re: [Django] #31260: Enable cookie security if HTTPS is explicity indicated in settings.

[Django]

#31260: Enable cookie security if HTTPS is explicity indicated in settings.
-+-
 Reporter:  Adam Yala|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  ssl https cookie | Triage Stage:
  settings   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets Please follow triaging guidelines with regards to
 wontfix tickets.]

-- 
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/066.19c8f79da526dc7a82f9c900182dfdf2%40djangoproject.com.

Re: [Django] #31260: Enable cookie security if HTTPS is explicity indicated in settings.

[Django]

#31260: Enable cookie security if HTTPS is explicity indicated in settings.
-+-
 Reporter:  Adam Yala|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  ssl https cookie | Triage Stage:
  settings   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * status:  closed => new
 * resolution:  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/066.a4c6bc5266f73c46e2e0a9edd9df810b%40djangoproject.com.

Re: [Django] #31271: Logged queries may interpolate parameters in the wrong order on Oracle.

[Django]

#31271: Logged queries may interpolate parameters in the wrong order on Oracle.
-+-
 Reporter:  Hans Aarne Liblik|Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  oracle sql log   | Triage Stage:  Accepted
  debug logging  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/12465 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/073.05893ef333076e7c57ce501100b5ff08%40djangoproject.com.

Re: [Django] #31260: Enable cookie security if HTTPS is explicity indicated in settings.

[Django]

#31260: Enable cookie security if HTTPS is explicity indicated in settings.
-+-
 Reporter:  Adam Yala|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  ssl https cookie | Triage Stage:
  settings   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * cc: Adam (Chainz) Johnson (added)


Comment:

 A cleaner alternative I thought of would be to introduce the new value
 `None` as the defaults for these settings, which could mean the secure
 flag is set on the cookies if `request.is_secure()`. The only potential
 breakage is for sites that are served on HTTP and HTTPS, which is
 something of a misconfiguration these days.

-- 
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/066.7f13fb95dd6d0c266bfd1035434fc0ce%40djangoproject.com.

Re: [Django] #31281: Make TestClient run transaction.on_commit actions.

[Django]

#31281: Make TestClient run transaction.on_commit actions.
---+--
 Reporter:  François Freitag   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 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 François Freitag):

 Many thanks for the detailed explanation and the triage.

-- 
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/073.adc294090584cd260e52ed8c274ea2c8%40djangoproject.com.

Re: [Django] #20917: Change the password hashers when testing

[Django]

#20917: Change the password hashers when testing
---+--
 Reporter:  Marc Tamlyn|Owner:  Bruno Alla
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   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 Bruno Alla):

 * has_patch:  0 => 1


-- 
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/066.12f896f87b5bb32fd96452bea1461435%40djangoproject.com.

Re: [Django] #30457: on_commit should be triggered in a TestCase

[Django]

#30457: on_commit should be triggered in a TestCase
+-
 Reporter:  Bernhard Mäder  |Owner:  Swatantra
 Type:  New feature |   Status:  assigned
Component:  Documentation   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  on_commit TestCase  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+-
Changes (by François Freitag):

 * cc: François Freitag (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/064.33b33f9241ed0502e507d61c904607f8%40djangoproject.com.