date:20200226

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

2020-02-26 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:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

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


Comment:

 The third example here (L162) is:

 {{{
 r'((?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+)(?:[A-Z0-9-]{2,63}(?https://code.djangoproject.com/ticket/31311#comment:1>
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.431c84eb0e730a988dc3c60583995339%40djangoproject.com.

Re: [Django] #27017: Why doesn't Django's Model.save() save only the dirty fields by default? And how can I do that if I want?

2020-02-26 Thread Django

#27017: Why doesn't Django's Model.save() save only the dirty fields by default?
And how can I do that if I want?
-+-
 Reporter:  prajnamort   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andreas Bergström):

 There is the django-dirtyfields that will at least tell you if a model is
 dirty and what fields that's dirty, but it won't do the saving...
 https://github.com/romgar/django-dirtyfields

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

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

2020-02-26 Thread Django

#31312: Wrong MySQL query generation after version 3.0.3.
-+-
 Reporter:  rick2ricks   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 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 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/068.6baa1cee9c694a37e3510937cc1988e6%40djangoproject.com.

Re: [Django] #31313: Error in Example in Model field reference > Field.choices > Enumeration types

2020-02-26 Thread Django

#31313: Error in Example in Model field reference > Field.choices > Enumeration
types
-+-
 Reporter:  Lee Hopkins  |Owner:  Andrey
 Type:   |  Doroschenko
  Cleanup/optimization   |   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 Mariusz Felisiak ):

 In [changeset:"59ac25c93b228cd4ef34d4f36fbfbab3d9f6b4ad" 59ac25c9]:
 {{{
 #!CommitTicketReference repository=""
 revision="59ac25c93b228cd4ef34d4f36fbfbab3d9f6b4ad"
 [3.0.x] Fixed #31313 -- Fixed is_upperclass() example in enumeration types
 docs.

 Backport of f1016814d84b1423cfe0df85644c9870a6bc6b41 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.ef40491333d7fdc4f57439df02dad3b9%40djangoproject.com.

Re: [Django] #31313: Error in Example in Model field reference > Field.choices > Enumeration types

2020-02-26 Thread Django

#31313: Error in Example in Model field reference > Field.choices > Enumeration
types
-+-
 Reporter:  Lee Hopkins  |Owner:  Andrey
 Type:   |  Doroschenko
  Cleanup/optimization   |   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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"f1016814d84b1423cfe0df85644c9870a6bc6b41" f101681]:
 {{{
 #!CommitTicketReference repository=""
 revision="f1016814d84b1423cfe0df85644c9870a6bc6b41"
 Fixed #31313 -- Fixed is_upperclass() example in enumeration types docs.
 }}}

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

Re: [Django] #31313: Error in Example in Model field reference > Field.choices > Enumeration types

2020-02-26 Thread Django

#31313: Error in Example in Model field reference > Field.choices > Enumeration
types
-+-
 Reporter:  Lee Hopkins  |Owner:  Andrey
 Type:   |  Doroschenko
  Cleanup/optimization   |   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):

 * 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/066.74bb10321ed0c98cf94a934eac0470b8%40djangoproject.com.

Re: [Django] #31313: Error in Example in Model field reference > Field.choices > Enumeration types

2020-02-26 Thread Django

#31313: Error in Example in Model field reference > Field.choices > Enumeration
types
-+-
 Reporter:  Lee Hopkins  |Owner:  Andrey
 Type:   |  Doroschenko
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => Andrey Doroschenko
 * status:  new => assigned
 * severity:  Normal => Release blocker


Comment:

 [https://github.com/django/django/pull/12499 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.762b107c31c6b419a121562b4eedff00%40djangoproject.com.

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

2020-02-26 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 Simon Charette):

 * owner:  (none) => Hans Aarne Liblik
 * 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/073.3b7107462531a882e3f94c9ad0f4fc56%40djangoproject.com.

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

2020-02-26 Thread Django

#31301: bulk_create with ForeignKey fields with mixed filled/None values fails
-+-
 Reporter:  Hans Aarne Liblik|Owner:  (none)
 Type:  Bug  |   Status:  new
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 Hardik Patel):

 * owner:  Hardik Patel => (none)
 * status:  assigned => new


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.03a235c0a27b06b192ae1a992ad4274e%40djangoproject.com.

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

2020-02-26 Thread Django

#31301: bulk_create with ForeignKey fields with mixed filled/None values fails
-+-
 Reporter:  Hans Aarne Liblik|Owner:  Hardik
 |  Patel
 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 Hardik Patel):

 Replying to [comment:3 Hans Aarne Liblik]:
 > Any progress on this? If not, I can take over.
 It is looking harder than I expected. I am just a newbie. I will come back
 later. Feel free to take over

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

