Re: [Django] #31301: bulk_create with ForeignKey fields with mixed filled/None values fails

2020-02-27 Thread Django
#31301: bulk_create with ForeignKey fields with mixed filled/None values fails
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hans
 |  Aarne Liblik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle sql   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_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/073.4e0749ad4f64ae835c38907f11fe4106%40djangoproject.com.


Re: [Django] #31310: Wrong hint about recursive relationship.

2020-02-27 Thread Django
#31310: Wrong hint about recursive relationship.
-+-
 Reporter:  Matheus Cunha Motta  |Owner:  Matheus
 Type:   |  Cunha Motta
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|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/071.5156a54090bef4ad72ae20025bc0bdaa%40djangoproject.com.


Re: [Django] #31301: bulk_create with ForeignKey fields with mixed filled/None values fails

2020-02-27 Thread Django
#31301: bulk_create with ForeignKey fields with mixed filled/None values fails
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hans
 |  Aarne Liblik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle sql   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hans Aarne Liblik):

 * stage:  Ready for checkin => Accepted


-- 
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.ae0b3930019d3a414d08a07aec3e65c9%40djangoproject.com.


Re: [Django] #31301: bulk_create with ForeignKey fields with mixed filled/None values fails

2020-02-27 Thread Django
#31301: bulk_create with ForeignKey fields with mixed filled/None values fails
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hans
 |  Aarne Liblik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle sql   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hans Aarne Liblik):

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


Comment:

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

-- 
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.4399e6df97646f1fc19f4fd8b88dc0c4%40djangoproject.com.


Re: [Django] #31307: Arrow display error in filter_horizontal field when width less than 1024px

2020-02-27 Thread Django
#31307: Arrow display error in filter_horizontal field when width less than 
1024px
-+-
 Reporter:  007  |Owner:  007
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  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:  1
-+-

Comment (by felixxm):

 This patch doesn't qualify for a backport per our backporting policy, see
 https://docs.djangoproject.com/en/3.0/internals/release-process/ for more
 details.

-- 
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.683a5ebe2360b4faae0546b159e3459b%40djangoproject.com.


Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

2020-02-27 Thread Django
#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sanskar Jaiswal):

 Unfortunately, I don't think this is the case here. Here is the migration
 file that was generated: https://pastebin.com/nSN5HNW8

-- 
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.66e27ac0eb7d48a9185fc76be8d67447%40djangoproject.com.


Re: [Django] #31307: Arrow display error in filter_horizontal field when width less than 1024px

2020-02-27 Thread Django
#31307: Arrow display error in filter_horizontal field when width less than 
1024px
-+-
 Reporter:  007  |Owner:  007
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  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:  1
-+-

Comment (by 007):

 This problem also occurs in 2.2 and 3.0. What do I need to do to merge the
 changes into stable/2.2.x and stable/3.0.x

-- 
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.76902213ae457023bdd09e6ace1196a3%40djangoproject.com.


[Django] #31315: Closing all connections in function tagged with @transaction_atomic or transaction atomic block breaks atomicity

2020-02-27 Thread Django
#31315: Closing all connections in function tagged with @transaction_atomic or
transaction atomic block breaks atomicity
-+-
   Reporter:  David  |  Owner:  nobody
  Eling  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.1
  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  |
