date:20180126

Re: [Django] #21429: BaseCommand should use logging instead of custom output wrappers

2018-01-26 Thread Django

#21429: BaseCommand should use logging instead of custom output wrappers
-+-
 Reporter:  Nical|Owner:  John Kang
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  command output   | Triage Stage:  Accepted
  logger |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by John Kang):

 Hi all, going to resume work on this patch.

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

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

Re: [Django] #27877: Management command exceptions should be logged

2018-01-26 Thread Django

#27877: Management command exceptions should be logged
-+-
 Reporter:  karyon   |Owner:  John Kang
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  1.11
  commands)  |
 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 John Kang):

 Replying to [comment:6 karyon]:
 > John do you still plan to work on this?
 Hi Karyon, I will be resuming work on this.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a52bd3d9c06ca7dd1e21203f26607ef3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29055: Document that escapejs doesn't make template literals safe

2018-01-26 Thread Django

#29055: Document that escapejs doesn't make template literals safe
-+-
 Reporter:  Alvin Lindstam   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  2.0
 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 Loic Bistuer):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.f9dc555d3d4b5551e691a6688bf307ac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29074: django-admin makemessages messes up .po file when fed with empty strings

2018-01-26 Thread Django

#29074: django-admin makemessages messes up .po file when fed with empty strings
-+-
   Reporter: |  Owner:  nobody
  instantname|
   Type:  Bug| Status:  new
  Component:  Core   |Version:  1.11
  (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  |
-+-
 Django 1.11.9

 == Steps to reproduce

 {{{
 django-admin startproject mysite
 cd mysite/mysite
 mkdir locale
 }}}

 Edit urls.py to add this line at the end:

 {{{
 _('hello')
 }}}

 Create messages:

 {{{
 django-admin makemessages -l de
 }}}

 Edit urls.py again to add this line at the end:

 {{{
 pgettext_lazy('context', '')
 }}}

 Update messages:

 {{{
 django-admin makemessages
 }}}

 == Result

 The locale/de/django.po file obtained is the following:

 {{{
 # SOME DESCRIPTIVE TITLE.
 # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
 # This file is distributed under the same license as the PACKAGE package.
 # FIRST AUTHOR , YEAR.
 #
 #, fuzzy
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2018-01-27 03:50+0100\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME \n"
 "Language-Team: LANGUAGE \n"
 "Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1);\n"

 #: urls.py:23
 msgid "hello"
 msgstr ""

 # SOME DESCRIPTIVE TITLE.
 # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
 # This file is distributed under the same license as the PACKAGE package.
 # FIRST AUTHOR , YEAR.
 #
 #: urls.py:24
 #, fuzzy
 msgctxt "context"
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2018-01-27 03:49+0100\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME \n"
 "Language-Team: LANGUAGE \n"
 "Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1);\n"
 }}}

 The unexpected behavior is the repetition of some header lines. This seems
 to only happen with empty strings in the Python code. While a bit odd, I
 think empty strings are valid strings (at least with a context) that may
 sometimes need translation.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.047498bb4cb6add70b097da7bf87890d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28878: "pip install django" is broken on Python 2; can be fixed for most users with metadata

2018-01-26 Thread Django

#28878: "pip install django" is broken on Python 2; can be fixed for most users
with metadata
+
 Reporter:  Zac Hatfield Dodds  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Packaging   |  Version:  2.0
 Severity:  Release blocker |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Zac Hatfield Dodds):

 Replying to [comment:8 Andy Grabow]:
 > okay, good to know! i hope this works out! should be possible for a
 project as big as this!

 [https://github.com/pypa/warehouse/issues/2170#issuecomment-360945767 Yep,
 all done] - this ticket is as resolved now as it can possibly be.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.74c912a414ced94fd807a036fbc0b6cb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29073: CONN_MAX_AGE and others not being picked up from settings file

2018-01-26 Thread Django

