Re: [Django] #26940: django-admin makemessages vs. manage.py makemessages

2016-07-22 Thread Django
#26940: django-admin makemessages vs. manage.py makemessages
-+-
 Reporter:  romeroqj |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.9
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translations | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Maybe the documentation should mention that `--settings` must be specified
 to `django-admin` and `python -m django` for them to be interchangeable
 with `manage.py`.

--
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.4a77f39e6cb186e0f33029f170249d83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26941: Remove quotes from uwsgi "env = LANG=…" configuration

2016-07-22 Thread Django
#26941: Remove quotes from uwsgi "env = LANG=…" configuration
---+
 Reporter:  denilsonsa |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 At the very end of
 https://docs.djangoproject.com/en/1.9/howto/deployment/wsgi/uwsgi/
 There is this example line for uwsgi INI configuration:

 {{{
 env = LANG='en_US.UTF-8'
 }}}

 After trying to debug my configuration for hours, I found that line is
 incorrect. Those quotes should be removed. The correct line is:

 {{{
 env = LANG=en_US.UTF-8
 }}}

 How to reproduce it:
 * Ubuntu 16.04
 * Python 3.5.2
 * Django 1.9.8
 * uwsgi 2.0.12-debian

 And add the following lines to the settings.py:
 {{{
 import locale
 import os
 print(os.getenv('LANG', None))
 print(locale.getlocale(), locale.getdefaultlocale())
 print(locale.getpreferredencoding())
 print(sys.getfilesystemencoding())
 }}}

 The broken configuration prints:
 {{{
 'en_US.UTF-8'
 (None, None) ("'en_US", "UTF-8'")
 ANSI_X3.4-1968
 ascii
 }}}

 The correct one prints:
 {{{
 en_US.UTF-8
 ('en_US', 'UTF-8') ('en_US', 'UTF-8')
 UTF-8
 utf-8
 }}}

--
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/053.10779cbbd72b1a99b9a4e15095475274%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26940: django-admin makemessages vs. manage.py makemessages

2016-07-22 Thread Django
#26940: django-admin makemessages vs. manage.py makemessages
--+--
 Reporter:  romeroqj  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Internationalization  |Version:  1.9
 Severity:  Normal|   Keywords:  translations
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 '''django-admin''' and '''manage.py''' are supposed to be interchangeable.

 From the docs(https://docs.djangoproject.com/en/1.9/ref/django-admin/):

 ''The command-line examples throughout this document use django-admin to
 be consistent, but any example can use manage.py or python -m django just
 as well.''

 However, this doesn't seem to be true for ''makemessages''.

 If I run ''manage.py makemessages'' from the top level of the project
 MEDIA_ROOT and STATIC_ROOT are ignored. This isn't precisely a bug because
 that's what the code is intended to do
 
(https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L448),
 but I find it strange specially  for ''--domain djangojs'' because is very
 common for Javascript files to be put in STATIC_ROOT.

 django-admin makemessages doesn't ignore MEDIA_ROOT or STATIC_ROOT and it
 traverses the entire source tree.

 At least this should be explained in the documentation. At best both
 commands should do the exact same. It's very easy to be bitten by this as
 we don't always review the resulting *.po file.

 Am I missing something here?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/051.815618bc7af495edf59162ff3de395ea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26938: Template postmortem on debug page contains invalid HTML

2016-07-22 Thread Django
#26938: Template postmortem on debug page contains invalid HTML
-+--
 Reporter:  jdufresne|Owner:
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.9
 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 jdufresne):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 [https://github.com/django/django/pull/6966 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 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.074d0d27a503c437467d21192af9ab64%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26939: Django 1.9.8 Sitemaps is broken due to "isinstance() arg 2 must be a class, type, or tuple of classes and types"

2016-07-22 Thread Django
#26939: Django 1.9.8 Sitemaps is broken due to "isinstance() arg 2 must be a 
class,
type, or tuple of classes and types"
---+--
 Reporter:  xuchen81   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.9
 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 xuchen81):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> I am using Django version 1.9.8, and mezzanine version 4.1.0.
> The following code failed:
> {{{
> from mezzanine.core.sitemaps import DisplayableSitemap
> sitemaps = {"sitemaps": {"displayable": DisplayableSitemap, 'views':
> SwiftypeSitemap}}
> urlpatterns += patterns("django.contrib.sitemaps.views",
> ("^sitemap\.xml$", "sitemap", sitemaps))
> }}}
> The trace back:
> {{{
> TypeError at /sitemap.xml
> isinstance() arg 2 must be a class, type, or tuple of classes and types
> Request Method: GET
> Request URL:https://xx.com:8787/sitemap.xml
> Django Version: 1.9.8
> Exception Type: TypeError
> Exception Value:
> isinstance() arg 2 must be a class, type, or tuple of classes and types
> Exception Location:
> /srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-
> packages/django/db/models/fields/related.py in get_default, line 908
> Python Executable:  /srv/appdynamics/virtualenvs/corpsite/bin/uwsgi
> Python Version: 2.7.6
> Python Path:
> ['.',
>  '',
>  '/srv/xx/virtualenvs/corpsite/src/supervisor',
>  '/srv/xx/virtualenvs/corpsite/lib/python2.7',
>  '/srv/xx/virtualenvs/corpsite/lib/python2.7/plat-x86_64-linux-
> gnu',
>  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-tk',
>  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-old',
>  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-dynload',
>  '/usr/lib/python2.7',
>  '/usr/lib/python2.7/plat-x86_64-linux-gnu',
>  '/usr/lib/python2.7/lib-tk',
>  '/srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-
> packages',
>  '/srv/xx/www/private']
> Server time:Fri, 22 Jul 2016 17:48:22 -0700
> ...
> ...
>
> /srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-
> packages/django/db/models/fields/related.py in get_default
> if isinstance(field_default, self.remote_field.model): ...
> ▶ Local vars
> VariableValue
> self: 
> field_default: None
> }}}
>
> The problem is here: self.remote_field.model is not a type of class, but
> unicode.

New description:

 I am using Django version 1.9.8, and mezzanine version 4.1.0.
 The following code failed:
 {{{
 from mezzanine.core.sitemaps import DisplayableSitemap
 sitemaps = {"sitemaps": {"displayable": DisplayableSitemap, 'views':
 SwiftypeSitemap}}
 urlpatterns += patterns("django.contrib.sitemaps.views",
 ("^sitemap\.xml$", "sitemap", sitemaps))
 }}}
 The trace back:
 {{{
 TypeError at /sitemap.xml
 isinstance() arg 2 must be a class, type, or tuple of classes and types
 Request Method: GET
 Request URL:https://xx.com:8787/sitemap.xml
 Django Version: 1.9.8
 Exception Type: TypeError
 Exception Value:
 isinstance() arg 2 must be a class, type, or tuple of classes and types
 Exception Location:
 /srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py in get_default, line 908
 Python Executable:  /srv/xx/virtualenvs/corpsite/bin/uwsgi
 Python Version: 2.7.6
 Python Path:
 ['.',
  '',
  '/srv/xx/virtualenvs/corpsite/src/supervisor',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7/plat-x86_64-linux-
 gnu',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-tk',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-old',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-dynload',
  '/usr/lib/python2.7',
  '/usr/lib/python2.7/plat-x86_64-linux-gnu',
  '/usr/lib/python2.7/lib-tk',
  '/srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-packages',
  '/srv/xx/www/private']
 Server time:Fri, 22 Jul 2016 17:48:22 -0700
 ...
 ...

 /srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py in get_default
 if isinstance(field_default, self.remote_field.model): ...
 ▶ Local vars
 VariableValue
 self: 
 field_default: None
 }}}

 The problem is here: self.remote_field.model is not a type of class, but
 unicode.