-+-
 Bug might be related to https://code.djangoproject.com/ticket/21239

 If you use the transaction atomic tag on a function ala
 {{{
 @transaction.atomic
 def post(self, request):
Machine.objects.create(name="a")
connections.close_all()
connection.connect()
list(Machine.objects.all())
Machine.objects.create(name="b")

return JsonResponse({})
 }}}
 b will exist but a will not.

 Now the code above is way simplified compared to what actually caused the
 bug in my codebase but it replicates the issue (although it seems very
 arbitrary in its current form) The codebase in question is very complex
 and involves multiple databases on different machines, this is my best
 attempt at boiling it down to what bits caused what. So it calls
 connections.close_all() and then reopens the connection to the current db
 then does a query then later down the line it does a create.

 The issue will occur if you do this instead
 {{{
 def post(self, request):
with transaction.atomic():
   Machine.objects.create(name="a")
   connections.close_all()
   connection.connect()
   list(Machine.objects.all())
   Machine.objects.create(name="b")

 return JsonResponse({})
 }}}

 During further testing it looks like swapping connections.close_all() with
 connection.close() still causes the issue to occur, so maybe the fix in
 the issue linked above did not fix the issue all the way.

 It's possible this bug is only happening due to the code exploiting some
 loophole or something but I just thought I would put this here just in
 case it might be a real problem that needs to be fixed. Within our code
 base we had to isolate the offending bit and do it before entering the
 atomic block.

 This is my first time reporting a django bug so I apologize for any
 issues.

-- 
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/050.33406eaf6c6d90305b43e12ef2b87b37%40djangoproject.com.


Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

2020-02-27 Thread Django
#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > The method is adding four operations to the generated_operations, but
 only three of them show up in the actual migrations file. Am I missing
 something here?

 Yes. The optimizer is likely able to optimize one of the `RemoveField`
 into its corresponding `DeleteModel` but not the other one. The reduction
 operation takes place in `RemoveField.reduce`.

 See #26720 (https://github.com/django/django/pull/7999) and
 https://code.djangoproject.com/ticket/24424#comment:35 for more details
 about 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.86e84ba29277542e595ae46de01c6bb4%40djangoproject.com.


Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

2020-02-27 Thread Django
#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
-+-
 Reporter:  Panagis  |Owner:  Rohit Jha
  Alisandratos   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration,optimizer  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sanskar Jaiswal):

 Upon doing some more debugging, I found some peculiar behaviour. I tried
 to print `generated_operations` at the end of the function
 `generate_deleted_models's `.  This is the output:  `{'some':
 [, , ,
 ]}`.

 The method is adding four operations to the `generated_operations`, but
 only three of them show up in the actual migrations file. Am I missing
 something here?

-- 
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.85cc6a764ab20db417e4abe707aac9ce%40djangoproject.com.


Re: [Django] #31314: makemessages doesn't provide feedback when no locale is specified

2020-02-27 Thread Django
#31314: makemessages doesn't provide feedback when no locale is specified
-+-
 Reporter:  Cristóbal Mackenzie  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  3.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


-- 
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.5e63691f986f6e2c0a5b1c63dc5d8dbf%40djangoproject.com.


Re: [Django] #31312: Wrong MySQL query generation after version 3.0.3.

2020-02-27 Thread Django
#31312: Wrong MySQL query generation after version 3.0.3.
-+-
 Reporter:  Ricardo Helou|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  mysql ORM| Triage Stage:  Ready for
  DateTimeField DurationField|  checkin
  regression |
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:"94e192a580374259d9e52432f007fd2b49a8672d" 94e192a5]:
 {{{
 #!CommitTicketReference repository=""
 revision="94e192a580374259d9e52432f007fd2b49a8672d"
 [3.0.x] Refs #31312 -- Fixed FTimeDeltaTests.test_date_case_subtraction()
 test.

 Follow up to 16cacdcb3f7856df5454b648503374de150fa245.
 }}}

-- 
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.6e5822983907d0c56d3a1e2f60300ef8%40djangoproject.com.


Re: [Django] #15619: Logout link should be protected

2020-02-27 Thread Django
#15619: Logout link should be protected
-+-
 Reporter:  Alexey Boriskin  |Owner:  René
 |  Fleschenberg
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by René Fleschenberg):

 * has_patch:  0 => 1


Comment:

 As a first step, I suggest deprecating logout via GET.

 PR: https://github.com/django/django/pull/12504

-- 
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/062.c95c875b29384d1317e81de6396493a2%40djangoproject.com.