Re: [Django] #31313: Error in Example in Model field reference > Field.choices > Enumeration types

2020-02-26 Thread Django

#31313: Error in Example in Model field reference > Field.choices > Enumeration
types
--+
 Reporter:  Lee Hopkins   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.0
 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 Simon Charette):

 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * 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/066.75b4065a29c1f143b023c6c31dd3c7c0%40djangoproject.com.

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

2020-02-26 Thread Django

#31310: Wrong hint about recursive relationship
-+-
 Reporter:  Matheus Cunha Motta  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Simon Charette):

 * 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/071.022a6e9154737fdd6b4c64a44751a1f4%40djangoproject.com.

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

2020-02-26 Thread Django

#31312: Wrong MySQL query generation after version 3.0.3.
-+-
 Reporter:  rick2ricks   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysql ORM| Triage Stage:  Accepted
  DateTimeField DurationField|
  regression |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

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

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

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

2020-02-26 Thread Django

#31312: Wrong MySQL query generation after version 3.0.3.
-+-
 Reporter:  rick2ricks   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysql ORM| Triage Stage:
  DateTimeField DurationField|  Unreviewed
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * owner:  nobody => Simon Charette
 * status:  new => assigned
 * severity:  Normal => Release blocker


Comment:

 Looks like I inverted `lhs_params` and `rhs_params`
 
[https://github.com/django/django/commit/02cda09b13e677db01863fa0a7112dba631b9c5c
 #diff-a7516854a0eab5c74e491a6dc8249c2dR290 on this 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/068.71016f54f4794c70a0375cc8b983533e%40djangoproject.com.

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

2020-02-26 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):

 Sankar it's bit more complicated than that.

 If you remove two interelated models (or any model cycle) at the same time
 fields have to be removed to break the cycle before hand

 Given

 {{{#!python
 class Foo(models.Model):
 bar = models.ForeignKey('Bar')

 class Bar(models.Model):
 foo = models.ForeignKey(Foo)
 }}}

 Removing both models and running `makemigrations` must generate a
 migration that either drop `Foo.bar` or `Bar.foo` before proceeding with
 the model removal. I'm pretty sure we have auto-detector tests for this
 case.

 The optimizer likely need to be adjusted somehow but I doubt
 `generate_deleted_models`'s generation of `RemoveField` is to blame.

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

Re: [Django] #29129: Child model updates parent model with empty fields making an extra query in multi-inheritance when parent model has custom PK

2020-02-26 Thread Django

#29129: Child model updates parent model with empty fields making an extra 
query in
multi-inheritance when parent model has custom PK
-+-
 Reporter:  user0007 |Owner:  Abhijeet
 |  Viswa
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (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 Abhijeet Viswa):

 * has_patch:  0 => 1


Comment:

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

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

2020-02-26 Thread Django

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

 * cc: Rohit Jha (added)
 * needs_tests:  1 => 0


Comment:

 Tests => https://github.com/django/django/pull/12489

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

[Django] #31313: Error in Example in Model field reference > Field.choices > Enumeration types

2020-02-26 Thread Django

#31313: Error in Example in Model field reference > Field.choices > Enumeration
types
-+
   Reporter:  lhopkins   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  3.0
   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  |
-+
 The example in the new Field.choices Enumeration types documentation has
 an error:

 {{{
 class Student(models.Model):

 class YearInSchool(models.TextChoices):
 FRESHMAN = 'FR', _('Freshman')
 SOPHOMORE = 'SO', _('Sophomore')
 JUNIOR = 'JR', _('Junior')
 SENIOR = 'SR', _('Senior')
 GRADUATE = 'GR', _('Graduate')

 year_in_school = models.CharField(
 max_length=2,
 choices=YearInSchool.choices,
 default=YearInSchool.FRESHMAN,
 )

 def is_upperclass(self):
 return self.year_in_school in {YearInSchool.JUNIOR,
 YearInSchool.SENIOR}
 }}}

 The method `is_upperclass()` attempts to access the `YearInSchool` class
 directly, but cannot. The method should be:

 {{{
 def is_upperclass(self):
 return self.year_in_school in {self.YearInSchool.JUNIOR,
 self.YearInSchool.SENIOR}
 }}}

 or:

 {{{
 def is_upperclass(self):
 return self.year_in_school in {Student.YearInSchool.JUNIOR,
 Student.YearInSchool.SENIOR}
 }}}

 https://docs.djangoproject.com/en/3.0/ref/models/fields/#enumeration-types

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

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

2020-02-26 Thread Django