#29073: CONN_MAX_AGE and others not being picked up from settings file
-+-
 Reporter:  Karl Kuehn   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (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
-+-
Changes (by Tim Graham):

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


Comment:

 As Simon said on the pull request, "These settings should be defined per-
 DATABASES entry and not as top level settings."

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.10b747a9ff303266f761a1ffb4a4ff90%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29072: Allow select_related() to fetch individual fields from a related model

2018-01-26 Thread Django

#29072: Allow select_related() to fetch individual fields from a related model
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 [https://groups.google.com/d/topic/django-
 developers/XSiGQWI1TNs/discussion django-developers thread]

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.fb163815b34e36047f0013e0db1769a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29073: CONN_MAX_AGE and others not being picked up from settings file

2018-01-26 Thread Django

#29073: CONN_MAX_AGE and others not being picked up from settings file
-+-
 Reporter:  Karl Kuehn   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Karl Kuehn):

 I have created a pull request with one way of fixing this:
 https://github.com/django/django/pull/9625

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b56962fa226d8d26fc94636c7a65b7bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29073: CONN_MAX_AGE and others not being picked up from settings file

2018-01-26 Thread Django

#29073: CONN_MAX_AGE and others not being picked up from settings file
-+-
Reporter: Karl | Owner: nobody
Kuehn |
Type: Bug| Status: new
Component: Database |Version: master
layer (models, ORM)|
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+-
In trying to solve some performance issues I am observing (probably our
code) I tried to use the `CONN_MAX_AGE` setting documented here:
https://docs.djangoproject.com/en/2.0/ref/settings/#conn-max-age

I have a `pgbouncer` instance setup, so it was easy to observe connections
going to the database, and I found that regardless of that setting the
connections were being dropped at the end of every request, regardless of
what value I set (even invalid ones have no effect).

Using `git grep CONN_MAX_AGE | grep '\.py:'` I found that this value is
never being read from the settings file, and only defaulted in
`django/db/utils.py:ConnectionHandler.ensure_defaults()`. This is true
both on current (as of this writing) `master` and version 1.11.1 (what we
are currently using). It may well go farther back than that, but I have
not checked.

I also checked `ATOMIC_REQUESTS`, and `AUTOCOMMIT` and they show the same
pattern. Other values there are more complicated, and I did not 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/050.6feb7be4385ac0cd9c6c00d984344128%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29065: Only load Pillow if needed

2018-01-26 Thread Django

#29065: Only load Pillow if needed
-+-
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * component:  File uploads/storage => Core (Other)


Comment:

 I don't see the motivation behind the idea.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.20578865f6fa87200ecabf3a777fe4f3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29054: QuerySet with multiple annotations crashes with "unhashable type: 'Point'"

2018-01-26 Thread Django

#29054: QuerySet with multiple annotations crashes with "unhashable type: 
'Point'"
-+-
 Reporter:  Lachlan Cannon   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  2.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 Tim Graham):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d1d376c13ff297c78b9fed82e831ef80%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29070: Admin login redirects to /accounts/login after upgrade to Django 2.0

2018-01-26 Thread Django

#29070: Admin login redirects to /accounts/login after upgrade to Django 2.0
+--
 Reporter:  Dan Loewenherz  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  2.0
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Dan Loewenherz):

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


Comment:

 This issue is due to a third-party app (django-two-factor-auth) overriding
 the login routes. Closing.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.03b7db62eb614567e4d9a1ea8d2c7177%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29072: Allow select_related() to fetch individual fields from a related model (was: only()/defer() vs select_related())

2018-01-26 Thread Django

#29072: Allow select_related() to fetch individual fields from a related model
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Tim Graham):

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