Re: [Django] #31295: Avoid Select widget triggering additional query when using ModelChoiceIterator.

2020-02-27 Thread Django
#31295: Avoid Select widget triggering additional query when using
ModelChoiceIterator.
--+
 Reporter:  Aurélien Pardon   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  2.2
 Severity:  Normal|   Resolution:
 Keywords:  Model | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Aurélien Pardon):

 Hi Carlton,

 Thanks for your answer. I'm afraid the code you proposed won't work, I
 just tested it. I will try to think about a solution.

 The difficulty is that when rendering the widget, we need '''before
 rendering the options''' (and thus iterate over the
 ModelChoiceFieldIterator/fetch the data from the DB) if the HTML attribute
 {{{required}}} should be used.
 And we also don't want to cache the query, for memory usage performance.

 I think of two different solutions :
  * defer the presence of the {{{required}}} attribute after the iteration
 for the . During this iteration, we store the fact that the first
 option allows or not the {{{required}}} attribute. After the rendering of
 the options, we put afterwards (or not) the {{{required}}} attribute.
 Maybe with a placeholder replaced by a regexp? I find this quite ugly.
  *  Maybe the ModelChoiceIterator may cache it's first value? It should
 not take a lot of memory. I don't think it will work because I assume
 that, for efficiency, multiple rows are fetched from the database, if you
 want to cache the first value for an ulterior iteration, you also have to
 cache the rest of the rows until  are iterated.

-- 
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/065.a0ce695521035444e58fe2d59a6dc579%40djangoproject.com.


Re: [Django] #31064: Migration doesn't detect precision changes in fields that ManyToMany points to.