#31310: Wrong hint about recursive relationship
-+-
 Reporter:  Matheus Cunha Motta  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Matheus Cunha Motta:

Old description:

> When there's more than 2 ForeignKeys pointing to the same model in an
> intermediary model of a m2m field and no through_fields have been set,
> Django will show an error with the following hint:
>   {{{#!python
> hint=(
> 'If you want to create a recursive relationship, '
> 'use ForeignKey("%s", symmetrical=False, through="%s").'
>   }}}
> But to create a recursive relationship the ManyToManyField should be used
> instead of ForeignKey. Also symmetrical=False should only be used with
> m2m fields, according to model field reference (link:
> https://docs.djangoproject.com/en/3.0/ref/models/fields/#django.db.models.ManyToManyField.symmetrical).
> And more than that, setting symmetrical=False is not required for
> recursive relationships since Django >= 3.0.
>
> This was probably a small mistake where the developer thought
> ManyToManyField but typed ForeignKey instead. And the symmetrical=False
> is an outdated requirement to recursive relationships, not applicable
> since 3.0. I'll provide a PR with a proposed correction shortly after.

New description:

 When there's more than 2 ForeignKeys in an intermediary model of a m2m
 field and no through_fields have been set, Django will show an error with
 the following hint:
   {{{#!python
 hint=(
 'If you want to create a recursive relationship, '
 'use ForeignKey("%s", symmetrical=False, through="%s").'
   }}}
 But 'symmetrical' and 'through' are m2m keyword arguments, not ForeignKey.

 This was probably a small mistake where the developer thought
 ManyToManyField but typed ForeignKey instead. And the symmetrical=False is
 an outdated requirement to recursive relationships with intermediary model
 to self, not required since 3.0. I'll provide a PR with a proposed
 correction shortly after.

 Edit: fixed description.

--

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

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

2020-02-26 Thread Django

#31312: Wrong MySQL query generation after version 3.0.3.
-+-
 Reporter:  rick2ricks   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql ORM| Triage Stage:
  DateTimeField DurationField|  Unreviewed
  regression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by rick2ricks):

 * keywords:  mysql ORM DateTimeField DurationField => mysql ORM
 DateTimeField DurationField regression


Old description:

> After updating from 3.0.2 to 3.0.3,  Django is generating a wrong MySQL
> query for the queryset method ''with_duration'' in the following example:
>
> {{{
> #!python
> #models.py:
>
> from datetime import datetime
> import pytz
>
> from django.db import models
> from django.db.models.functions import Cast
>
> class PhaseQueryset(models.QuerySet):
>
> def with_duration(self,):
> base_date = datetime(2000, 1, 3, 0, tzinfo=pytz.utc)
>
> # When I use base_date to do the end_total_time math in 3.0.3
> together
> # with ended_at annotated, it creates a wrong query
> qs = self.annotate(
> ended_at=models.Case(
> models.When(
> models.Q(type='TYPEONE'),
> then=models.functions.Now()
> ),
> default=models.F('started_at'),
> output_field=models.DateTimeField(),
> ),
> base_date=models.functions.Cast(
> models.Value(base_date),
> output_field=models.DateTimeField()
> ),
> end_total_time=models.ExpressionWrapper(
> models.F('ended_at') - models.F('base_date'),
> output_field=models.fields.DurationField()
> )
> )
>
> print(qs.values('end_total_time').query)
> return qs
>

> # Create your models here.
> class Phase(models.Model):
> objects = PhaseQueryset().as_manager()
> started_at = models.DateTimeField()
> type = models.CharField(max_length=40)
>
> }}}
>

> == Result query on 3.0.3:
>
> {{{
> SELECT TIMESTAMPDIFF(MICROSECOND, CAST(TYPEONE AS datetime(6)),
> CASE WHEN `daterror_phase`.`type` = 2000-01-03 00:00:00+00:00
> THEN CURRENT_TIMESTAMP
> ELSE `daterror_phase`.`started_at` END) AS `end_total_time`
> FROM `daterror_phase`
> }}}
>

> == Result query on 3.0.2:
> {{{
> SELECT TIMESTAMPDIFF(MICROSECOND, CAST(2000-01-03 00:00:00+00:00 AS
> datetime(6)),
> CASE WHEN `daterror_phase`.`type` = TYPEONE
> THEN CURRENT_TIMESTAMP
> ELSE `daterror_phase`.`started_at` END) AS `end_total_time`
> FROM `daterror_phase`
> }}}

New description:

 After updating from 3.0.2 to 3.0.3,  Django is generating a wrong MySQL
 query for the queryset method ''with_duration'' in the following example:

 {{{
 #!python
 #models.py:

 from datetime import datetime
 import pytz

 from django.db import models
 from django.db.models.functions import Cast

 class PhaseQueryset(models.QuerySet):

 def with_duration(self,):
 base_date = datetime(2000, 1, 3, 0, tzinfo=pytz.utc)

 # When I use base_date to do the end_total_time math in 3.0.3
 together
 # with ended_at annotated, it creates a wrong query
 qs = self.annotate(
 ended_at=models.Case(
 models.When(
 models.Q(type='TYPEONE'),
 then=models.functions.Now()
 ),
 default=models.F('started_at'),
 output_field=models.DateTimeField(),
 ),
 base_date=models.functions.Cast(
 models.Value(base_date),
 output_field=models.DateTimeField()
 ),
 end_total_time=models.ExpressionWrapper(
 models.F('ended_at') - models.F('base_date'),
 output_field=models.fields.DurationField()
 )
 )

 print(qs.values('end_total_time').query)
 return qs


 # Create your models here.
 class Phase(models.Model):
 objects = PhaseQueryset().as_manager()
 started_at = models.DateTimeField()
 type = models.CharField(max_length=40)

 }}}


 == Result query on 3.0.3:

 {{{
 SELECT TIMESTAMPDIFF(MICROSECOND, CAST(TYPEONE AS datetime(6)),
 CASE WHEN `daterror_phase`.`type` = 2000-01-03 00:00:00+00:00
 THEN CURRENT_TIMESTAMP
 ELSE `daterror_phase`.`started_at` END) AS `end_total_time`
 FROM

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

2020-02-26 Thread Django

#31312: Wrong MySQL query generation after version 3.0.3.
-+-
   Reporter: |  Owner:  nobody
  rick2ricks |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  layer (models, ORM)|   Keywords:  mysql ORM
   Severity:  Normal |  DateTimeField DurationField
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 After updating from 3.0.2 to 3.0.3,  Django is generating a wrong MySQL
 query for the queryset method ''with_duration'' in the following example:

 {{{
 #!python
 #models.py:

 from datetime import datetime
 import pytz

 from django.db import models
 from django.db.models.functions import Cast

 class PhaseQueryset(models.QuerySet):

 def with_duration(self,):
 base_date = datetime(2000, 1, 3, 0, tzinfo=pytz.utc)

 # When I use base_date to do the end_total_time math in 3.0.3
 together
 # with ended_at annotated, it creates a wrong query
 qs = self.annotate(
 ended_at=models.Case(
 models.When(
 models.Q(type='TYPEONE'),
 then=models.functions.Now()
 ),
 default=models.F('started_at'),
 output_field=models.DateTimeField(),
 ),
 base_date=models.functions.Cast(
 models.Value(base_date),
 output_field=models.DateTimeField()
 ),
 end_total_time=models.ExpressionWrapper(
 models.F('ended_at') - models.F('base_date'),
 output_field=models.fields.DurationField()
 )
 )

 print(qs.values('end_total_time').query)
 return qs


 # Create your models here.
 class Phase(models.Model):
 objects = PhaseQueryset().as_manager()
 started_at = models.DateTimeField()
 type = models.CharField(max_length=40)

 }}}


 == Result query on 3.0.3:

 {{{
 SELECT TIMESTAMPDIFF(MICROSECOND, CAST(TYPEONE AS datetime(6)),
 CASE WHEN `daterror_phase`.`type` = 2000-01-03 00:00:00+00:00
 THEN CURRENT_TIMESTAMP
 ELSE `daterror_phase`.`started_at` END) AS `end_total_time`
 FROM `daterror_phase`
 }}}


 == Result query on 3.0.2:
 {{{
 SELECT TIMESTAMPDIFF(MICROSECOND, CAST(2000-01-03 00:00:00+00:00 AS
 datetime(6)),
 CASE WHEN `daterror_phase`.`type` = TYPEONE
 THEN CURRENT_TIMESTAMP
 ELSE `daterror_phase`.`started_at` END) AS `end_total_time`
 FROM `daterror_phase`
 }}}

-- 
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/053.52f9d876b7a1e21782ff659f066afddf%40djangoproject.com.

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

2020-02-26 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 going through some of the source code, the issue clearly arises
 because we are calling `RemoveField` in the `generate_deleted_models`
 method in `db/migrations/autodetector.py`
 
[https://github.com/django/django/blob/f283ffaa84ef0a558eb466b8fc3fae7e6fbb547c/django/db/migrations/autodetector.py#L707].
 I think calling this method here is redundant as `DeleteModel` should drop
 the table from the database which automatically deletes the related fields
 as well. Can someone confirm my hypothesis or correct me if I am steering
 in the wrong direction?

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

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

2020-02-26 Thread Django

#31311: Unneeded escape sequences in character classes
-+-
   Reporter:  kimbo  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  3.0
  (Other)|
   Severity:  Normal |   Keywords:  validators, regex
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 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

-- 
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/048.c4db92d7aa6d8720a1375ca450b9a01e%40djangoproject.com.

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

2020-02-26 Thread Django

#31310: Wrong hint about recursive relationship
-+-
 Reporter:  Matheus Cunha Motta  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Matheus Cunha Motta):

 Here's a PR: https://github.com/django/django/pull/12497

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

[Django] #31310: Wrong hint about recursive relationship

2020-02-26 Thread Django

#31310: Wrong hint about recursive relationship
-+-
   Reporter:  Matheus|  Owner:  nobody
  Cunha Motta|
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  3.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 When there's more than 2 ForeignKeys pointing to the same model in an
 intermediary model of a m2m field and no through_fields have been set,
 Django will show an error with the following hint:
   {{{#!python
 hint=(
 'If you want to create a recursive relationship, '
 'use ForeignKey("%s", symmetrical=False, through="%s").'
   }}}
 But to create a recursive relationship the ManyToManyField should be used
 instead of ForeignKey. Also symmetrical=False should only be used with m2m
 fields, according to model field reference (link:
 
https://docs.djangoproject.com/en/3.0/ref/models/fields/#django.db.models.ManyToManyField.symmetrical).
 And more than that, setting symmetrical=False is not required for
 recursive relationships since Django >= 3.0.

 This was probably a small mistake where the developer thought
 ManyToManyField but typed ForeignKey instead. And the symmetrical=False is
 an outdated requirement to recursive relationships, not applicable since
 3.0. I'll provide a PR with a proposed correction shortly after.

-- 
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/056.f996317f736a339cdf1290c0e1a8e59f%40djangoproject.com.

Re: [Django] #28699: REMOTE_USER issues with CSRF

2020-02-26 Thread Django

#28699: REMOTE_USER issues with CSRF
-+-
 Reporter:  stephanm |Owner:  Colton
 |  Hicks
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  remote user  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"f283ffaa84ef0a558eb466b8fc3fae7e6fbb547c" f283ffa]:
 {{{
 #!CommitTicketReference repository=""
 revision="f283ffaa84ef0a558eb466b8fc3fae7e6fbb547c"
 Fixed #28699 -- Fixed CSRF validation with remote user middleware.

 Ensured process_view() always accesses the CSRF token from the session
 or cookie, rather than the request, as rotate_token() may have been called
 by an authentication middleware during the process_request() phase.
 }}}

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

Re: [Django] #31295: required ModelChoiceField makes duplicate (cursor) queries to the database

2020-02-26 Thread Django

#31295: required ModelChoiceField makes duplicate (cursor) queries to the 
database
-+-
 Reporter:  Aurélien Pardon  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Model| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aurélien Pardon):

 The fact that the following code makes '''two''' requests to the database
 :
 {{{#!python
 class MyModel(models.Model):
 my_field = models.CharField(max_length=1)

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

 my_form.as_ul()
 }}}
 is absolutely not working as intended. Show this to any other core dev and
 ask them, please.


 This whole "invalid HTML code" is not an important issue. It happens yes,
 but under very rare circumstances (a blank primary key and an {{{INSERT}}}
 between the two '''identical''' requests to the database), and it also
 won't bother any browser. I can work hard and show you the invalid HTML
 code (using database trigger to emulate race conditions?) but honestly
 it's not the problem.

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

Re: [Django] #28699: REMOTE_USER issues with CSRF

2020-02-26 Thread Django

#28699: REMOTE_USER issues with CSRF
-+-
 Reporter:  stephanm |Owner:  Colton
 |  Hicks
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  remote user  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * owner:  Rodrigo => Colton Hicks
 * 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/066.5fa03fdd07c80036bb9f1c275c15dbfe%40djangoproject.com.

Re: [Django] #28280: numberformat.format() incorrectly formats large/tiny floats in scientific notation

2020-02-26 Thread Django

#28280: numberformat.format() incorrectly formats large/tiny floats in 
scientific
notation
---+-
 Reporter:  Wil Tan|Owner:  Hasan Ramezani
 Type:  Bug|   Status:  closed
Component:  Utilities  |  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
---+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"bc1c03407649a37a8a3c26b8d0cb355ab2fc128e" bc1c0340]:
 {{{
 #!CommitTicketReference repository=""
 revision="bc1c03407649a37a8a3c26b8d0cb355ab2fc128e"
 Fixed #28280 -- Prevented numberformat.format() from formatting large/tiny
 floats in scientific notation.
 }}}

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

Re: [Django] #31304: PostgreSQL full-text search employs coalesce function for non-null single-column searches with SearchVector

2020-02-26 Thread Django

#31304: PostgreSQL full-text search employs coalesce function for non-null 
single-
column searches with SearchVector
-+-
 Reporter:  Paul Boddie  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL text  | Triage Stage:  Accepted
  search FTS coalesce SearchVector   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > Should it be a different issue, though?

 Yeah I think it should.

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

Re: [Django] #28280: numberformat.format() incorrectly formats large/tiny floats in scientific notation

2020-02-26 Thread Django

#28280: numberformat.format() incorrectly formats large/tiny floats in 
scientific
notation
---+-
 Reporter:  Wil Tan|Owner:  Hasan Ramezani
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  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 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.966ad63d09dfaf7eb23aadf9aeb05ebd%40djangoproject.com.

Re: [Django] #31295: required ModelChoiceField makes duplicate (cursor) queries to the database

2020-02-26 Thread Django

#31295: required ModelChoiceField makes duplicate (cursor) queries to the 
database
-+-
 Reporter:  Aurélien Pardon  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Model| 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):

 If you can provide a test case demonstrating invalid HTML then that we be
 a big we could look at.

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

Re: [Django] #31295: required ModelChoiceField makes duplicate (cursor) queries to the database

2020-02-26 Thread Django

#31295: required ModelChoiceField makes duplicate (cursor) queries to the 
database
-+-
 Reporter:  Aurélien Pardon  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Model| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aurélien Pardon):

 Replying to [comment:6 Carlton Gibson]:
 > I don't know what else I can say. It's part of the design of
 ModelChoiceField that it re-evaluates it's queryset each time it's
 iterated.

 {{{ModelChoiceField}}} iterates over his {{{ModelChoiceIterator}}} when
 rendering its widget (and its options).
 {{{ModelChoiceIterator}}} does not necessarily re-evaluates it's queryset
 each time it's iterated: sometimes the query is cached (for example when
 the query involves a {{{prefetch_related}}}), sometimes it is not cached.

 The reason {{{ModelChoiceIterator}}} use, sometimes, {{{.iterator()}}} is
 for '''performance''' (less memory usage, see #3534) and because, at the
 times, the queryset was evaluated/fetched only once when the the field was
 rendered.
 After [https://code.djangoproject.com/ticket/27370 Django's Select widget
 adds a required="required" attribute, even if created with
 empty_label=True], the queryset is evaluated/fetched twice because of the
 new {{{.use_required_attribute}}} method.


 > See #3534 for example, 13 years ago:
 > > ModelChoiceField and ModelMultipleChoiceField cache the output of
 their queryset the first time self.choices is accessed. This is bad for
 long-running processes, such as mod_python, because the cache gets stale.
 Plus, it's bad saving all of those choices in memory. The attached unit
 tests illustrate the problem.
 > The exact same memory usage considerations were the motivation for the
 move to iterator() in #23623. I can't see that being removed.

 You said that "correctness trumps performance" but since
 [https://code.djangoproject.com/ticket/27370], the usage of
 {{{.iterator()}}} in ModelChoiceIterator '''with''' the new
 {{{.use_required_attribute}}} when rendering the form leads to invalid
 HTML. How is this not a bug?
 Moreover, how duplicate requests to the database (the second one is
 useless and leads to bug) do not fall under the same performance
 considerations of #3534?


 I think the solution is to decide to use the required attribute after
 having rendered the field options: while iterating the choices/options, we
 can check if the first option allows us to use the required attribute.

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

Re: [Django] #31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering the page poorly in compatibility mode.

2020-02-26 Thread Django

#31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
the page poorly in compatibility mode.
---+--
 Reporter:  Petter Strandmark  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.0
 Severity:  Normal |   Resolution:  needsinfo
 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):

 Hi Peter.

 If you can prepare some more details on the problems we can look at
 whether we can (and want) to address them.

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

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

2020-02-26 Thread Django

#31032: Document the minimal supported version of browsers for the admin
--+
 Reporter:  Claude Paroz  |Owner:  Ata Öz
 Type:  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):

 Ref #31309, no specifics but it looks like we're already incompatible with
 IE 11.

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

Re: [Django] #31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering the page poorly in compatibility mode.

2020-02-26 Thread Django

#31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
the page poorly in compatibility mode.
---+--
 Reporter:  Petter Strandmark  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.0
 Severity:  Normal |   Resolution:  needsinfo
 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):

 You've target IE11 [https://docs.microsoft.com/en-us/previous-
 versions/windows/internet-explorer/ie-developer/dev-
 guides/bg182625(v=vs.85)?redirectedfrom=MSDN but, the MS Docs again]:

 > Starting with IE11, document modes are deprecated and should no longer
 be used.

 You may need to narrow down **exactly** what CSS elements aren't working.
 Maybe those can be addressed but removing features for a previous
 generation browser isn't likely to win friends.

 Given Claude's comment on #31032

 > ...especially since the responsive patch

 Have you tried overriding the `responsive` block in `admin/base.html`?
 Maybe removing those stylesheets is enough to simplify it?

 (TBH using Edge seems the best option 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/065.a329d783256305e98cd90cfc90cffce5%40djangoproject.com.

Re: [Django] #31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering the page poorly in compatibility mode.

2020-02-26 Thread Django

#31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
the page poorly in compatibility mode.
---+--
 Reporter:  Petter Strandmark  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.0
 Severity:  Normal |   Resolution:  needsinfo
 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:   => needsinfo


Comment:

 > ... the X-UA-Compatible tag needs to come before the stylesheets.

 There's no block for that. Possibly we could add a block but I go back to
 MS's docs saying that the tag shouldn't be used.

 Ref #31032 here: it's not clear that IE is still supported (vs Edge).
 Maybe an email to the DevelopersMailingList is appropriate to clarify the
 situation.

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

Re: [Django] #31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering the page poorly in compatibility mode.

2020-02-26 Thread Django

#31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
the page poorly in compatibility mode.
---+--
 Reporter:  Petter Strandmark  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Petter Strandmark):

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