Comment:

 I'm not in love with the proposed API. Giving `select _related()` the
 ability to fetch individual fields doesn't seem like a proper separation
 of concerns (that's what `only()` is for). You could raise a discussion on
 the DevelopersMailingList to see if consensus emerges about a more elegant
 solution.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.72a05749de9723ee4b65b6e83b4e9756%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29072: only()/defer() vs select_related()

2018-01-26 Thread Django

#29072: only()/defer() vs select_related()
-+-
   Reporter:  Дилян  |  Owner:  nobody
  Палаузов   |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Provided
 {{{
 class M(models.Model):
 n = models.IntegerField()
 r = models.IntegerField()
 t = models.IntegerField()
 s = models.IntegerField()
 u = models.IntegerField()

 class F(models.Model):
 g = models.ForeignKey(M, on_delete=models.CASCADE)
 a = models.IntegerField()
 b = models.IntegerField()
 c = models.IntegerField()
 d = models.IntegerField()
 e = models.IntegerField()
 }}}


 I want to obtain with a queryset all fields from F and M.n, but not the
 other fields of M like M.r.  This works
 {{{F.objects.select_related('g').defer('g__r', 'g__t', 'g__s', 'g__u')}}}
 but I don't like it, as I want to say only M.n has to be obtained, and not
 the others.  prefetch_related is also suboptimal, as it creates two SQL
 queries instead of one.  {{{only()}}} does not let me specify 'All fields
 of F'.

 {{{F.objects.select_related('g__n')}}} would fit from logic, but does not
 work ({{{django.core.exceptions.FieldError: Non-relational field given in
 select_related: 'n'. Choices are: (none)}}})

 Please make {{{select_related()}}} accept the above expression.

 This applies to both master and 1.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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.d931b9e46352a7da0f25ced76f329289%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29071: Backend authentication does not reset `credentials` on each iteration.

2018-01-26 Thread Django

#29071: Backend authentication does not reset `credentials` on each iteration.
+
 Reporter:  Sjoerd Job Postmus  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.auth|  Version:  1.11
 Severity:  Release blocker |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tim Graham):

 * version:  2.0 => 1.11
 * severity:  Normal => Release blocker
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ff1dac68a6fa38c473bf64475cc0803a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28562: DecimalValidator raises ValidationError for decimals in scientific notation

2018-01-26 Thread Django

#28562: DecimalValidator raises ValidationError for decimals in scientific 
notation
-+-
 Reporter:  Maksim Iakovlev  |Owner:  Josh
 |  Schneier
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  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 Tim Graham):

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


Comment:

 Please open a new ticket as the fix for this ticket has been released.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ad786e5c102dad1db412f6add3527cdc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29070: Admin login redirects to /accounts/login after upgrade to Django 2.0

2018-01-26 Thread Django

#29070: Admin login redirects to /accounts/login after upgrade to Django 2.0
+--
 Reporter:  Dan Loewenherz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  2.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
+--

Comment (by Tim Graham):

 No, I haven't seen a report like this.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.67412f755a491d213141fbf86269b723%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28562: DecimalValidator raises ValidationError for decimals in scientific notation

2018-01-26 Thread Django

#28562: DecimalValidator raises ValidationError for decimals in scientific 
notation
-+-
 Reporter:  Maksim Iakovlev  |Owner:  Josh
 |  Schneier
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  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 Josh Harwood):

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