--

--
Ticket URL: 
Django 

[Django] #26939: Django 1.9.8 Sitemaps is broken due to "isinstance() arg 2 must be a class, type, or tuple of classes and types"

2016-07-22 Thread Django
#26939: Django 1.9.8 Sitemaps is broken due to "isinstance() arg 2 must be a 
class,
type, or tuple of classes and types"
---+
 Reporter:  xuchen81   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I am using Django version 1.9.8, and mezzanine version 4.1.0.
 The following code failed:
 {{{
 from mezzanine.core.sitemaps import DisplayableSitemap
 sitemaps = {"sitemaps": {"displayable": DisplayableSitemap, 'views':
 SwiftypeSitemap}}
 urlpatterns += patterns("django.contrib.sitemaps.views",
 ("^sitemap\.xml$", "sitemap", sitemaps))
 }}}
 The trace back:
 {{{
 TypeError at /sitemap.xml
 isinstance() arg 2 must be a class, type, or tuple of classes and types
 Request Method: GET
 Request URL:https://xx.com:8787/sitemap.xml
 Django Version: 1.9.8
 Exception Type: TypeError
 Exception Value:
 isinstance() arg 2 must be a class, type, or tuple of classes and types
 Exception Location:
 /srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py in get_default, line 908
 Python Executable:  /srv/appdynamics/virtualenvs/corpsite/bin/uwsgi
 Python Version: 2.7.6
 Python Path:
 ['.',
  '',
  '/srv/xx/virtualenvs/corpsite/src/supervisor',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7/plat-x86_64-linux-
 gnu',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-tk',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-old',
  '/srv/xx/virtualenvs/corpsite/lib/python2.7/lib-dynload',
  '/usr/lib/python2.7',
  '/usr/lib/python2.7/plat-x86_64-linux-gnu',
  '/usr/lib/python2.7/lib-tk',
  '/srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-packages',
  '/srv/xx/www/private']
 Server time:Fri, 22 Jul 2016 17:48:22 -0700
 ...
 ...

 /srv/xx/virtualenvs/corpsite/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py in get_default
 if isinstance(field_default, self.remote_field.model): ...
 ▶ Local vars
 VariableValue
 self: 
 field_default: None
 }}}

 The problem is here: self.remote_field.model is not a type of class, but
 unicode.

--
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/051.76c6686f7be4dfdcaae9d8bef3430213%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26938: Template postmortem on debug page contains invalid HTML

2016-07-22 Thread Django
#26938: Template postmortem on debug page contains invalid HTML
-+-
 Reporter:  jdufresne|  Owner:
 Type:  Bug  | Status:  new
Component:  Error reporting  |Version:  1.9
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 There is an extra `` in the template:

 
https://github.com/django/django/blob/32cf01c1c1dcd5fa5d700d0e5117778caf947b74/django/views/debug.py#L729

 This bug was introduced in 1.9, commit
 
[https://github.com/django/django/commit/65a7a0d9eed4f4da9568cf0e7688e7a8c9f01957
 65a7a0d9eed4f4da9568cf0e7688e7a8c9f01957].

 I would appreciate if the fix would be considered for the next 1.9 bug fix
 release. I use a middleware for HTML validation. After upgrading from 1.8,
 this middleware is now reporting some 500 pages as invalid instead of
 showing me the useful information. This was not the case with 1.8.

--
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.1a4a11138812c4211a9801930d9fd540%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26780: Prefetch objects don't work with slices

2016-07-22 Thread Django
#26780: Prefetch objects don't work with slices
-+-
 Reporter:  ludwik   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, slicing| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by asdator):

 The only way to limit this Query (and to not load all the records into
 memory) would be to is to do a `top-n-per-group` query which I don't think
 the `ORM` is capable of.

 What I can suggest is: Instead of limiting the `QuerySet`, find a way to
 filter it.

 For example, get only the `Posts` in the last day, week or a month (based
 on the post-frequency).

 {{{
 Category.objects.prefetch_related(Prefetch(
 'post_set',
 queryset=Post.objects.filter(
 date_published__gte=datetime.date.today()-timedelta(days=7)),
 to_attr='example_posts',
 ))
 }}}

 This way you won't load all the Posts into Memory.

--
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.d5c39a9ac2125222e85253392a83cf69%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26937: 'NoneType' object has no attribute '_meta' in manage.py dumpdata auth.user