Comment:

 From the documentation:

 "The X-UA-Compatible header isn't case sensitive; however, it must appear
 in the header of the webpage (the HEAD section) before all other elements
 except for the title element and other meta elements."

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

Re: [Django] #31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering the page poorly in compatibility mode.

2020-02-26 Thread Django

#31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
the page poorly in compatibility mode.
---+--
 Reporter:  Petter Strandmark  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.0
 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 Petter Strandmark):

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

Re: [Django] #31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering the page poorly in compatibility mode.

2020-02-26 Thread Django

#31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
the page poorly in compatibility mode.
---+--
 Reporter:  Petter Strandmark  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Petter Strandmark):

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


Comment:

 No that does not work, unfortunately, since the X-UA-Compatible tag needs
 to come before the stylesheets.

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

Re: [Django] #31295: required ModelChoiceField makes duplicate (cursor) queries to the database

2020-02-26 Thread Django

Comment (by Carlton Gibson):

> How is that correct if the queries yield different results ?

I don't know what else I can say. It's part of the design of
ModelChoiceField that it re-evaluates it's queryset each time it's
iterated.
See #3534 for example, 13 years ago:

> ModelChoiceField and ModelMultipleChoiceField cache the output of their
queryset the first time self.choices is accessed. This is bad for long-
running processes, such as mod_python, because the cache gets stale. Plus,
it's bad saving all of those choices in memory. The attached unit tests
illustrate the problem.