Comment:

 Running version Django==2.0.1

 With Example form

 {{{
 class UpdateBalanceForm(forms.Form):
 id = forms.ModelChoiceField(ProductPortfolio.objects.all(),
 required=True)
 balance = forms.DecimalField(decimal_places=2, max_digits=16,
 required=True)
 }}}

 Running the following you get

 {{{
 form = UpdateBalanceForm({'id':1,
 'balance':Decimal('5.420575188741E-12')})
 form.is_valid()
 False
 form.errors
 {'id': ['Select a valid choice. That choice is not one of the available
 choices.'], 'balance': ['Ensure that there are no more than 16 digits in
 total.']}
 }}}

 This is surprising because the value has 13 digits minus the 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.262e1195dbc8b474dfcc667521607970%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29070: Admin login redirects to /accounts/login after upgrade to Django 2.0

2018-01-26 Thread Django

#29070: Admin login redirects to /accounts/login after upgrade to Django 2.0
+--
 Reporter:  Dan Loewenherz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  2.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
+--
Description changed by Dan Loewenherz:

Old description:

> After upgrading to Django 2.0, our administrative site login redirects to
> the site-wide login instead of the admin login. This seems like a bug.
>
> `LOGIN_URL` and `LOGOUT_URL` are both default, and `path('admin/',
> admin.site.urls),` is the first URL listed in `urlpatterns`.
>
> If this is a known issue, great, if not, let me know and I will try to
> get a reproducible test case.

New description:

 After upgrading to Django 2.0, our administrative site login redirects to
 the site-wide login URL (/accounts/login) instead of the admin login. This
 seems like a bug.

 `LOGIN_URL` and `LOGOUT_URL` are both default, and `path('admin/',
 admin.site.urls),` is the first URL listed in `urlpatterns`.

 If this is a known issue, great, if not, let me know and I will try to get
 a reproducible test case.

--

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

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

[Django] #29071: Backend authentication does not reset `credentials` on each iteration.

2018-01-26 Thread Django

#29071: Backend authentication does not reset `credentials` on each iteration.
--+
   Reporter:  Sjoerd Job Postmus  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.auth|Version:  2.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   |
--+
 For Django 1.11 and Django 2.0, there's a problem with the "graceful
 deprecation" layer that's being used, which has already caused some issues
 from what I can see. It's regarding the {{{authenticate}}} and
 {{{_authenticate_with_backend}}}.

 Regarding ticket:28207: there was an issue regarding the {{{credentials}}}
 dictionary being polluted inside each loop.
 In commit 3008f30f194af386c354416be4c483f0f6b15f33, this was solved by
 moving the work inside each iteration into a separate function, getting
 the arguments using kwargs-passing-style ({{{**credentials}}}), so that
 each iteration would get a clean version of the credentials to work on.
 In commit a3ba2662cdaa36183fdfb8a26dfa157e26fca76a, however, that was
 completely undone, by passing the original dictionary instead
 ({{{**credentials}}} was changed into {{{credentials}}}), which again
 meant the original dictionary would get mutated.

 I think the easiest fix is to add the following line:

 {{{
 credentials = dict(credentials)
 }}}

 at the start of {{{_authenticate_with_backend}}}.

 This change is no longer necessary for Django 2.1, as this calling-style
 is not even supported anymore. However, for both Django 1.11 and Django
 2.0 it can cause problems. In our case, it was due to two specific
 overrides from different apps: one was still using the old convention
 {{{authenticate(self, username=None, password=None, **kwargs)}}}, while
 the other was a wrapper around the {{{ModelBackend}}}: as follows:

 {{{
 class ActiveUserBackend(ModelBackend):
 def authenticate(self, *args, **kwargs):
 # some code
 return super()(*args, **kwargs)
 }}}

 However, seeing as the first backend caused {{{credentials}}} to be
 changed to username/password/request, it was now called as follows:

 {{{
 authenticate(request, **{'username': 'foo', 'password': 'bar', 'request':
 request})
 }}}

 ticket:28207 would again be fixed I believe by the following simple patch
 applied to Django 1.11 and 2.0.

 {{{
 diff --git a/django/contrib/auth/__init__.py
 b/django/contrib/auth/__init__.py
 index d96300c503..2d4b525f67 100644
 --- a/django/contrib/auth/__init__.py
 +++ b/django/contrib/auth/__init__.py
 @@ -82,6 +82,8 @@ def authenticate(request=None, **credentials):


  def _authenticate_with_backend(backend, backend_path, request,
 credentials):
 +# Make sure that changes to `credentials` argument are not propagated
 to caller
 +credentials = dict(credentials)
  args = (request,)
  # Does the backend accept a request argument?
  try:
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.fdd6f5449ce8e2947518dc3d77667fbd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29070: Admin login redirects to /accounts/login after upgrade to Django 2.0

2018-01-26 Thread Django

#29070: Admin login redirects to /accounts/login after upgrade to Django 2.0
--+
   Reporter:  Dan Loewenherz  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.admin   |Version:  2.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   |
--+
 After upgrading to Django 2.0, our administrative site login redirects to
 the site-wide login instead of the admin login. This seems like a bug.

 `LOGIN_URL` and `LOGOUT_URL` are both default, and `path('admin/',
 admin.site.urls),` is the first URL listed in `urlpatterns`.

 If this is a known issue, great, if not, let me know and I will try to get
 a reproducible test case.

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

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

Re: [Django] #29039: Disabling migrations doesn't work with --keepdb

2018-01-26 Thread Django

#29039: Disabling migrations doesn't work with --keepdb
-+-
 Reporter:  Vackar Afzal |Owner:  Anoosha
 |  keen
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  database, tests, | Triage Stage:  Accepted
  migrations |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Migrations => Testing framework
 * type:  Uncategorized => Bug
 * easy:  1 => 0
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.dcbe202ffe81b95a190c5b0029daece7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29039: Disabling migrations doesn't work with --keepdb

2018-01-26 Thread Django

#29039: Disabling migrations doesn't work with --keepdb
-+-
 Reporter:  Vackar Afzal |Owner:  Anoosha
 |  keen
 Type:  Uncategorized|   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  database, tests, | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 Is `/home/anoosha/django` using Django's master branch? The traceback
 shows line numbers that makes me think it's not.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.e96c0482a7dee2992174c256800c6bab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29039: Disabling migrations doesn't work with --keepdb

2018-01-26 Thread Django

#29039: Disabling migrations doesn't work with --keepdb
-+-
 Reporter:  Vackar Afzal |Owner:  Anoosha
 |  keen
 Type:  Uncategorized|   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  database, tests, | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Vackar Afzal):

 Could you please add the print statement before the custom block of code

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.57d757c868e25e84b5bb754714222914%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29039: Disabling migrations doesn't work with --keepdb

2018-01-26 Thread Django

#29039: Disabling migrations doesn't work with --keepdb
-+-
 Reporter:  Vackar Afzal |Owner:  Anoosha
 |  keen
 Type:  Uncategorized|   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  database, tests, | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Anoosha keen):

 * cc: Anoosha keen (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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.3e4aca7331dd0aa9597b935d1ea8db23%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29039: Disabling migrations doesn't work with --keepdb

2018-01-26 Thread Django

#29039: Disabling migrations doesn't work with --keepdb
-+-
 Reporter:  Vackar Afzal |Owner:  Anoosha
 |  keen
 Type:  Uncategorized|   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  database, tests, | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Anoosha keen):

 **Output is this:**
 python manage.py runserver
 None
 None
 None
 None
 None
 None
 None
 None
 None
 None
 None
 None
 None
 None
 Performing system checks...

 System check identified no issues (0 silenced).
 Unhandled exception in thread started by .wrapper at 0x7f570f8098c8>
 Traceback (most recent call last):
   File "/home/anoosha/django/django/utils/autoreload.py", line 220, in
 wrapper
 fn(*args, **kwargs)
   File
 "/home/anoosha/django/django/core/management/commands/runserver.py", line
 113, in inner_run
 self.check_migrations()
   File
 "/home/anoosha/django/django/core/management/commands/runserver.py", line
 159, in check_migrations
 executor = MigrationExecutor(connections[DEFAULT_DB_ALIAS])
   File "/home/anoosha/django/django/db/migrations/executor.py", line 19,
 in __init__
 self.loader = MigrationLoader(self.connection)
   File "/home/anoosha/django/django/db/migrations/loader.py", line 49, in
 __init__
 self.build_graph()
   File "/home/anoosha/django/django/db/migrations/loader.py", line 178, in
 build_graph
 self.load_disk()
   File "/home/anoosha/django/django/db/migrations/loader.py", line 71, in
 load_disk
 module = import_module(module_name)
   File
 "/home/anoosha/.virtualenvs/djangodev/lib/python3.5/importlib/__init__.py",
 line 117, in import_module
 if name.startswith('.'):
 AttributeError: 'NoneType' object has no attribute 'startswith'

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.872eaafca2205b1245fd8a5a49f29662%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29067: QuerySet.values_list(..., flat=True) combined with .annotate() incorrectly includes the annotate columns

2018-01-26 Thread Django

#29067: QuerySet.values_list(..., flat=True) combined with .annotate() 
incorrectly
includes the annotate columns
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 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 Tim Graham ):

 In [changeset:"61c74ae74f6e23e5c6468c1bc2adb348c60cc289" 61c74ae]:
 {{{
 #!CommitTicketReference repository=""
 revision="61c74ae74f6e23e5c6468c1bc2adb348c60cc289"
 [2.0.x] Fixed #29067 -- Fixed regression in QuerySet.values_list(...,
 flat=True) followed by annotate().

 Regression in 4dfd6b88d520b43b6363946e5ee58ba14cd1efe6.

 Backport of 3187c89d6f8c60ca7e78093d5b37e0709e71cea9 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c8af420772aa284fa1a9ee8a0af726cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29039: Disabling migrations doesn't work with --keepdb

2018-01-26 Thread Django

#29039: Disabling migrations doesn't work with --keepdb
-+-
 Reporter:  Vackar Afzal |Owner:  Anoosha
 |  keen
 Type:  Uncategorized|   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  database, tests, | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Vackar Afzal):

 Replying to [comment:2 Anoosha keen]:
 > **I get this error:**
 >  if name.startswith('.'):
 > AttributeError: 'NoneType' object has no attribute 'startswith'
 > When I add the given code to setting.py I got the error mentioned
 above.Can you explain this please?


 What output do you get from either:
 print INSTALLED_APPS #Python2.x
 or
 print (INSTALLED_APPS) #Python3.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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.da9c430443fccac795025935b7eb45c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29067: QuerySet.values_list(..., flat=True) combined with .annotate() incorrectly includes the annotate columns

2018-01-26 Thread Django

#29067: QuerySet.values_list(..., flat=True) combined with .annotate() 
incorrectly
includes the annotate columns
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 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 Tim Graham ):

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


Comment:

 In [changeset:"3187c89d6f8c60ca7e78093d5b37e0709e71cea9" 3187c89]:
 {{{
 #!CommitTicketReference repository=""
 revision="3187c89d6f8c60ca7e78093d5b37e0709e71cea9"
 Fixed #29067 -- Fixed regression in QuerySet.values_list(..., flat=True)
 followed by annotate().
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.7ecb0deff2b84c9a6630cc060de06091%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29039: Disabling migrations doesn't work with --keepdb

2018-01-26 Thread Django

#29039: Disabling migrations doesn't work with --keepdb
-+-
 Reporter:  Vackar Afzal |Owner:  Anoosha
 |  keen
 Type:  Uncategorized|   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  database, tests, | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Anoosha keen):

 **I get this error:**
  if name.startswith('.'):
 AttributeError: 'NoneType' object has no attribute 'startswith'
 When I add the given code to setting.py I got the error mentioned
 above.Can you explain this please?
 Replying to [ticket:29039 Vackar Afzal]:
 > We have a large number of migrations in our application now, and as a
 result it can take 20 mins to create a test DB.
 > To make this faster I am settings MIGRATION_MODULES in my settings as
 follows:
 >
 > {{{
 > MIGRATION_MODULES = {}
 > for app in INSTALLED_APPS:
 > if app.startswith('django.contrib.'):
 > app=app.replace('django.contrib.', '')
 > MIGRATION_MODULES[app] = None
 >
 > }}}
 >
 > I've found that this breaks the --keepdb option as it Django wants to
 run sync_db internally every time.
 >
 > The workaround I found is to modify django.db.backends.creation.py
 (lines 64 to 70) from
 >
 > {{{
 > call_command(
 > 'migrate',
 > verbosity=max(verbosity - 1, 0),
 > interactive=False,
 > database=self.connection.alias,
 > run_syncdb=true,
 > )
 > }}}
 >
 > To
 >
 >
 > {{{
 > call_command(
 > 'migrate',
 > verbosity=max(verbosity - 1, 0),
 > interactive=False,
 > database=self.connection.alias,
 > run_syncdb=not keepdb,
 > )
 > }}}
 >
 >
 >

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.7bb1d3683e62bab9d8e6fb7127db6446%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29051: unique_together behavior undocumented changes in 1.11

2018-01-26 Thread Django

#29051: unique_together behavior undocumented changes in 1.11
+--
 Reporter:  Christian Pedersen  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Documentation   |  Version:  1.11
 Severity:  Normal  |   Resolution:  worksforme
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => worksforme
 * component:  Uncategorized => Documentation


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7b7f7824bd837d9093bf1ed80f2adca3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29068: Django urlpatterns has limit of allowed urls with namespace?

2018-01-26 Thread Django

#29068: Django urlpatterns has limit of allowed urls with namespace?
---+--
 Reporter:  Gerben Morsink |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (URLs)|  Version:  1.11
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  urlpatterns limit  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

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


Comment:

 You should debug your code and confirm that Django is at fault before
 creating a ticket. We can't triage the issue without a sample project to
 reproduce it. Please reopen the ticket if you can do one of those things.
 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.3a8d8406ff907c68cdce05f395d78851%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29039: Disabling migrations doesn't work with --keepdb

2018-01-26 Thread Django

#29039: Disabling migrations doesn't work with --keepdb
-+-
 Reporter:  Vackar Afzal |Owner:  Anoosha
 |  keen
 Type:  Uncategorized|   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  database, tests, | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Anoosha keen):

 * owner:  nobody => Anoosha keen
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.05d59affdf9454985f0edb54e9aa68d9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28668: Add ON CONFLICT support to QuerySet.bulk_create()

2018-01-26 Thread Django

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Дилян Палаузов):

 * Attachment "on_conflict_postgresql.patch" added.

 this adds INSERT ON CONFLICT IGNORE to Postgresql, where only IDs of the
 actually inserted rows are returned

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.ff633f254f53bd32f0be2df4ccfe0810%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29069: Static file serving does not call request_finished signal

2018-01-26 Thread Django

https://docs.djangoproject.com/en/2.0/howto/static-files/#serving-files-
uploaded-by-a-user-during-development

However I've found that requests that hit these URLs emit the
request_started signal but not the request_finished signal. Supposedly
this signal would be sent after the content was sent but it is never sent.
I've tried both with runserver and the latest uWSGI.

This is a problem when we are using a connection pool since Django uses
this signal to cleanup db connections (and thus return them to the pool),
so we have a connection leak.

--
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/049.5e6e83689e7375d7d3d6262b64c9a741%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29067: QuerySet.values_list(..., flat=True) combined with .annotate() incorrectly includes the annotate columns

2018-01-26 Thread Django

#29067: QuerySet.values_list(..., flat=True) combined with .annotate() 
incorrectly
includes the annotate columns
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 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):

 * severity:  Normal => Release blocker


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6354a4a9047beb2e981fa9d150fa7ff7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28988: Multi-table inheritance breaks GenericRelation querying

2018-01-26 Thread Django

#28988: Multi-table inheritance breaks GenericRelation querying
--+
 Reporter:  robwa |Owner:  robwa
 Type:  Bug   |   Status:  assigned
Component:  contrib.contenttypes  |  Version:  1.11
 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 robwa):

 * has_patch:  0 => 1