2016-07-22 Thread Django
#26937: 'NoneType' object has no attribute '_meta' in manage.py dumpdata 
auth.user
---+
 Reporter:  Adys   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In 1.10rc1 I get the following when running `./manage.py dumpdata
 auth.user --traceback`::

 {{{
 [Traceback (most recent call last):
   File "./manage.py", line 11, in 
 execute_from_command_line(sys.argv)
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/management/base.py", line 305, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/management/base.py", line 356, in execute
 output = self.handle(*args, **options)
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/management/commands/dumpdata.py", line 200, in handle
 object_count=object_count,
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/serializers/__init__.py", line 129, in serialize
 s.serialize(queryset, **options)
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/serializers/base.py", line 79, in serialize
 for count, obj in enumerate(queryset, start=1):
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/management/commands/dumpdata.py", line 161, in
 get_objects
 models = serializers.sort_dependencies(app_list.items())
   File "/home/adys/.local/share/virtualenvs/hs/lib/python3.5/site-
 packages/django/core/serializers/__init__.py", line 195, in
 sort_dependencies
 if field.remote_field.through._meta.auto_created:
 AttributeError: 'NoneType' object has no attribute '_meta'
 }}}

 For reference, here is my user model:
 
https://github.com/HearthSim/HSReplay.net/blob/51c269f2cc329d859df70705e2181666d443434c/hsreplaynet/accounts/models.py#L26-L36

--
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/047.a329c15db1318863d2f0f5be7958c002%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

2016-07-22 Thread Django
#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sqlite nose| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by jensneuhaus):

 * cc: kontakt@… (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/068.188a8d51db1f39c3697e97edd0934ddd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #15665: Inline admins are broken when primary key is not an AutoField and not editable.

2016-07-22 Thread Django
#15665: Inline admins are broken when primary key is not an AutoField and not
editable.
-+
 Reporter:  sebastian_noack  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 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 timgraham):

 * needs_tests:  1 => 0


Comment:

 [https://github.com/django/django/pull/6818 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 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/073.5cb663aef12243bf5088af63c3f13919%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #15665: Inline admins are broken when primary key is not an AutoField and not editable.

2016-07-22 Thread Django
#15665: Inline admins are broken when primary key is not an AutoField and not
editable.
-+
 Reporter:  sebastian_noack  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by timgraham):

 I closed #26934 as a duplicate.

--
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/073.eab9a119737ff43ec5198d173650820c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26934: Admin inline save fails when inline contains readonly primary key

2016-07-22 Thread Django
#26934: Admin inline save fails when inline contains readonly primary key
---+--
 Reporter:  LeeKevin   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Looks like a duplicate of #15665.

--
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.633c9946d5c9d2013cfe1f901d8c588e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26935: DB connections stuck in closed state when using Django ORM in daemon

2016-07-22 Thread Django
#26935: DB connections stuck in closed state when using Django ORM in daemon
-+-
 Reporter:  noky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (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
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I think this is a duplicate of #24810. Can you confirm?

--
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/062.45bd2c8f971355bf5844def955fcf766%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26928: Change checkbox/radio checked attribute to HTML5 boolean style

2016-07-22 Thread Django
#26928: Change checkbox/radio checked attribute to HTML5 boolean style
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 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
-+-

Comment (by jdufresne):

 [https://groups.google.com/forum/#!topic/django-developers/06FZAJooX6w
 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/067.333b715f5ffee97a4cef6c160772ba62%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26936: Stale content type deletion stops working if all models in an app are deleted

2016-07-22 Thread Django
#26936: Stale content type deletion stops working if all models in an app are
deleted
--+
 Reporter:  bmispelon |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  1.9
 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 bmispelon):

 * owner:  bmispelon =>
 * 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 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.cf2e8c610fe062377368663dcc06e3cc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #18348: Make parts of the sessions API public

2016-07-22 Thread Django
#18348: Make parts of the sessions API public
---+
 Reporter:  aaugustin  |Owner:  vpnosum
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   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 Tim Graham ):

 In [changeset:"b4fa102503076e62db13f76bbee4a3c880926676" b4fa102]:
 {{{
 #!CommitTicketReference repository=""
 revision="b4fa102503076e62db13f76bbee4a3c880926676"
 [1.10.x] Fixed #18348 -- Documented SesssionStore.create()

 Backport of 32cf01c1c1dcd5fa5d700d0e5117778caf947b74 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.7ebb3c00c907c4c7c669ff250a33f329%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #18348: Make parts of the sessions API public

2016-07-22 Thread Django
#18348: Make parts of the sessions API public
---+
 Reporter:  aaugustin  |Owner:  vpnosum
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   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 Tim Graham ):

 In [changeset:"b0b0a02af53a36776435133480334dc52df0301f" b0b0a02]:
 {{{
 #!CommitTicketReference repository=""
 revision="b0b0a02af53a36776435133480334dc52df0301f"
 [1.9.x] Fixed #18348 -- Documented SesssionStore.create()

 Backport of 32cf01c1c1dcd5fa5d700d0e5117778caf947b74 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.13239b36a96b53e0763eb4701ad67983%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #18348: Make parts of the sessions API public

2016-07-22 Thread Django
#18348: Make parts of the sessions API public
---+
 Reporter:  aaugustin  |Owner:  vpnosum
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   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 Tim Graham ):

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


Comment:

 In [changeset:"32cf01c1c1dcd5fa5d700d0e5117778caf947b74" 32cf01c1]:
 {{{
 #!CommitTicketReference repository=""
 revision="32cf01c1c1dcd5fa5d700d0e5117778caf947b74"
 Fixed #18348 -- Documented SesssionStore.create()
 }}}

--
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.2c0040e9bda6a12d2a4663bde3fc5996%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26936: Stale content type deletion stops working if all models in an app are deleted

2016-07-22 Thread Django
#26936: Stale content type deletion stops working if all models in an app are
deleted
-+-
 Reporter:  bmispelon|Owner:  bmispelon
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.9
  contrib.contenttypes   |
 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 timgraham):

 * 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.6f248cfb9cff5b415c148ccb30dbe287%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26929: Deprecate `extra_context` parameter in `contrib.auth.views.logout_then_login`

2016-07-22 Thread Django
#26929: Deprecate `extra_context` parameter in
`contrib.auth.views.logout_then_login`
-+-
 Reporter:  andrewnester |Owner:
 Type:   |  andrewnester
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Left comments for improvement on the 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 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/070.f6fc10c1b54e4cfb2552cadfc431e9a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26936: Stale content type deletion stops working if all models in an app are deleted

2016-07-22 Thread Django
#26936: Stale content type deletion stops working if all models in an app are
deleted
+
   Reporter:  bmispelon |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.contenttypes  |Version:  1.9
   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 |
+
 Steps to reproduce:

 1) Create an app with one model in its `models.py`
 2) Add it to `settings.INSTALLED_APPS`, run `makemakigrations`, and
 `migrate`
 3) Delete the model from `models.py`, run `makemigrations`, then `migrate`



 At step 3), Django deletes the model from the database (as expected) but
 doesn't prompt the user to delete the now stale content type (as normally
 happens when you run `migrate`).


 I believe this is called by the `if not app_config.models_module: return`
 statement in `update_contenttypes()` [1]

 [1]
 
https://github.com/django/django/blob/master/django/contrib/contenttypes/management.py#L95-L96

--
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.0c07620e704028a773fa6d9b59fb99c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26936: Stale content type deletion stops working if all models in an app are deleted

2016-07-22 Thread Django
#26936: Stale content type deletion stops working if all models in an app are
deleted
-+-
 Reporter:  bmispelon|Owner:  bmispelon
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.9
  contrib.contenttypes   |
 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 bmispelon):

 * owner:  nobody => bmispelon
 * 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/067.3eb02e721e9630c0f1981c0f2903578a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26834: MinValueValidator/MaxValueValidator not forwarded to form field for ModelForm

2016-07-22 Thread Django
#26834: MinValueValidator/MaxValueValidator not forwarded to form field for
ModelForm
-+-
 Reporter:  sergei-maertens  |Owner:  sgzsh269
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  MaxValueValidator,   | Triage Stage:  Accepted
  MinValueValidator, ModelForm,  |
  IntegerField   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Comments for improvement on the PR (and some failing tests to be fixed).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/073.118202a0e131ad0403a1e35b97ef3a8e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26511: Django 1.9 and Postgres 9.4 jsonb string containment inside JSONField

2016-07-22 Thread Django
#26511: Django 1.9 and Postgres 9.4 jsonb string containment inside JSONField
--+
 Reporter:  eoinmurray|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  postgres, jsonb   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by jensneuhaus):

 * has_patch:  0 => 1


Comment:

 Hi. I submitted a patch to include it in the docs:
 https://github.com/django/django/pull/6965

--
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/068.8985507edc2011f8fe3187cd973c9bf1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26935: DB connections stuck in closed state when using Django ORM in daemon

2016-07-22 Thread Django
#26935: DB connections stuck in closed state when using Django ORM in daemon
--+
 Reporter:  noky  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal| Resolution:
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by noky):

 * Attachment "django-daemon-test.tgz" added.

 barebones django "daemon" project that reproduces 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 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/062.401f42abdf6804bdb28c9731c657b8f8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26834: MinValueValidator/MaxValueValidator not forwarded to form field for ModelForm

2016-07-22 Thread Django
#26834: MinValueValidator/MaxValueValidator not forwarded to form field for
ModelForm
-+-
 Reporter:  sergei-maertens  |Owner:  sgzsh269
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  MaxValueValidator,   | Triage Stage:  Accepted
  MinValueValidator, ModelForm,  |
  IntegerField   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sgzsh269):

 * version:  1.9 => 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/073.f349674cad8cf04ff6c2c508a4ed064a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26935: DB connections stuck in closed state when using Django ORM in daemon