The exact same memory usage considerations were the motivation for the
move to iterator() in #23623. I can't see that being removed.

If the kind of race conditions you're talking about are a factor for your
app then, at least until #22841 is addressed, maybe you do need a
ModelChoiceIterator subclass for your field. (Always use the QuerySet
rather than the iterator...)

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

Re: [Django] #31295: required ModelChoiceField makes duplicate (cursor) queries to the database

2020-02-26 Thread Django

#31295: required ModelChoiceField makes duplicate (cursor) queries to the 
database
-+-
 Reporter:  Aurélien Pardon  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Model| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aurélien Pardon):

 Replying to [comment:4 Carlton Gibson]:
 > (Yes there's an extra query but correctness trumps performance.)

 How is that correct if the queries yield different results ?
 It only works if the two requests are inside a transaction, for example
 when {{{ATOMIC_REQUESTS}}} is set to {{{True}}} (which is not the
 default).


 For example, imagine this model (the primary key is important, it's the
 value that the choice will use):
 {{{#!python
 class MyModel(models.Model):
 my_field = models.CharField(max_length=1, primary_key=True)
 }}}
 If the first query (for the actual choices) returns {{{['a', 'b']}}}, but
 the second one (for the required attribute) returns {{{['', 'b', 'c']}}},
 then the required attribute will be used leading to invalid HTML.

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

Re: [Django] #31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering the page poorly in compatibility mode.

2020-02-26 Thread Django

#31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
the page poorly in compatibility mode.
---+--
 Reporter:  Petter Strandmark  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.0
 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:

 [https://docs.microsoft.com/en-us/previous-versions/windows/internet-
 explorer/ie-developer/compatibility/jj676915(v=vs.85)?redirectedfrom=MSDN
 As per Microsoft's advice] we use the HTML5 document type: ``. Document modes have been deprecated since 2013 and "should not be
 used".

 If you want this you can create your own `admin/base.html`, as per the
 [https://docs.djangoproject.com/en/3.0/howto/overriding-templates/
 Overriding templates docs].

 Give it the following content to add the meta tag to the existing block:

 {{{
 {% extends 'admin/base.html' %}

 {% block extrahead %}
 
 {% endblock %}
 }}}

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

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

2020-02-26 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:  Accepted
  unique_together E310 E311  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ahmad Abdallah):

 * needs_docs:  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.946cac8583aa7315ae0906fb88ad3923%40djangoproject.com.

Re: [Django] #31304: PostgreSQL full-text search employs coalesce function for non-null single-column searches with SearchVector

2020-02-26 Thread Django

#31304: PostgreSQL full-text search employs coalesce function for non-null 
single-
column searches with SearchVector
-+-
 Reporter:  Paul Boddie  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL text  | Triage Stage:  Accepted
  search FTS coalesce SearchVector   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Paul Boddie):

 I can probably look into it, given that I have managed to write a lookup
 that seems to have the desired behaviour. Should it be a different issue,
 though?

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