Comment:

 Added a [https://github.com/django/django/pull/9624 pull request].

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.ed1dd69abdb468646870602c8341b5ba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28878: "pip install django" is broken on Python 2; can be fixed for most users with metadata

2018-01-26 Thread Django

#28878: "pip install django" is broken on Python 2; can be fixed for most users
with metadata
+
 Reporter:  Zac Hatfield Dodds  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Packaging   |  Version:  2.0
 Severity:  Release blocker |   Resolution:  fixed
 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 Andy Grabow):

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


Comment:

 okay, good to know! i hope this works out! should be possible for a
 project as big as this!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.8ccd04da0457152b9a162b34dd9c4057%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29068: Django urlpatterns has limit of allowed urls with namespace?

2018-01-26 Thread Django

#29068: Django urlpatterns has limit of allowed urls with namespace?
-+-
   Reporter:  Gerben |  Owner:  nobody
  Morsink|
   Type:  Bug| Status:  new
  Component:  Core   |Version:  1.11
  (URLs) |
   Severity:  Normal |   Keywords:  urlpatterns limit
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm currently working on a huge site with a huge number of distinct
 urlpatterns, that are categorized in a tree pattern, starting with the
 project's urls.py and then going down the tree with include statements
 (sometimes namespaced), which in turn have their own include statements,
 untill we are about 4 branches away.

 Next to that many urlpatterns are conditional (if settings.DEBUG ... if
 'app_x' in installed_apps... etc).

 I have had issues with one of the last urlpatterns in the project's
 urls.py a lot on my production environment, on apache + wsgi ('No reverse
 found'), which I couldn't reproduce on my development machine with
 runserver . It has a namespace set. It was not a user facing endpoint so I
 forgot about it.

 Now I have added another urlpattern to the project's urls.py with a
 namespace and it too gives 'No reverse found' (it is reversed in a
 middleware, so the app does not start at all, making it easier to test).

 When I place the last urlpattern up in the projects urls.py that it comes
 as the second urlpattern, the app does start, so it looks like the
 urlpatterns are going into some kind of limit.

 For your reference this is the code that works when placed after the first
 urlpatterns definition, but not when placed at the bottom (I think nothing
 special).

 {{{
 if 'silk' in settings.INSTALLED_APPS:
 urlpatterns += [url(r'^silk/', include('silk.urls',
 namespace='silk'))]
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.eff0b65ddbe5c1d4b804f399c7e7ff44%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29067: QuerySet.values_list(..., flat=True) combined with .annotate() incorrectly includes the annotate columns

2018-01-26 Thread Django

#29067: QuerySet.values_list(..., flat=True) combined with .annotate() 
incorrectly
includes the annotate columns
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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:  0|UI/UX:  0
-+-
Changes (by Loic Bistuer):

 * stage:  Unreviewed => 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c3aca543f95206308ef7c87df8246583%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28988: Multi-table inheritance breaks GenericRelation querying

2018-01-26 Thread Django

#28988: Multi-table inheritance breaks GenericRelation querying
--+
 Reporter:  robwa |Owner:  robwa
 Type:  Bug   |   Status:  assigned
Component:  contrib.contenttypes  |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by robwa):

 * owner:  Paulo => robwa


Comment:

 @Paulo, I will try to work on this. If I come up with a patch, I'd like to
 discuss it with you, as I'm not very familiar with the django model
 internals.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.238a6996967995bca8941cb25a54c1b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2018-01-26 Thread Django

#20562: Docs: How to use django ORM with multiprocessing
--+
 Reporter:  Thomas Güttler|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.5
 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 Antony V. Badaykin):

 Replying to [comment:8 Aymeric Augustin]:
 > Most users of the Django ORM use it from multiple processes, since most
 production WSGI servers use multiple processes :-)
 >
 > This question isn't specific to Django. The general problem that you
 can't carry sockets across fork.
 >
 > If your Django process has network connections to remote data stores and
 you want to fork, you need to close these connections before forking.
 (Usually, they're reopened automatically on the next access.)
 >
 > In practice, applications servers fork before Django does anything, **so
 this issue only arises when you fork in a management command**, typically
 because you're trying to use `multiprocessing`.

 What about to add some top-level wrapper, like `MultiprocessingCommand`
 for example, that's carry out about connections and etc?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.807079efd4b538cb51322fdd15731701%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #8851: Add a default option to list_filter in the admin interface

2018-01-26 Thread Django

#8851: Add a default option to list_filter in the admin interface
-+-
 Reporter:  Riskable |Owner:  Harro
     |
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, list_filter,  | Triage Stage:  Accepted
  default|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Harro):

 Ok, I found a much nicer solution for this whole thing, no need to do
 changes to urls at all.

 Say you have an is_archived flag on a model and you want to default filter
 the list to hide archived items:

 {{{
 class ArchivedListFilter(admin.SimpleListFilter):

 title = _('Archived')
 parameter_name = 'show_archived'

 def lookups(self, request, model_admin):
 return (
 ('all', _('Show all')),
 ('archived', _('Show archived only')),
 )

 def queryset(self, request, queryset):
 show_archived = request.GET.get('show_archived')
 if (show_archived == 'all'):
 return queryset.all()
 elif (show_archived == 'archived'):
 return queryset.filter(is_archived=True)
 return queryset.filter(is_archived=False)

 def choices(self, cl):
 yield {
 'selected': self.value() is None,
 'query_string': cl.get_query_string({},
 [self.parameter_name]),
 'display': _('Hide archived'),  # Changed All to Hide
 archived.
 }
 for lookup, title in self.lookup_choices:
 yield {
 'selected': self.value() == force_text(lookup),
 'query_string': cl.get_query_string({
 self.parameter_name: lookup,
 }, []),
 'display': title,
 }
 }}}

 Simply add this filter and by default it will filter and on filter values
 it will either show all items or only the archived items.

 Now it would be nice to be able to change the label in for "All" in the
 choices method without the need to override whole method, so maybe the
 only fix would be to move the label to a propery on SimpleListFilter so
 you can quickly override it.

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

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

43 matches

Mail list logo