2016-07-22 Thread Django
#26935: DB connections stuck in closed state when using Django ORM in daemon
--+
 Reporter:  noky  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 '''Situation:'''
 1. A long-running daemon process is using the Django ORM
 2. The underlying database gets restarted, causing existing db
 connection(s) to become invalid

 '''Problem:'''
 A subsequent db read using the ORM fail with the exception:
 {{{
   File "main.py", line 22, in 
 testread()
   File "main.py", line 14, in testread
 user = User.objects.all()[0]
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 297, in __getitem__
 return list(qs)[0]
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 258, in __iter__
 self._fetch_all()
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 1074, in _fetch_all
 self._result_cache = list(self.iterator())
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 52, in __iter__
 results = compiler.execute_sql()
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/sql/compiler.py", line 848, in execute_sql
 cursor.execute(sql, params)
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/utils.py", line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
 OperationalError: terminating connection due to administrator command
 server closed the connection unexpectedly
 This probably means the server terminated abnormally
 before or while processing the request.
 }}}

 Further subsequent db reads using the ORM yield a different (yet
 consistent) exception:
 {{{
   File "main.py", line 22, in 
 testread()
   File "main.py", line 14, in testread
 user = User.objects.all()[0]
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 297, in __getitem__
 return list(qs)[0]
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 258, in __iter__
 self._fetch_all()
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 1074, in _fetch_all
 self._result_cache = list(self.iterator())
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 52, in __iter__
 results = compiler.execute_sql()
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/models/sql/compiler.py", line 846, in execute_sql
 cursor = self.connection.cursor()
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/backends/base/base.py", line 233, in cursor
 cursor = self.make_cursor(self._cursor())
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/backends/base/base.py", line 206, in _cursor
 return self.create_cursor()
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/utils.py", line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/backends/base/base.py", line 206, in _cursor
 return self.create_cursor()
   File "/home/noky/Downloads/django-standalone/venv/local/lib/python2.7
 /site-packages/django/db/backends/postgresql/base.py", line 210, in
 create_cursor
 cursor = self.connection.cursor()
 InterfaceError: connection already closed
 }}}

 '''Environment:'''
 * Ubuntu 14.04
 * PostgreSQL 9.5
 * Django 1.9.8
 * psycopg2 2.6.2

 '''To reproduce problem:'''
 * Download attached project files and untar
 * Create a PostgreSQL database `testdb`
 * Edit `settings.py` to setup db settings
 * Run `setup.sh` to create virtualenv, 

Re: [Django] #26834: MinValueValidator/MaxValueValidator not forwarded to form field for ModelForm

2016-07-22 Thread Django
#26834: MinValueValidator/MaxValueValidator not forwarded to form field for
ModelForm
-+-
 Reporter:  sergei-maertens  |Owner:  sgzsh269
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  MaxValueValidator,   | Triage Stage:  Accepted
  MinValueValidator, ModelForm,  |
  IntegerField   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sgzsh269):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/073.2db4b902ba1ab371151c947831e68be4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26934: Admin inline save fails when inline contains readonly primary key