Re: [Django] #31295: required ModelChoiceField makes duplicate (cursor) queries to the database

2020-02-26 Thread Django

#31295: required ModelChoiceField makes duplicate (cursor) queries to the 
database
-+-
 Reporter:  Aurélien Pardon  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Model| 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
 * type:  Bug => Cleanup/optimization
 * resolution:   => needsinfo


Comment:

 Hi Aurélien,

 Thanks for the follow-up. Really not a problem. Better to ''measure twice,
 cut once'' and all that.  :)

 The iterator behaviour — refetching each time — was deliberate, and is
 correct. I can't see an adjustment there that doesn't entail a fix to
 #22841.
 (Duplicate then...)

 ''Maybe you don't want that behaviour and a ModelChoiceIterator subclass
 would work for you?'' But as soon as I think that, better would be a
 Select widget subclass.

 #27370 fixed the `Select.use_required_attribute()` behaviour. It
 necessarily needs the first item for the `_choice_has_empty_value` check.
 So, give the design of ModelChoiceIterator, fetching it isn't a Bug. (Yes
 there's an extra query but correctness trumps performance.)

 ''Maybe'' there's a way of performing that
 `Select.use_required_attribute()` check without fetching the first
 item...? Would that be better than using a subclass for this kind of case?
 (If I know my dataset I can just return `False` from
 `use_required_attribute()`.)

 I guess we could look at a patch there. I'm going to call this needsinfo
 pending such though. 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/065.fc9bd1ea75724bc0a976c6c561e6976c%40djangoproject.com.