2020-02-27 Thread Django
#31064: Migration doesn't detect precision changes in fields that ManyToMany 
points
to.
-+
 Reporter:  zapililirad  |Owner:  Dart
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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 Simon Charette):

 Sanskar it's possible the issue is only present on SQLite because it deals
 with column alterations in a different way since it doesn't support `ALTER
 TABLE`.

 The idea is that is you have the follow models

 {{{#!python
 class Author(models.Model):
 pass

 class Book(models.Model):
 isbn = models.CharField(max_length=10, primary_key=True)
 authors = models.ManyToManyField(Author)
 }}}

 Django will automatically created a `trough` model

 {{{#!python
 # Automatically created by Django
 class Book_Authors(models.Model):
 book= models.ForeignKey(Book)  # This is a
 models.CharField(max_length=10) referring to Book.isbn
 author = models.ForeignKey(Author)
 }}}

 Now the reported issue is that if you If you change `Book.isbn.max_length`
 to 13 the `Book_Authors.book` field in the intermediary table that backs
 the `Book.authors` many-to-many relationship currently doesn't change to
 `max_length=13`.

 
[https://github.com/django/django/blob/a4881f5e5d7ee38b7e83301331a0b4962845ef8a/django/db/backends/base/schema.py#L757
 The re-pointing logic currently lives] in
 `BaseDatabaseSchemaEditor._alter_field` but it's possible that it's only
 
[https://github.com/django/django/blob/a4881f5e5d7ee38b7e83301331a0b4962845ef8a/django/db/backends/sqlite3/schema.py#L348-L365
 an issue with SQLite schema editor].

 By a quick glance at the code it looks like it could be a SQLite only
 issue due to
 
[https://github.com/django/django/blob/a4881f5e5d7ee38b7e83301331a0b4962845ef8a/django/db/backends/sqlite3/schema.py#L364
 this particular line].

-- 
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.157e702251d3b05395e99a06f7595c05%40djangoproject.com.


Re: [Django] #31293: MultiPartParser support double quotes

2020-02-27 Thread Django
#31293: MultiPartParser support double quotes
--+
 Reporter:  007   |Owner:  007
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  HTTP handling |  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 Carlton Gibson):

 * stage:  Ready for checkin => Accepted


Comment:

 GitHub is momentarily dying on me. I have small edits to push. I will try
 again later.

-- 
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.28f2259fbf8962d9196ab37e5e270bc4%40djangoproject.com.


Re: [Django] #31307: Arrow display error in filter_horizontal field when width less than 1024px

2020-02-27 Thread Django
#31307: Arrow display error in filter_horizontal field when width less than 
1024px
-+-
 Reporter:  007  |Owner:  007
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  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:  1
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"a4881f5e5d7ee38b7e83301331a0b4962845ef8a" a4881f5e]:
 {{{
 #!CommitTicketReference repository=""
 revision="a4881f5e5d7ee38b7e83301331a0b4962845ef8a"
 Fixed #31307 -- Fixed filter_horizontal add/remove SVG :hover positioning.
 }}}

-- 
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.b0f35bcbc138a5c22dcef8a86a79a3fd%40djangoproject.com.


Re: [Django] #31293: MultiPartParser support double quotes

2020-02-27 Thread Django
#31293: MultiPartParser support double quotes
-+-
 Reporter:  007  |Owner:  007
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   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 Carlton Gibson):

 * stage:  Accepted => Ready for checkin


Comment:

 PR looks correct. Thank you.

-- 
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.096fae2d45f009638b17c6a451bf6093%40djangoproject.com.


Re: [Django] #31311: Unneeded escape sequences in character classes

2020-02-27 Thread Django
#31311: Unneeded escape sequences in character classes
--+
 Reporter:  Kimball Leavitt   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  3.0
 Severity:  Normal|   Resolution:
 Keywords:  validators, regex | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Kimball Leavitt):

 * stage:  Ready for checkin => Accepted


Old description:

> There are at least three places in the regex in django/core/validators.py
> that have unnecessary escape sequences inside of character classes:
>
> -
> https://github.com/django/django/blob/master/django/core/validators.py#L68
> -
> https://github.com/django/django/blob/master/django/core/validators.py#L85
> -
> https://github.com/django/django/blob/master/django/core/validators.py#L162

New description:

 There are at least three places in the regex in django/core/validators.py
 that have unnecessary escape sequences inside of character classes:

 -
 https://github.com/django/django/blob/master/django/core/validators.py#L68
 -
 https://github.com/django/django/blob/master/django/core/validators.py#L85
 -
 https://github.com/django/django/blob/master/django/core/validators.py#L166

--

Comment:

 Thanks for the review. I submitted a PR for this yesterday -
 https://github.com/django/django/pull/12498/files.

 You're right, the third one was wrong. I made the fix first, then
 submitted the ticket, so I hastily grabbed the wrong line. I changed it so
 it's correct
 (https://github.com/django/django/blob/master/django/core/validators.py#L166).

-- 
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/063.f337aa320ddcd903652657278f830563%40djangoproject.com.


Re: [Django] #31311: Unneeded escape sequences in character classes

2020-02-27 Thread Django
#31311: Unneeded escape sequences in character classes
-+-
 Reporter:  Kimball Leavitt  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  validators, regex| 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):

 * stage:  Accepted => Ready for checkin


Comment:

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

 Yep, this looks fine. Thank you.

-- 
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/063.a35d2f11b17060261d122e6ca58b754c%40djangoproject.com.


Re: [Django] #31311: Unneeded escape sequences in character classes

2020-02-27 Thread Django
#31311: Unneeded escape sequences in character classes
--+
 Reporter:  Kimball Leavitt   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  3.0
 Severity:  Normal|   Resolution:
 Keywords:  validators, regex | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Kimball Leavitt):

 * 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/063.fba942d06816a815b5a95cbd71e946ac%40djangoproject.com.


Re: [Django] #31295: Avoid Select widget triggering additional query when using ModelChoiceIterator. (was: Avoid Select widget triggering additional query in ModelChoiceIterator.)

2020-02-27 Thread Django
#31295: Avoid Select widget triggering additional query when using
ModelChoiceIterator.
--+
 Reporter:  Aurélien Pardon   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  2.2
 Severity:  Normal|   Resolution:
 Keywords:  Model | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  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/065.f8785b849d2616848ed6331f95045928%40djangoproject.com.


Re: [Django] #15619: Logout link should be protected

2020-02-27 Thread Django
#15619: Logout link should be protected
-+-
 Reporter:  Alexey Boriskin  |Owner:  René
 |  Fleschenberg
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by René Fleschenberg):

 * owner:  Ramiro Morales => René Fleschenberg
 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * needs_docs:  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/062.dd3d70e7885f82e60a9e01001e57b145%40djangoproject.com.


Re: [Django] #31295: Avoid Select widget triggering additional query in ModelChoiceIterator.

2020-02-27 Thread Django
#31295: Avoid Select widget triggering additional query in ModelChoiceIterator.
--+
 Reporter:  Aurélien Pardon   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  2.2
 Severity:  Normal|   Resolution:
 Keywords:  Model | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

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


-- 
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/065.dce8cb382bffa5a830afb869c54577fa%40djangoproject.com.


Re: [Django] #31295: Avoid Select widget triggering additional query in ModelChoiceIterator. (was: required ModelChoiceField makes duplicate (cursor) queries to the database)

2020-02-27 Thread Django
#31295: Avoid Select widget triggering additional query in ModelChoiceIterator.
-+-
 Reporter:  Aurélien Pardon  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Model| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Hi Aurélien,

 > Maybe there's a way of performing that Select.use_required_attribute()
 check without fetching the first item...?

 It strikes me that we might be able to do this. This patch passes the
 existing tests:

 {{{
 diff --git a/django/forms/widgets.py b/django/forms/widgets.py
 index 40ac1d3162..5bc040065a 100644
 --- a/django/forms/widgets.py
 +++ b/django/forms/widgets.py
 @@ -696,7 +696,16 @@ class Select(ChoiceWidget):
  if self.allow_multiple_selected:
  return use_required_attribute

 -first_choice = next(iter(self.choices), None)
 +iterator = iter(self.choices)
 +# Avoid an extra query if we have a ModelChoiceIterator.
 +try:
 +empty_label = iterator.field.empty_label
 +except AttributeError:
 +pass
 +else:
 +if empty_label is not None:
 +return use_required_attribute
 +first_choice = next(iterator, None)
  return use_required_attribute and first_choice is not None and
 self._choice_has_empty_value(first_choice)
 }}}

 So with a further test asserting number of queries, a think about any edge
 cases, and a tidy up, I think we can evaluate a patch on that basis.

 Thanks for your input!

-- 
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/065.714af7ae2fed8946e9efb04c18a227bf%40djangoproject.com.


Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

2020-02-27 Thread Django
#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  Josef
 Type:   |  Rousek
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  HTML,Select,wdiget,ModelChoiceField|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  1 => 0


Comment:

 Follow-up in #31295.

-- 
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.01409c3ac01053b95be6cbbbf78cac22%40djangoproject.com.


Re: [Django] #31314: makemessages doesn't provide feedback when no locale is specified

2020-02-27 Thread Django
#31314: makemessages doesn't provide feedback when no locale is specified
-+-
 Reporter:  cmackenziek  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  3.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n | 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 cmackenziek:

Old description:

> makemessages requires that one of three flags be passed to specify
> locales for message building: `--locale` to explicitly specify locales,
> `--exclude` to specify locales to exclude, or  `--all` to build message
> files for all locales.
>
> When non of these flags are present, the command doesn't show any errors
> for the user. According to the source code, it should raise
> `CommandError`, but that never happens because of a bug in an `if`
> statement that checks if a locale has been specified.
>
> I've already fixed this in my fork and will submit a small PR.

New description:

 makemessages requires that one of three flags be passed to specify locales
 for message building: `--locale` to explicitly specify locales,
 `--exclude` to specify locales to exclude, or  `--all` to build message
 files for all locales.

 When non of these flags are present, the command doesn't show any errors
 for the user. According to the source code, it should raise
 `CommandError`, but that never happens because of a bug in an `if`
 statement that checks if a locale has been specified.

 I've already fixed this in my fork and have submitted a small PR.

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

 Please point out if there are any other necessary steps to move this
 forward. 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/069.14f79c5aa4715732b65e9b56203619c5%40djangoproject.com.


[Django] #31314: makemessages doesn't provide feedback when no locale is specified

2020-02-27 Thread Django
#31314: makemessages doesn't provide feedback when no locale is specified
-+-
   Reporter: |  Owner:  nobody
  cmackenziek|
   Type:  Bug| Status:  new
  Component:  Core   |Version:  3.0
  (Management commands)  |
   Severity:  Normal |   Keywords:  i18n
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 makemessages requires that one of three flags be passed to specify locales
 for message building: `--locale` to explicitly specify locales,
 `--exclude` to specify locales to exclude, or  `--all` to build message
 files for all locales.

 When non of these flags are present, the command doesn't show any errors
 for the user. According to the source code, it should raise
 `CommandError`, but that never happens because of a bug in an `if`
 statement that checks if a locale has been specified.

 I've already fixed this in my fork and will submit a small 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/054.effd1021eff8a85cb860c967db9d7b93%40djangoproject.com.


Re: [Django] #31301: bulk_create with ForeignKey fields with mixed filled/None values fails

2020-02-27 Thread Django
#31301: bulk_create with ForeignKey fields with mixed filled/None values fails
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hans
 |  Aarne Liblik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle sql   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by felixxm):

 Hans, Please remember to add also `SmallAutoField` and `BigAutoField`.

-- 
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.1d5f38103537164fdc8b471f135b9b77%40djangoproject.com.


Re: [Django] #31251: QuerySet.annotate() crashes when grouping by OuterRef().

2020-02-27 Thread Django
#31251: QuerySet.annotate() crashes when grouping by OuterRef().
-+-
 Reporter:  Oliver Ford  |Owner:  Rohit Jha
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db,outerref,group| Triage Stage:  Ready for
  by,subquery,annotate   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"486786c4c480f5b1ae3ac1c95858b03699b9eb9c" 486786c]:
 {{{
 #!CommitTicketReference repository=""
 revision="486786c4c480f5b1ae3ac1c95858b03699b9eb9c"
 Fixed #31251 -- Disabled grouping by OuterRef() annotation.
 }}}

-- 
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.56471f3171636948e1c6d36f97b3835e%40djangoproject.com.


Re: [Django] #31307: Arrow display error in filter_horizontal field when width less than 1024px

2020-02-27 Thread Django
#31307: Arrow display error in filter_horizontal field when width less than 
1024px
-+-
 Reporter:  007  |Owner:  007
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Carlton Gibson):

 * 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/064.6f2c7911a9100ede7d81240390d41ec3%40djangoproject.com.


Re: [Django] #31307: Arrow display error in filter_horizontal field when width less than 1024px

2020-02-27 Thread Django
#31307: Arrow display error in filter_horizontal field when width less than 
1024px
-+-
 Reporter:  007  |Owner:  007
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   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:  1
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  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/064.bea53c2fd965b0994a8f67bd70642396%40djangoproject.com.


Re: [Django] #31310: Wrong hint about recursive relationship. (was: Wrong hint about recursive relationship)

2020-02-27 Thread Django
#31310: Wrong hint about recursive relationship.
-+-
 Reporter:  Matheus Cunha Motta  |Owner:  Matheus
 Type:   |  Cunha Motta
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => Matheus Cunha Motta
 * status:  new => assigned
 * version:  3.0 => master
 * needs_tests:  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/071.aa0e82dc914a366e090483fd8181f12e%40djangoproject.com.


Re: [Django] #31064: Migration doesn't detect precision changes in fields that ManyToMany points to.

2020-02-27 Thread Django
#31064: Migration doesn't detect precision changes in fields that ManyToMany 
points
to.
-+
 Reporter:  zapililirad  |Owner:  Dart
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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 Sanskar Jaiswal):

 I have not been able to reproduce this on my machine. Could you kindly
 provide me with a minimal code sample, so that I could get a hint of
 what's going wrong here?
 Replying to [comment:1 felixxm]:
 > Thanks I was able to reproduce this issue on SQLite (`ForeignKey`s are
 not affected).

-- 
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.27679737cdd5d34e973c39fbd50cc52f%40djangoproject.com.


Re: [Django] #31032: Document the minimal supported version of browsers for the admin

2020-02-27 Thread Django
#31032: Document the minimal supported version of browsers for the admin
-+-
 Reporter:  Claude Paroz |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * 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/065.755e1f1e222a11dd2584bab2bf880a68%40djangoproject.com.


Re: [Django] #31185: fields.E310-E311 should take into account UniqueConstraints without conditions.

2020-02-27 Thread Django
#31185: fields.E310-E311 should take into account UniqueConstraints without
conditions.
-+-
 Reporter:  Pavel Garkin |Owner:  Ahmad
 |  Abdallah
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  UniqueConstraint | Triage Stage:  Ready for
  unique_together E310 E311  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"5bf28ac2ed17773214bd6c7796ef356067c9fa91" 5bf28ac2]:
 {{{
 #!CommitTicketReference repository=""
 revision="5bf28ac2ed17773214bd6c7796ef356067c9fa91"
 Fixed #31185 -- Fixed detecting of unique fields in
 ForeignKey/ForeignObject checks when using Meta.constraints.
 }}}

-- 
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.1fe0bee4ebe5ee5bc56f5e6f9f6529a0%40djangoproject.com.


Re: [Django] #31185: fields.E310-E311 should take into account UniqueConstraints without conditions.

2020-02-27 Thread Django
#31185: fields.E310-E311 should take into account UniqueConstraints without
conditions.
-+-
 Reporter:  Pavel Garkin |Owner:  Ahmad
 |  Abdallah
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Ready for
  unique_together E310 E311  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

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


Re: [Django] #31301: bulk_create with ForeignKey fields with mixed filled/None values fails

2020-02-27 Thread Django
#31301: bulk_create with ForeignKey fields with mixed filled/None values fails
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hans
 |  Aarne Liblik
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle sql   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Marti Raudsepp):

 * cc: Marti Raudsepp (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/073.1c414ddd42749ecc9e457dc26866c5b3%40djangoproject.com.


Re: [Django] #31032: Document the minimal supported version of browsers for the admin

2020-02-27 Thread Django
#31032: Document the minimal supported version of browsers for the admin
-+-
 Reporter:  Claude Paroz |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   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:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 [https://github.com/django/django/pull/12502 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/065.f38389dee39462f5791774e22747da5c%40djangoproject.com.


Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

2020-02-27 Thread Django
#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  Josef
 Type:   |  Rousek
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  HTML,Select,wdiget,ModelChoiceField|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aurélien Pardon):

 * cc: Aurélien Pardon (added)
 * needs_better_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/068.5ee44ed72d316e44faef895a8348a7d9%40djangoproject.com.


Re: [Django] #27370: Django's Select widget adds a required="required" attribute, even if created with empty_label=True

2020-02-27 Thread Django
#27370: Django's Select widget adds a required="required" attribute, even if
created with empty_label=True
-+-
 Reporter:  alexpirine   |Owner:  Josef
 Type:   |  Rousek
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  HTML,Select,wdiget,ModelChoiceField|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aurélien Pardon):

 There is a huge performance regression as a side-effect of
 [changeset:"aaecf038cae61f114db396f74e06759c95f21e93" aaecf038]. For
 {{{ModelChoiceField}}} with {{{empty_label=None}}}, it doubles the queries
 to the database.

 With this {{{simple_app/models.py}}}:
 {{{#!python
 from django.db import models

 class MyModel(models.Model):
 my_field = models.CharField(max_length=1)
 }}}

 the following code:
 {{{#!python
 from django import forms
 from simple_app.models import MyModel

 class MyForm(forms.Form):
 my_form_field = forms.ModelChoiceField(MyModel.objects.all(),
 empty_label=None)

 MyForm().as_ul()
 }}}

 makes two times the same request to the database:
 {{{#!python
 >>> from django.db import connection
 >>> from django.db import reset_queries
 >>> reset_queries()
 >>> _ = MyForm().as_ul()
 >>> connection.queries
 [{'sql': 'SELECT "simple_app_mymodel"."id",
 "simple_app_mymodel"."my_field" FROM "simple_app_mymodel"',
   'time': '0.000'},
  {'sql': 'SELECT "simple_app_mymodel"."id",
 "simple_app_mymodel"."my_field" FROM "simple_app_mymodel"',
   'time': '0.000'}]
 }}}

 Before this commit, it only makes one request (as intended IMO):
 {{{#!python
 >>> from django.db import connection
 >>> from django.db import reset_queries
 >>> reset_queries()
 >>> _ = MyForm().as_ul()
 >>> connection.queries
 [{'sql': 'SELECT "simple_app_mymodel"."id",
 "simple_app_mymodel"."my_field" FROM "simple_app_mymodel"',
   'time': '0.000'}]
 }}}

-- 
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.4e08f4ab70684d6fd783d10b66115ace%40djangoproject.com.


Re: [Django] #31032: Document the minimal supported version of browsers for the admin

2020-02-27 Thread Django
#31032: Document the minimal supported version of browsers for the admin
-+-
 Reporter:  Claude Paroz |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * owner:  Ata Öz => Carlton Gibson


-- 
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/065.7ed15aa1dac45acae34ff88975cfbf83%40djangoproject.com.


Re: [Django] #31312: Wrong MySQL query generation after version 3.0.3.

2020-02-27 Thread Django
#31312: Wrong MySQL query generation after version 3.0.3.
-+-
 Reporter:  rick2ricks   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  mysql ORM| Triage Stage:  Ready for
  DateTimeField DurationField|  checkin
  regression |
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:"16cacdcb3f7856df5454b648503374de150fa245" 16cacdc]:
 {{{
 #!CommitTicketReference repository=""
 revision="16cacdcb3f7856df5454b648503374de150fa245"
 [3.0.x] Fixed #31312 -- Properly ordered temporal subtraction params on
 MySQL.

 Regression in 9bcbcd599abac91ea853b2fe10b784ba32df043e.

 Thanks rick2ricks for the report.

 Backport of 41ebe60728a15aa273f4d70de92f5246a89c3d4e 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/068.3a2a70df945c2dcf5389fdbfbb2a20d5%40djangoproject.com.


Re: [Django] #31312: Wrong MySQL query generation after version 3.0.3.

2020-02-27 Thread Django
#31312: Wrong MySQL query generation after version 3.0.3.
-+-
 Reporter:  rick2ricks   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  mysql ORM| Triage Stage:  Ready for
  DateTimeField DurationField|  checkin
  regression |
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:"41ebe60728a15aa273f4d70de92f5246a89c3d4e" 41ebe607]:
 {{{
 #!CommitTicketReference repository=""
 revision="41ebe60728a15aa273f4d70de92f5246a89c3d4e"
 Fixed #31312 -- Properly ordered temporal subtraction params on MySQL.

 Regression in 9bcbcd599abac91ea853b2fe10b784ba32df043e.

 Thanks rick2ricks 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/068.993c37a71d46e2f6296e6c7d56a4ad33%40djangoproject.com.