2016-07-22 Thread Django
#26934: Admin inline save fails when inline contains readonly primary key
---+
 Reporter:  LeeKevin   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 '''Example:''

 For an AbstractBaseCode model (password reset), the "code" field is as
 follows (note the primary_key argument):
 {{{
 code = models.CharField(_('code'), max_length=40,
 primary_key=True)
 }}}

 And the inline admin class is:

 {{{
 class PasswordResetCodeInline(admin.TabularInline):
 model = PasswordResetCode
 fieldsets = (
 (None, {
 'fields': ('code', 'created_at')
 }),
 )
 readonly_fields = ('code', 'created_at')

 def has_add_permission(self, request):
 return False
 }}}


 When saving a user in Django admin, which contains the
 PasswordResetCodeInline, the following error is issued:

 {{{
 MultiValueDictKeyError at /admin/accounts/user/30/change/
 "'passwordresetcode_set-0-code'"

 Exception location: /.../python3.5/site-
 packages/django/utils/datastructures.py in __getitem__, line 85
 }}}

 This occurs because line 587 in ModelForm._construct_form in
 forms/models.py looks for the primary key "code" within the editable
 fields. Since it is readonly, there is no input or hidden field passed
 along that includes the primary key.

 Here is a snippet where the error occurs (on the last line):

 {{{
 def _construct_form(self, i, **kwargs):
 if self.is_bound and i < self.initial_form_count():
 pk_key = "%s-%s" % (self.add_prefix(i),
 self.model._meta.pk.name)
 pk = self.data[pk_key]
 }}}



 
 Traceback:

 {{{
 Traceback (most recent call last):
   File "/.../lib/python3.5/site-packages/django/core/handlers/base.py",
 line 149, in get_response
 response = self.process_exception_by_middleware(e, request)
   File "/.../lib/python3.5/site-packages/django/core/handlers/base.py",
 line 147, in get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/.../lib/python3.5/site-packages/django/contrib/admin/options.py",
 line 541, in wrapper
 return self.admin_site.admin_view(view)(*args, **kwargs)
   File "/.../lib/python3.5/site-packages/django/utils/decorators.py", line
 149, in _wrapped_view
 response = view_func(request, *args, **kwargs)
   File "/.../lib/python3.5/site-
 packages/django/views/decorators/cache.py", line 57, in _wrapped_view_func
 response = view_func(request, *args, **kwargs)
   File "/.../lib/python3.5/site-packages/django/contrib/admin/sites.py",
 line 244, in inner
 return view(request, *args, **kwargs)
   File "/.../lib/python3.5/site-packages/django/contrib/admin/options.py",
 line 1440, in change_view
 return self.changeform_view(request, object_id, form_url,
 extra_context)
   File "/.../lib/python3.5/site-packages/django/utils/decorators.py", line
 67, in _wrapper
 return bound_func(*args, **kwargs)
   File "/.../lib/python3.5/site-packages/django/utils/decorators.py", line
 149, in _wrapped_view
 response = view_func(request, *args, **kwargs)
   File "/.../lib/python3.5/site-packages/django/utils/decorators.py", line
 63, in bound_func
 return func.__get__(self, type(self))(*args2, **kwargs2)
   File
 
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/contextlib.py",
 line 30, in inner
 return func(*args, **kwds)
   File "/.../lib/python3.5/site-packages/django/contrib/admin/options.py",
 line 1377, in changeform_view
 if all_valid(formsets) and form_validated:
   File "/.../lib/python3.5/site-packages/django/forms/formsets.py", line
 451, in all_valid
 if not formset.is_valid():
   File "/.../lib/python3.5/site-packages/django/forms/formsets.py", line
 316, in is_valid
 self.errors
   File "/.../lib/python3.5/site-packages/django/forms/formsets.py", line
 290, in errors
 self.full_clean()
   File "/.../lib/python3.5/site-packages/django/forms/formsets.py", line
 338, in full_clean
 form = self.forms[i]
   File "/.../lib/python3.5/site-packages/django/utils/functional.py", line
 33, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "/.../lib/python3.5/site-packages/django/forms/formsets.py", line
 144, in forms
 for i in range(self.total_form_count())]
   File "/.../lib/python3.5/site-packages/django/forms/formsets.py", line
 144, in 
 for i in range(self.total_form_count())]
   File "/.../lib/python3.5/site-packages/django/forms/models.py", line
 881, in _construct_form
 form = super(BaseInlineFormSet, self)._construct_form(i, **kwargs)
   File "/.../lib/python3.5/site-packages/django/forms/models.py", line
 587, in 

Re: [Django] #26933: Test for #26804 has a tendency to fail on Oracle databases

2016-07-22 Thread Django
#26933: Test for #26804 has a tendency to fail on Oracle databases
-+-
 Reporter:  jensen-cochran   |Owner:  jensen-
 |  cochran
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  update_or_create | Triage Stage:
  test tests |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jensen-cochran):

 * Attachment "26933.diff" 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/072.7ed457a8181d2f8dd517eb1a7e82335c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26933: Test for #26804 has a tendency to fail on Oracle databases

2016-07-22 Thread Django
#26933: Test for #26804 has a tendency to fail on Oracle databases
-+-
 Reporter:  jensen-cochran   |Owner:  jensen-
 |  cochran
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  update_or_create | Triage Stage:
  test tests |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by jensen-cochran:

Old description:

> According to comment on the pull request for #26804
> (https://github.com/django/django/pull/6831), the test for the issue
> (written by me) has a tendency to fail on Oracle databases. The test
> assumes that the database will take no longer than 50ms to lock the
> associated row, but it seems that this assumption is incorrect in some
> cases.
>
> I have written a patch for this that should mostly fix the issue.
> Instead of assuming the database has locked the row,  I set a value in
> the spawned thread after select_for_update has ran and poll that value in
> the main thread.
>
> However, there still has to be some kind of timeout as we cannot wait
> forever for the database to lock the row.  I have set that timeout at 5
> seconds, and if the timeout occurs the test is skipped. Alternatively, I
> could fail if the timeout occurs, but this has potential to fail somewhat
> randomly as it is doing now.  If update_or_create were ever changed such
> that the locking behavior was removed, the test would fail so it should
> still serve its purpose.

New description:

 According to comment on the pull request for #26804
 (https://github.com/django/django/pull/6831), the test for the issue
 (written by me) has a tendency to fail on Oracle databases. The test
 assumes that the database will take no longer than 50ms to lock the
 associated row, but it seems that this assumption is incorrect in some
 cases.

 I have written a patch for this that should mostly fix the issue.  Instead
 of assuming the database has locked the row,  I set a value in the spawned
 thread after select_for_update has ran and poll that value in the main
 thread.

 However, there still has to be some kind of timeout as we cannot wait
 forever for the database to lock the row.  I have set that timeout at 0.5
 seconds and have changed the thread/callable sleep time to 0.5 seconds as
 well to allow for more room for slow databases.  There is no reason to
 have the timeout be any longer than the thread sleep time, because once
 the main thread waits that long the assertion would pass no matter what
 anyway. If the timeout expires the test is skipped.

 Alternatively, I could fail if the timeout occurs, but this has potential
 to fail somewhat randomly as it is doing now.

 If update_or_create were ever changed such that the locking behavior was
 removed, the test would fail as expected so it should still serve its
 purpose.

--

--
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.ab8a5e24a077f4f0689d1b4d36c12f0f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26882: Add test(s) for django.contrib.auth.views.logout_then_login

2016-07-22 Thread Django
#26882: Add test(s) for django.contrib.auth.views.logout_then_login
-+-
 Reporter:  timgraham|Owner:
 Type:   |  andrewnester
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"dde6288fbe97c7053e67b613fec3366f3c298cf4" dde6288f]:
 {{{
 #!CommitTicketReference repository=""
 revision="dde6288fbe97c7053e67b613fec3366f3c298cf4"
 Fixed #26882 -- Added tests for auth.views.logout_then_login().
 }}}

--
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.2394a02d03965fbbe4c3c4559f294a3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26933: Test for #26804 has a tendency to fail on Oracle databases

2016-07-22 Thread Django
#26933: Test for #26804 has a tendency to fail on Oracle databases
-+-
 Reporter:  jensen-cochran   |Owner:  jensen-
 |  cochran
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  update_or_create | Triage Stage:
  test tests |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jensen-cochran):

 * Attachment "26933.diff" 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/072.1c65cd0fca4e8333545644143366e61a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26933: Test for #26804 has a tendency to fail on Oracle databases

2016-07-22 Thread Django
#26933: Test for #26804 has a tendency to fail on Oracle databases
-+-
 Reporter:  jensen-cochran   |Owner:  jensen-
 |  cochran
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  update_or_create | Triage Stage:
  test tests |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jensen-cochran):

 * Attachment "26933.diff" 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/072.7d663dc2f20fbb9734993bef992d81ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26933: Test for #26804 has a tendency to fail on Oracle databases

2016-07-22 Thread Django
#26933: Test for #26804 has a tendency to fail on Oracle databases
-+-
 Reporter:  jensen-cochran   |Owner:  jensen-
 |  cochran
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  update_or_create | Triage Stage:
  test tests |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jensen-cochran):

 * owner:   => jensen-cochran
 * needs_better_patch:   => 0
 * status:  new => assigned
 * needs_tests:   => 0
 * needs_docs:   => 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 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.bb84eefb957ca5929ad65c21e10a0543%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26933: Test for #26804 has a tendency to fail on Oracle databases

2016-07-22 Thread Django
#26933: Test for #26804 has a tendency to fail on Oracle databases
--+
 Reporter:  jensen-cochran|  Owner:
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal| Resolution:
 Keywords:  update_or_create test tests   |   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by jensen-cochran):

 * Attachment "26933.diff" 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/072.89bd8553fa5a0231b54a86a06abc6e52%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26933: Test for #26804 has a tendency to fail on Oracle databases

2016-07-22 Thread Django
#26933: Test for #26804 has a tendency to fail on Oracle databases
-+-
 Reporter:  jensen-cochran   |  Owner:
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  master
  (models, ORM)  |   Keywords:  update_or_create test
 Severity:  Normal   |  tests
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+-
 According to comment on the pull request for #26804
 (https://github.com/django/django/pull/6831), the test for the issue
 (written by me) has a tendency to fail on Oracle databases. The test
 assumes that the database will take no longer than 50ms to lock the
 associated row, but it seems that this assumption is incorrect in some
 cases.

 I have written a patch for this that should mostly fix the issue.  Instead
 of assuming the database has locked the row,  I set a value in the spawned
 thread after select_for_update has ran and poll that value in the main
 thread.

 However, there still has to be some kind of timeout as we cannot wait
 forever for the database to lock the row.  I have set that timeout at 5
 seconds, and if the timeout occurs the test is skipped. Alternatively, I
 could fail if the timeout occurs, but this has potential to fail somewhat
 randomly as it is doing now.  If update_or_create were ever changed such
 that the locking behavior was removed, the test would fail so it should
 still serve its purpose.

--
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.4269e9bd16915088909ecc552cc77a47%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26928: Change checkbox/radio checked attribute to HTML5 boolean style

2016-07-22 Thread Django
#26928: Change checkbox/radio checked attribute to HTML5 boolean style
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 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
-+-

Comment (by timgraham):

 I'd like to ask on the DevelopersMailingList if anyone has concerns about
 this change.

--
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.9bdc8bc980663478430a66112b234ee8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26925: Add a link to aggregation ordering interaction from Meta.ordering docs (was: ORM changes grouping when default ordering is set)

2016-07-22 Thread Django
#26925: Add a link to aggregation ordering interaction from Meta.ordering docs
--+
 Reporter:  njoyard   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  aggregation   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * type:  Bug => Cleanup/optimization
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted
 * component:  Database layer (models, ORM) => Documentation


Comment:

 [https://github.com/django/django/pull/6963 PR] to add a doc link.

--
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.499e1cd5cf5b4a76b24386d099ada5d4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26932: CALL Service + 18 44-307-0840 HUSHMAIL support phone number

2016-07-22 Thread Django
#26932: CALL Service + 18 44-307-0840 HUSHMAIL support phone number
---+
 Reporter:  sibyl  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Plus SHINE 1 8 44 307 08,40` HUSHMAIL support phone number CALL Service +
 18 44-307-0840 HUSHMAIL support phone number HUSHMAIL Customer care,
 service Phone Number W.i.t.t.l.y ŒœŒæŒ @@ⁿ££Call Toll Free @@ 1 844 307
 0840 HUSHMAIL support phone Number, usa Intuit@(1-844-307-0840)HUSHMAIL
 Tech Support Phone 1 844 307 0840 Number Intuit@(1-844-307-0840)HUSHMAIL
 Tech Support Phone Number Antivirusvides online solution for all
 USA//-CANADA clients.1 844 307 0840 For any help of query call (1 844 307
 0840) to get all 1 844 307 0840HUSHMAIL account solution. @@Call,
 (1-844-307-0840) for all type help by HUSHMAIL tech support phone number,
 Intuit HUSHMAIL Tech Support Phone Number, HUSHMAIL Help Desk Phone
 Number, HUSHMAIL tech support number, HUSHMAIL technical support phone
 number,@@@ HUSHMAIL phone number, HUSHMAIL technical support number,
 HUSHMAIL support phone number, HUSHMAIL technical support, HUSHMAIL
 Customer Service Phone Number, HUSHMAIL Customer Service Number, HUSHMAIL
 Customer Support Phone Number, HUSHMAIL Customer Support Number,
 HUSHMAIL Customer Service Helpline Number, HUSHMAIL Customer Care Number,
 HUSHMAIL support team phone number, @ HUSHMAIL help number-HUSHMAIL
 Helpline Number; HUSHMAIL help phone number-HUSHMAIL Helpline Number,
 HUSHMAIL Tech Support Toll free Number, HUSHMAIL Support Telephone Number,
 HUSHMAIL Tech Support Telephone number, HUSHMAIL Tech Support contact
 number, HUSHMAIL support contact number, HUSHMAIL technical support
 contact number. Call, HUSHMAIL tech support phone number, Intuit HUSHMAIL
 Tech Support Phone Number, HUSHMAIL Help Desk Phone Number, HUSHMAIL tech
 support number, HUSHMAIL technical support phone number, HUSHMAIL phone
 number, HUSHMAIL technical support number, HUSHMAIL support phone number.
 It is very popular toll free number which Antivirusvide by HUSHMAIL
 technical support, HUSHMAIL Customer Service Phone Number, HUSHMAIL
 Customer Service Number, HUSHMAIL Customer Support Phone Number, HUSHMAIL
 Customer Support Number, HUSHMAIL Customer Service Helpline Number,
 HUSHMAIL Customer Care Number, HUSHMAIL support team phone number. Call,
 HUSHMAIL tech support phone number, Intuit HUSHMAIL Tech Support Phone
 Number, HUSHMAIL Help Desk Phone Number, HUSHMAIL tech support number,
 HUSHMAIL technical support phone number, HUSHMAIL phone number, HUSHMAIL
 technical support number, HUSHMAIL support phone number, HUSHMAIL
 technical support, HUSHMAIL Customer Service Phone Number, HUSHMAIL
 Customer Service Number, HUSHMAIL Customer Support Phone Number, HUSHMAIL
 Customer Support Number, HUSHMAIL Customer Service Helpline Number,
 HUSHMAIL Customer Care Number, HUSHMAIL support team phone number,
 HUSHMAIL help number-HUSHMAIL Helpline Number; HUSHMAIL help phone number,
 HUSHMAIL Helpline Number, HUSHMAIL Tech Support Toll free Number, HUSHMAIL
 Support Telephone Number, HUSHMAIL Tech Support Telephone number, HUSHMAIL
 Tech Support contact number, HUSHMAIL support contact number, HUSHMAIL
 technical support contact number, HUSHMAIL Antivirus support phone number,
 HUSHMAIL payroll support phone number. HUSHMAIL payroll customer support
 phone number HUSHMAIL Support Helpline Number, HUSHMAIL contact number
 HUSHMAIL tech support phone number HUSHMAIL support team phone number
 HUSHMAIL contact number 1844-307-0840 HUSHMAIL technical help telephone
 number, HUSHMAIL technical help contact number, HUSHMAIL technical support
 contact number, HUSHMAIL contact number, HUSHMAIL contact phone number,
 HUSHMAIL contact telephone number, HUSHMAIL 24 hour contact number,
 HUSHMAIL customer support contact number, HUSHMAIL customer service
 contact number, HUSHMAIL official number, HUSHMAIL official contact
 number, HUSHMAIL 844 contact number, HUSHMAIL toll free number, 844 number
 for HUSHMAIL support, HUSHMAIL 24/7 support phone number HUSHMAIL
 ANTIVIRUS support phone number,HUSHMAIL ANTIVIRUS support phone
 number,HUSHMAIL ANTIVIRUS help phone number, HUSHMAIL ANTIVIRUS technical
 support number.HUSHMAIL ANTIVIRUS support number, HUSHMAIL ANTIVIRUS phone
 number, HUSHMAIL ANTIVIRUS tech support number, HUSHMAIL ANTIVIRUS
 customer support number, HUSHMAIL ANTIVIRUS customer support phone number,
 HUSHMAIL ANTIVIRUS customer service phone number, HUSHMAIL ANTIVIRUS
 payroll customer service phone number, HUSHMAIL ANTIVIRUS support phone
 number. Help@Call 1-844-307-0840/.HUSHMAIL 24/7 support phone
 number,HUSHMAIL telephone number for support? call
 

[Django] #26931: Plus SHINE 1 8 44 307 08, 40` ONEDRIVE support phone number

2016-07-22 Thread Django
#26931: Plus SHINE 1 8 44 307 08,40` ONEDRIVE support phone number
---+
 Reporter:  sibyl  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Plus SHINE 1 8 44 307 08,40` ONEDRIVE support phone number CALL Service +
 18 44-307-0840 ONEDRIVE support phone number ONEDRIVE Customer care,
 service Phone Number W.i.t.t.l.y ŒœŒæŒ @@ⁿ££Call Toll Free @@ 1 844 307
 0840 ONEDRIVE support phone Number, usa Intuit@(1-844-307-0840)ONEDRIVE
 Tech Support Phone 1 844 307 0840 Number Intuit@(1-844-307-0840)ONEDRIVE
 Tech Support Phone Number Antivirusvides online solution for all
 USA//-CANADA clients.1 844 307 0840 For any help of query call (1 844 307
 0840) to get all 1 844 307 0840ONEDRIVE account solution. @@Call,
 (1-844-307-0840) for all type help by ONEDRIVE tech support phone number,
 Intuit ONEDRIVE Tech Support Phone Number, ONEDRIVE Help Desk Phone
 Number, ONEDRIVE tech support number, ONEDRIVE technical support phone
 number,@@@ ONEDRIVE phone number, ONEDRIVE technical support number,
 ONEDRIVE support phone number, ONEDRIVE technical support, ONEDRIVE
 Customer Service Phone Number, ONEDRIVE Customer Service Number, ONEDRIVE
 Customer Support Phone Number, ONEDRIVE Customer Support Number,
 ONEDRIVE Customer Service Helpline Number, ONEDRIVE Customer Care Number,
 ONEDRIVE support team phone number, @ ONEDRIVE help number-ONEDRIVE
 Helpline Number; ONEDRIVE help phone number-ONEDRIVE Helpline Number,
 ONEDRIVE Tech Support Toll free Number, ONEDRIVE Support Telephone Number,
 ONEDRIVE Tech Support Telephone number, ONEDRIVE Tech Support contact
 number, ONEDRIVE support contact number, ONEDRIVE technical support
 contact number. Call, ONEDRIVE tech support phone number, Intuit ONEDRIVE
 Tech Support Phone Number, ONEDRIVE Help Desk Phone Number, ONEDRIVE tech
 support number, ONEDRIVE technical support phone number, ONEDRIVE phone
 number, ONEDRIVE technical support number, ONEDRIVE support phone number.
 It is very popular toll free number which Antivirusvide by ONEDRIVE
 technical support, ONEDRIVE Customer Service Phone Number, ONEDRIVE
 Customer Service Number, ONEDRIVE Customer Support Phone Number, ONEDRIVE
 Customer Support Number, ONEDRIVE Customer Service Helpline Number,
 ONEDRIVE Customer Care Number, ONEDRIVE support team phone number. Call,
 ONEDRIVE tech support phone number, Intuit ONEDRIVE Tech Support Phone
 Number, ONEDRIVE Help Desk Phone Number, ONEDRIVE tech support number,
 ONEDRIVE technical support phone number, ONEDRIVE phone number, ONEDRIVE
 technical support number, ONEDRIVE support phone number, ONEDRIVE
 technical support, ONEDRIVE Customer Service Phone Number, ONEDRIVE
 Customer Service Number, ONEDRIVE Customer Support Phone Number, ONEDRIVE
 Customer Support Number, ONEDRIVE Customer Service Helpline Number,
 ONEDRIVE Customer Care Number, ONEDRIVE support team phone number,
 ONEDRIVE help number-ONEDRIVE Helpline Number; ONEDRIVE help phone number,
 ONEDRIVE Helpline Number, ONEDRIVE Tech Support Toll free Number, ONEDRIVE
 Support Telephone Number, ONEDRIVE Tech Support Telephone number, ONEDRIVE
 Tech Support contact number, ONEDRIVE support contact number, ONEDRIVE
 technical support contact number, ONEDRIVE Antivirus support phone number,
 ONEDRIVE payroll support phone number. ONEDRIVE payroll customer support
 phone number ONEDRIVE Support Helpline Number, ONEDRIVE contact number
 ONEDRIVE tech support phone number ONEDRIVE support team phone number
 ONEDRIVE contact number 1844-307-0840 ONEDRIVE technical help telephone
 number, ONEDRIVE technical help contact number, ONEDRIVE technical support
 contact number, ONEDRIVE contact number, ONEDRIVE contact phone number,
 ONEDRIVE contact telephone number, ONEDRIVE 24 hour contact number,
 ONEDRIVE customer support contact number, ONEDRIVE customer service
 contact number, ONEDRIVE official number, ONEDRIVE official contact
 number, ONEDRIVE 844 contact number, ONEDRIVE toll free number, 844 number
 for ONEDRIVE support, ONEDRIVE 24/7 support phone number ONEDRIVE
 ANTIVIRUS support phone number,ONEDRIVE ANTIVIRUS support phone
 number,ONEDRIVE ANTIVIRUS help phone number, ONEDRIVE ANTIVIRUS technical
 support number.ONEDRIVE ANTIVIRUS support number, ONEDRIVE ANTIVIRUS phone
 number, ONEDRIVE ANTIVIRUS tech support number, ONEDRIVE ANTIVIRUS
 customer support number, ONEDRIVE ANTIVIRUS customer support phone number,
 ONEDRIVE ANTIVIRUS customer service phone number, ONEDRIVE ANTIVIRUS
 payroll customer service phone number, ONEDRIVE ANTIVIRUS support phone
 number. Help@Call 1-844-307-0840/.ONEDRIVE 24/7 support phone
 number,ONEDRIVE telephone number for support? call
 

Re: [Django] #26927: Subwidgets not passed required and disabled attributes in BoundField.__iter__()

2016-07-22 Thread Django
#26927: Subwidgets not passed required and disabled attributes in
BoundField.__iter__()
---+
 Reporter:  jdufresne  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  1.10   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

 * keywords:   => 1.10
 * 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.f1b41ef3e7c2b065096ebe76f636867c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26926: Dual index migration bug?

2016-07-22 Thread Django
#26926: Dual index migration bug?
+--
 Reporter:  Vaal|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.9
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by timgraham):

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


--
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/062.0d0433f123d8f25d7f6e56894b29f549%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26930: makemigrations tries to access default databases even when set to empty

2016-07-22 Thread Django
#26930: makemigrations tries to access default databases even when set to empty
-+
 Reporter:  lizlemon |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.10
 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 timgraham):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  master => 1.10
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Regression in 1.10 due to 02ae5fd31a56ffb42feadb49c1f3870ba0a24869.

--
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.ac90e375b5b1d4b7528e91dc688a049b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26928: Change checkbox/radio checked attribute to HTML5 boolean style

2016-07-22 Thread Django
#26928: Change checkbox/radio checked attribute to HTML5 boolean style
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 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
-+-

Comment (by jdufresne):

 > Are there any backwards-compatibility concerns for projects not using an
 HTML5 doctype?

 I'm not aware of any for modern browsers. Just now, I tested the following
 HTML document:

 {{{
 
   
 Test
   
   
 
   
 
   
 
 }}}

 Against the doctypes listed on [https://www.w3.org/QA/2002/04/valid-dtd-
 list.html w3.org].

 All of these doctypes worked with recent versions of Firefox and Chrome --
 they rendered the checkbox as checked on page reload. I currently do not
 have easy access to IE for testing.

 If you think it would help, I could add a blurb to the "Backwards
 incompatible changes" section of the release notes.

--
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.a82cb222712b9a4720923d58705667c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26929: Deprecate `extra_context` parameter in `contrib.auth.views.logout_then_login`

2016-07-22 Thread Django
#26929: Deprecate `extra_context` parameter in
`contrib.auth.views.logout_then_login`
-+-
 Reporter:  andrewnester |Owner:
 Type:   |  andrewnester
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * version:   => master
 * component:  Uncategorized => contrib.auth
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/6944 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 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/070.9895c95b7da2308ad7f3f1b028fdc7a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26899: Document why RawSQL requires parameters

2016-07-22 Thread Django
#26899: Document why RawSQL requires parameters
-+-
 Reporter:  wolever  |Owner:
 Type:   |  petedmarsh
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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:  1|UI/UX:  0
-+-

Comment (by wolever):

 That's absolutely fair!

 I just want to make sure that the (potentially many?) use cases which
 don't involve any parameters are being considered (ex, adding an
 `array_agg` to a `groupby`, selecting a column from an intermediary many-
 to-many table, a subselect that doesn't require parameters, and I'm sure
 you can imagine a bunch more).

 Anyway, if this has been considered and parameters are the final decision,
 the one last request I would make (and PR I could provide): provide a
 default value for the `params` argument which raises an explanatory
 exception (it took me 15 minutes to figure out why `RawSQL("some_column")`
 was raising a `__init__ takes 3 arguments but 2 were provided` error).

 {{{
 def __init__(self, query, params=Undefined, …):
 if params is Undefined:
 raise TypeError(
 "params must always be provided to RawSQL to reduce the risk
 of SQL injection. "
 "Use `params=()` if your query does not require any
 parameters."
 )
 }}}

--
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.c896e2dbcd58b62a7d30abbaa4886268%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26930: makemigrations tries to access default databases even when set to empty

2016-07-22 Thread Django
#26930: makemigrations tries to access default databases even when set to empty
+
 Reporter:  lizlemon|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 makemigrations always tries to access the default database, so it raises
 an error when settings.DATABASES 'default' key is set to empty dict. This
 was fixed previously in #22576, but there has been a regression.

 The issue appears to be in
 django/core/management/commands/makemigrations.py


 {{{
 for db in connections:
 loader.check_consistent_history(connections[db])
 }}}

 in settings.py:



 {{{
 DATABASES = {
 'default': {},
 'leftside': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': os.path.join(BASE_DIR, 'db-left.sqlite3'),
 },
 'rightside': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': os.path.join(BASE_DIR, 'db-right.sqlite3'),
 }
 }

 }}}

 Then create a model in an application and define  a router for it, and
 then run {{{manage.py makemigrations}}}

 With 1.8 and other releases this will create the migrations, but current
 version raises an error:

 {{{
 Traceback (most recent call last):
   File "manage.py", line 22, in 
 execute_from_command_line(sys.argv)
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/core/management/base.py", line 305, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/core/management/base.py", line 356, in execute
 output = self.handle(*args, **options)
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/core/management/commands/makemigrations.py", line 98, in
 handle
 loader.check_consistent_history(connections[db])
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/db/migrations/loader.py", line 276, in
 check_consistent_history
 applied = recorder.applied_migrations()
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/db/migrations/recorder.py", line 65, in applied_migrations
 self.ensure_schema()
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/db/migrations/recorder.py", line 52, in ensure_schema
 if self.Migration._meta.db_table in
 self.connection.introspection.table_names(self.connection.cursor()):
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/db/backends/base/base.py", line 238, in cursor
 cursor = self.make_debug_cursor(self._cursor())
   File "/home/lemon/code/envs/dj34/lib/python3.4/site-
 packages/django/db/backends/dummy/base.py", line 21, in complain
 raise ImproperlyConfigured("settings.DATABASES is improperly
 configured. "
 django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
 improperly configured. Please supply the ENGINE value. Check settings
 documentation for more details.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/051.3ef0ceba853aa4b89ccbaf81f5243c32%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26928: Change checkbox/radio checked attribute to HTML5 boolean style

2016-07-22 Thread Django
#26928: Change checkbox/radio checked attribute to HTML5 boolean style
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 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
-+-

Comment (by timgraham):

 `required` and `disabled` were added recently so I guess backwards-
 compatibility wasn't much of a concern. Are there any backwards-
 compatibility concerns for projects not using an HTML5 doctype?

--
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.752ff54723f7653aef6d55f1a8e81f5b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26929: Deprecate `extra_context` parameter in `contrib.auth.views.logout_then_login`

2016-07-22 Thread Django
#26929: Deprecate `extra_context` parameter in
`contrib.auth.views.logout_then_login`
-+-
 Reporter:  andrewnester |Owner:
 Type:   |  andrewnester
  Cleanup/optimization   |   Status:  assigned
Component:  Uncategorized|  Version:
 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 andrewnester):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * owner:   => andrewnester
 * needs_tests:   => 0
 * needs_docs:   => 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 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/070.19312441037f22336c37688dcbaac6b6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26929: Deprecate `extra_context` parameter in `contrib.auth.views.logout_then_login`

2016-07-22 Thread Django
#26929: Deprecate `extra_context` parameter in
`contrib.auth.views.logout_then_login`
-+-
 Reporter:  andrewnester |Owner:
 Type:   |  andrewnester
  Cleanup/optimization   |   Status:  assigned
Component:  Uncategorized|  Version:
 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 andrewnester):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/070.372887245f46d99ae6c0a829e4fdc0b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26929: Deprecate `extra_context` parameter in `contrib.auth.views.logout_then_login`

2016-07-22 Thread Django
#26929: Deprecate `extra_context` parameter in
`contrib.auth.views.logout_then_login`
--+-
 Reporter:  andrewnester  |  Owner:
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Using extra context makes sense when we are rendering some template but
 with `logout_then_login` we just have HttpRedirectResponse returned with
 no context data.

--
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/055.3c7f4eeb2e953ade530e064f3736a3fe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #13936: django-admin makemessages generates PO files with an incorrect path to source code files

2016-07-22 Thread Django
#13936: django-admin makemessages generates PO files with an incorrect path to
source code files
-+-
 Reporter:  ciupicri |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.2
  commands)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by tobias):

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


Comment:

 The original case has been fixed outside Django and this hasn't been
 touched in 3 years. If this is still an issue for you, please re-open with
 current steps to reproduce.

 Another consideration is that many tools have probably, like Poedit,
 adapted to Django's existing source code path convention (along with other
 projects that use the same convention). Changing it now would be a
 backwards-incompatible change that may cause more confusion than its
 worth.

--
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.878107a46a20cb1015f4bcd445cd156f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25788: Enable the cached template loader when DEBUG=False if no loaders are explicitly configured

2016-07-22 Thread Django
#25788: Enable the cached template loader when DEBUG=False if no loaders are
explicitly configured
-+-
 Reporter:  jaap3|Owner:
 |  harrislapiroff
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Some test failures need to be fixed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.20b07ee3ffc9bbf2ec8839c41a76f10e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26685: Implement Spatialite PtDistWithin() in GeoDjango

2016-07-22 Thread Django
#26685: Implement Spatialite PtDistWithin() in GeoDjango
-+-
 Reporter:  deed02392|Owner:
 |  kevswanberg
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  spatialite dwithin   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Comments for improvement are on the 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 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.d96cf0cd868f0bd2948a1af0b3526a63%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26899: Document why RawSQL requires parameters

2016-07-22 Thread Django
#26899: Document why RawSQL requires parameters
-+-
 Reporter:  wolever  |Owner:
 Type:   |  petedmarsh
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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:  1|UI/UX:  0
-+-

Comment (by jarshwah):

 I can understand your frustration. There's certainly an inconsistency
 here, which is unfortunate, but I think I'd prefer to make the raw and
 extra params a necessary argument if I was writing them from scratch given
 the argument made earlier. It's way too easy to slip in a % (format) and
 just ignore the params argument altogether. All parameters should be
 passed via params, whether they're potentially injectable or not.

 I consider the overhead involved in adding an empty params argument a
 decent tradeoff to have a reminder of good security practises built into
 the API and not just within the docs. RawSQL will probably not be used
 very much within projects so it shouldn't lead to any/much API fatigue.

--
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.75f07ea308209ba0198fa9078141a6f3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26909: UserAttributeSimilarityValidator has hardcoded reference to 'username' causing error in password reset built-in auth form when using a custom model

2016-07-22 Thread Django
#26909: UserAttributeSimilarityValidator has hardcoded reference to 'username'
causing error in password reset built-in auth form when using a custom
model
--+
 Reporter:  kierenpitts   |Owner:  andrewnester
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 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 timgraham):

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


Comment:

 [https://github.com/django/django/pull/6962 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 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.ca04e8a5bf52d3b1d0cfbea25c22da09%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26909: UserAttributeSimilarityValidator has hardcoded reference to 'username' causing error in password reset built-in auth form when using a custom model

2016-07-22 Thread Django
#26909: UserAttributeSimilarityValidator has hardcoded reference to 'username'
causing error in password reset built-in auth form when using a custom
model
--+
 Reporter:  kierenpitts   |Owner:  andrewnester
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 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 andrewnester):

 * status:  new => assigned
 * owner:  nobody => andrewnester


--
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.56f62b9c68bb671f4084ae0c23662078%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26882: Add test(s) for django.contrib.auth.views.logout_then_login

2016-07-22 Thread Django
#26882: Add test(s) for django.contrib.auth.views.logout_then_login
-+-
 Reporter:  timgraham|Owner:
 Type:   |  andrewnester
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by andrewnester):

 * owner:  andersonresende => andrewnester


--
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.8867f5150b10fc3ca4c36efdf4a36a69%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26928: Change checkbox/radio checked attribute to HTML5 boolean style

2016-07-22 Thread Django
#26928: Change checkbox/radio checked attribute to HTML5 boolean style
--+
 Reporter:  jdufresne |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Forms |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 As Django supports HTML5 boolean attributes and they are used for
 
[https://github.com/django/django/blob/bc1e9e823b7dd3fa68dc1678edeb09e2ae1a990c/django/forms/boundfield.py#L88-L91
 existing form attributes] internally, I think the checkbox/radio `checked`
 attribute should be converted to use HTML5 boolean style as well.

--
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.ff4cde2e6f27160f2a1a805e6ed4eabd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.