[Django] #31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering the page poorly in compatibility mode.

2020-02-26 Thread Django

#31309: Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
the page poorly in compatibility mode.
-+
   Reporter:  Petter Strandmark  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.0
   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  |
-+
 Django admin site needs X-UA-Compatible meta tag to prevent IE rendering
 the page poorly in compatibility mode.

 The fix is simple, just add `` to the base template. I'll make a PR for this.

 It's pretty annoying without this, CSS can break and the pages look
 generally poor.

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

Re: [Django] #31289: system checks: admin.E002 could provide a hint but doesn't

2020-02-26 Thread Django

#31289: system checks: admin.E002 could provide a hint but doesn't
-+-
 Reporter:  Keryn Knight |Owner:  Sanskar
 Type:   |  Jaiswal
  Cleanup/optimization   |   Status:  closed
Component:  Core (System |  Version:  3.0
  checks)|
 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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"fba5d3b6e63fe4a07b1aa133186f997eeebf9aeb" fba5d3b6]:
 {{{
 #!CommitTicketReference repository=""
 revision="fba5d3b6e63fe4a07b1aa133186f997eeebf9aeb"
 Fixed #31289 -- Added hint for USERNAME_FIELD/REQUIRED_FIELDS system
 check.
 }}}

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

Re: [Django] #31304: PostgreSQL full-text search employs coalesce function for non-null single-column searches with SearchVector

2020-02-26 Thread Django

#31304: PostgreSQL full-text search employs coalesce function for non-null 
single-
column searches with SearchVector
-+-
 Reporter:  Paul Boddie  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL text  | Triage Stage:  Accepted
  search FTS coalesce SearchVector   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  1 => 0
 * version:  2.2 => 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.16e4a602031e9397ebb94762d48338e4%40djangoproject.com.

49 matches

Mail list logo