Re: [Django] #25235: Document alternate syntax for class-based view decoration (was: Class based view decoration)

[Django]

#25235: Document alternate syntax for class-based view decoration
-+-
 Reporter:  zauddelig|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  1.8
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  documentation,   | Triage Stage:
  class based views, utilities,  |  Unreviewed
  decorators |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Closing as #25146 seems to address this concern as discussed on the
 mailing list.

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

Re: [Django] #25247: makemigrations unable to generate necessary migration for making a superclass abstract

[Django]

#25247: makemigrations unable to generate necessary migration for making a
superclass abstract
-+-
 Reporter:  rapilabs |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  abstract | Triage Stage:  Accepted
  makemigrations |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 I agree that generating a data migration might be risky but we could at
 least try do express a `OneToOneField(auto_created=True,
 primary_key=True)` -> `AutoField(auto_created=True, primary_key=True)`
 change as an `AlterField` operation.

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

Re: [Django] #25231: Incomplete Fix for #24628 - Squashed Migration Still Not Marked as Applied

[Django]

#25231: Incomplete Fix for #24628 - Squashed Migration Still Not Marked as 
Applied
+-
 Reporter:  mlavin  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-

Comment (by Tim Graham ):

 In [changeset:"ac46eb7e8379e451d0acc1ace666fabd56d016ce" ac46eb7]:
 {{{
 #!CommitTicketReference repository=""
 revision="ac46eb7e8379e451d0acc1ace666fabd56d016ce"
 [1.8.x] Fixed #25231 -- Added recording of squashed migrations in the
 migrate command.

 Ensured squashed migrations are recorded as applied when the
 migrate command is run and all of the original migrations
 have been previously applied.

 Backport of 69db1c745506bf63026def25d6854755179feaa8 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/064.0ae11d39330b316f61e555a0152d565d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25231: Incomplete Fix for #24628 - Squashed Migration Still Not Marked as Applied

[Django]

#25231: Incomplete Fix for #24628 - Squashed Migration Still Not Marked as 
Applied
+-
 Reporter:  mlavin  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"69db1c745506bf63026def25d6854755179feaa8" 69db1c7]:
 {{{
 #!CommitTicketReference repository=""
 revision="69db1c745506bf63026def25d6854755179feaa8"
 Fixed #25231 -- Added recording of squashed migrations in the migrate
 command.

 Ensured squashed migrations are recorded as applied when the
 migrate command is run and all of the original migrations
 have been previously applied.
 }}}

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

Re: [Django] #25249: Exception signaling in test client disconnected by nested test client call.

[Django]

#25249: Exception signaling in test client disconnected by nested test client 
call.
-+-
 Reporter:  pscottdevos  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  signals, test| Triage Stage:  Accepted
  client, got_request_exception  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|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/069.603e0a45d76ee7f0e5e282d94c750f8e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25247: makemigrations unable to generate necessary migration for making a superclass abstract

[Django]

#25247: makemigrations unable to generate necessary migration for making a
superclass abstract
-+-
 Reporter:  rapilabs |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  abstract | Triage Stage:  Accepted
  makemigrations |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I guess it's probably not feasible to allow `makemigrations` to generate a
 correct migration in cases like this (e.g. auto-generating data migration
 seems risky), but we could at least throw a more helpful error message or
 add some documentation about how to handle this case to `docs/howto
 /writing-migrations.txt`.

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

Re: [Django] #25248: Incorrect readonly_fields representation for some fields

[Django]

#25248: Incorrect readonly_fields representation for some fields
---+
 Reporter:  vmspike|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by charettes):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * version:  1.8 => master
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 It makes sense, patches welcome.

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

Re: [Django] #25250: Better Indication of Squash Migration State in showmigrations

[Django]

#25250: Better Indication of Squash Migration State in showmigrations
-+
 Reporter:  mlavin   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

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

[Django] #25250: Better Indication of Squash Migration State in showmigrations

[Django]

#25250: Better Indication of Squash Migration State in showmigrations
-+
 Reporter:  mlavin   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Migrations   |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 In the discussion of #25231 (https://github.com/django/django/pull/5112)
 it became clear that there was a disconnect between the current output of
 {{{showmigrations}}} and the actual recorded applied state of squashed
 migrations.

 Currently if all of the replaced/original migrations have been run,
 {{{showmigrations}}} will output that the related squashed migration has
 been applied with an [X] in the output even if that has not yet been
 recorded by the migration recorder. However, it is currently a requirement
 that {{{migrate}}} be run to record this applied state for the squashed
 migration before the original migrations are removed. If a deployment
 process is looking for an empty [ ] to know to run the migration then this
 may trip it up.

 This case is to consider an output for {{{showmigrations}}} which can
 indicate that this migration has only been "soft" applied, that is applied
 but not recorded yet.

 Changes to the planner for such an output may also impact #24900.

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

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

Re: [Django] #25249: Exception signaling in test client disconnected by nested test client call.

[Django]

#25249: Exception signaling in test client disconnected by nested test client 
call.
-+-
 Reporter:  pscottdevos  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  signals, test| Triage Stage:
  client, got_request_exception  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by pscottdevos):

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


Comment:

 A pull request that fixes the problem and includes a unit test is
 available at:

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

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

Re: [Django] #25223: Setting LANGUAGE_CODE to a language that doesn't exist in django/conf/locale raises IOError

[Django]

#25223: Setting LANGUAGE_CODE to a language that doesn't exist in
django/conf/locale raises IOError
-+-
 Reporter:  svleeuwen|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by beck):

 Note: the fix for #21055 added support for activating an unknown language

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

Re: [Django] #25246: Python 3 error in runserver when a directory is missing __init__.py

[Django]

#25246: Python 3 error in runserver when a directory is missing __init__.py
---+
 Reporter:  jessamynsmith  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by carljm):

 I don't know how or why a Python 3 namespace package would end up with a
 `__path__` containing the same directory multiple times (seems like a bug
 in Python, if someone is able to track down the cause), but regardless
 Django may as well be robust against it. We should just de-dupe
 `__path__`, probably by converting to a set, in
 `AppConfig._path_to_module`.

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

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

[Django] #25249: Exception signaling in test client disconnected by nested test client call.

[Django]

#25249: Exception signaling in test client disconnected by nested test client 
call.
-+-
 Reporter:   |  Owner:  nobody
  pscottdevos|
 Type:  Bug  | Status:  new
Component:  Testing  |Version:  master
  framework  |   Keywords:  signals, test client,
 Severity:  Normal   |  got_request_exception
 Triage Stage:   |  Has patch:  1
  Unreviewed |
Easy pickings:  1|  UI/UX:  0
-+-
 If the test client requests a view which itself makes a test client
 request exceptions raised after the inner request are suppressed (i.e. the
 traceback is not displayed).  This happens because, when the inner test
 client completes, it disconnects the got_request_exception signal.

 The solution is to set a unique dispatch_uid in exactly the same manner as
 it is done for the template_rendered signal.

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

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

Re: [Django] #25246: Python 3 error in runserver when a directory is missing __init__.py

[Django]

#25246: Python 3 error in runserver when a directory is missing __init__.py
---+
 Reporter:  jessamynsmith  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  1.7
 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 carljm):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (Other)
 * needs_tests:   => 0
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Old description:

> Using Python 3.4.2
> One app directory is missing a number of files, including __init__.py
> This results in an error when trying to run any manage.py command.
> It seems odd that the app directory is showing up multiple times in the
> path, and that duplication seems to cause issues for Django.
>
> Here is an example traceback:
>
> (testenv)~/Development/testenv-dev/testenv$ python manage.py runserver
> Traceback (most recent call last):
>   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
> packages/django/apps/config.py", line 100, in create
> entry = module.default_app_config
> AttributeError: 'module' object has no attribute 'default_app_config'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 385, in
> execute_from_command_line
> utility.execute()
>   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 354, in execute
> django.setup()
>   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
> packages/django/__init__.py", line 21, in setup
> apps.populate(settings.INSTALLED_APPS)
>   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
> packages/django/apps/registry.py", line 85, in populate
> app_config = AppConfig.create(entry)
>   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
> packages/django/apps/config.py", line 103, in create
> return cls(entry, module)
>   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
> packages/django/apps/config.py", line 41, in __init__
> self.path = self._path_from_module(app_module)
>   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
> packages/django/apps/config.py", line 70, in _path_from_module
> "with a 'path' class attribute." % (module, paths))
> django.core.exceptions.ImproperlyConfigured: The app module  'emptyapp' (namespace)> has multiple filesystem locations
> (['/Users/jessamyn/Development/testenv-dev/testenv/emptyapp',
> '/Users/jessamyn/Development/testenv-dev/testenv/emptyapp',
> '/Users/jessamyn/Development/testenv-dev/testenv/emptyapp']); you must
> configure this app with an AppConfig subclass with a 'path' class
> attribute.

New description:

 Using Python 3.4.2
 One app directory is missing a number of files, including __init__.py
 This results in an error when trying to run any manage.py command.
 It seems odd that the app directory is showing up multiple times in the
 path, and that duplication seems to cause issues for Django.

 Here is an example traceback:

 {{{
 (testenv)~/Development/testenv-dev/testenv$ python manage.py runserver
 Traceback (most recent call last):
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/apps/config.py", line 100, in create
 entry = module.default_app_config
 AttributeError: 'module' object has no attribute 'default_app_config'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 385, in
 execute_from_command_line
 utility.execute()
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 354, in execute
 django.setup()
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/__init__.py", line 21, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/apps/registry.py", line 85, in populate
 app_config = AppConfig.create(entry)
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/apps/config.py", 

[Django] #25246: Python 3 error in runserver when a directory is missing __init__.py

[Django]

#25246: Python 3 error in runserver when a directory is missing __init__.py
---+
 Reporter:  jessamynsmith  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Using Python 3.4.2
 One app directory is missing a number of files, including __init__.py
 This results in an error when trying to run any manage.py command.
 It seems odd that the app directory is showing up multiple times in the
 path, and that duplication seems to cause issues for Django.

 Here is an example traceback:

 (testenv)~/Development/testenv-dev/testenv$ python manage.py runserver
 Traceback (most recent call last):
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/apps/config.py", line 100, in create
 entry = module.default_app_config
 AttributeError: 'module' object has no attribute 'default_app_config'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 385, in
 execute_from_command_line
 utility.execute()
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 354, in execute
 django.setup()
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/__init__.py", line 21, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/apps/registry.py", line 85, in populate
 app_config = AppConfig.create(entry)
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/apps/config.py", line 103, in create
 return cls(entry, module)
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/apps/config.py", line 41, in __init__
 self.path = self._path_from_module(app_module)
   File "/Users/jessamyn/.virtualenvs/testenv/lib/python3.4/site-
 packages/django/apps/config.py", line 70, in _path_from_module
 "with a 'path' class attribute." % (module, paths))
 django.core.exceptions.ImproperlyConfigured: The app module  has multiple filesystem locations
 (['/Users/jessamyn/Development/testenv-dev/testenv/emptyapp',
 '/Users/jessamyn/Development/testenv-dev/testenv/emptyapp',
 '/Users/jessamyn/Development/testenv-dev/testenv/emptyapp']); you must
 configure this app with an AppConfig subclass with a 'path' class
 attribute.

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

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

[Django] #25248: Incorrect readonly_fields representation for some fields

[Django]

#25248: Incorrect readonly_fields representation for some fields
---+
 Reporter:  vmspike|  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Values of fields in readonly_fields in most cases shown as raw values.
 I suppose it's incorrect for some fields.

 I expected the following behavior:
 - CharField with 'choices' attribute should be shown as choice description
 instead of raw DB value;
 - date/time fields should be shown localized (tz, country format);
 - FileField should be shown as the link to file (if possible) (related to
 #14497 [closed, fixed], but I still see plain text with relative file
 path);
 - FilePath - the same as FileField (if possible: only if file can be
 downloaded);
 - ImageField should be shown as image or at link to image file like in
 FileField;
 - ManyToMany should be shown as list of objects __str__ instead of
 'app.model.None' string.

 Am I right or current behavior is a feature? :)

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

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

[Django] #25247: makemigrations unable to generate necessary migration for making a superclass abstract

[Django]

#25247: makemigrations unable to generate necessary migration for making a
superclass abstract
---+-
 Reporter:  rapilabs   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.8
 Severity:  Normal |   Keywords:  abstract makemigrations
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 If a user has an existing model state that uses model inheritance and
 changes a superclass to become abstract then makemigrations is unable to
 produce a suitable migration.  In fact the resulting migration will
 actually raise an exception when run.

 This is non-trivial as a generated migration may require some data
 migration operations.

 This was reported by a user on #django and I was able to reproduce with a
 small test:

 {{{#!python

 # Initial model state:

 class Foo(models.Model):
 name = models.CharField(max_length=255)


 class Bar(Foo):
 pass


 # Subsequent model state:

 class Foo(models.Model):
 name = models.CharField(max_length=255)

 class Meta:
 abstract=True


 class Bar(Foo):
 pass


 # running makemigrations results in:

 class Migration(migrations.Migration):

 dependencies = [
 ('foobar', '0001_initial'),
 ]

 operations = [
 migrations.RemoveField(
 model_name='bar',
 name='foo_ptr',
 ),
 migrations.AddField(
 model_name='bar',
 name='id',
 field=models.AutoField(auto_created=True, primary_key=True,
 default=1, serialize=False, verbose_name='ID'),
 preserve_default=False,
 ),
 migrations.AddField(
 model_name='bar',
 name='name',
 field=models.CharField(default='asdf', max_length=255),
 preserve_default=False,
 ),
 migrations.DeleteModel(
 name='Foo',
 ),
 ]


 # which results in the following when attempting to run migrate:

 (env)dsanders ~/test/abstract_update/test_abstract $ ./manage.py migrate
 Operations to perform:
   Synchronize unmigrated apps: staticfiles, messages
   Apply all migrations: admin, foobar, contenttypes, auth, sessions
 Synchronizing apps without migrations:
   Creating tables...
 Running deferred SQL...
   Installing custom SQL...
 Running migrations:
   Rendering model states...Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 338, in
 execute_from_command_line
 utility.execute()
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 330, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/core/management/base.py", line 393, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/core/management/base.py", line 444, in execute
 output = self.handle(*args, **options)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 221, in handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 104, in migrate
 state = migration.mutate_state(state, preserve=do_run)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/db/migrations/migration.py", line 83, in mutate_state
 operation.state_forwards(self.app_label, new_state)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/db/migrations/operations/fields.py", line 51, in
 state_forwards
 state.reload_model(app_label, self.model_name_lower)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/db/migrations/state.py", line 152, in reload_model
 self.apps.render_multiple(states_to_be_rendered)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/db/migrations/state.py", line 262, in render_multiple
 model.render(self)
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/db/migrations/state.py", line 546, in render
 body,
   File "/Users/dsanders/test/abstract_update/env/lib/python2.7/site-
 packages/django/db/models/base.py", line 254, in __new__
 'base class %r' % (field.name, name, base.__name__)
 django.core.exceptions.FieldError: Local field u'id' in class 'Bar'
 cl

Re: [Django] #6489: Add selected and enabled_from for JS calendar

[Django]

#6489: Add selected and enabled_from for JS calendar
-+-
 Reporter:  Bastian Kleineidam   |Owner:  nobody
   |
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I see. Maybe `disableDatesBefore` would be a better name? How is it used
 from Django though? It seems like you need a custom `calendar.js` file to
 pass the value for that field.

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

Re: [Django] #25223: Setting LANGUAGE_CODE to a language that doesn't exist in django/conf/locale raises IOError

[Django]

#25223: Setting LANGUAGE_CODE to a language that doesn't exist in
django/conf/locale raises IOError
-+-
 Reporter:  svleeuwen|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by beck):

 Indeed.  This is by design.

 The reason is to catch broken django installs.  If trying to activate a
 supported language and the django translations are missing/unreadable
 (referencing  #18192), the framework needs to blowup and make the user
 aware of the issue.

 When trying to set the default language to one not supported by django,
 this action has the same side-effects as activating a common language with
 a broken install.

 IMO catching a broken install is more critical and a more common use-case
 than setting the default language to one (not yet) supported.

 However, django will let you use and activate a custom language (just not
 make it the default).

 To exemplify:

 1. Add a translation catalog for the custom language.
   Add file `projectdir/locale/sd/LC_MESSAGES/django.po`:
   {{{
   msgid ""
   msgstr ""
   "Content-Type: text/plain; charset=UTF-8\n"

   msgid "butterfly"
   msgstr "پوپَٽُ"
   }}}

 2. In settings.py add the locale and use a default language found in
 [https://github.com/django/django/tree/master/django/conf/locale
 django/conf]:
   {{{
   LANGUAGE_CODE = 'en'
   LOCALE_PATHS = [os.path.join(BASE_DIR, 'locale')]
   }}}

 3. Compile messages:
   {{{
   $ python manage.py compilemessages
   processing file django.po in
 /Users/doug/Desktop/project/locale/sd/LC_MESSAGES
   }}}

 4. Test the translation.
   Create `test.py`:
   {{{
   from django.utils.translation import activate, ugettext
   activate('sd-pk')
   print ugettext('butterfly')
   }}}
   Run `test.py` through django shell:
   {{{
   $ python manage.py shell < test.py
   (InteractiveConsole)
   >>> پوپَٽُ
   }}}

 As for this ticket, since all is working by design I do not believe it to
 be a bug.

 This ticket could be reworded as a feature request:

 Allow default language to be one unsupported by django if the local
 project has the required translation catalog

 Or open a new pull on django adding Sindhi :)

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

Re: [Django] #6489: Add selected and enabled_from for JS calendar

[Django]

#6489: Add selected and enabled_from for JS calendar
-+-
 Reporter:  Bastian Kleineidam   |Owner:  nobody
   |
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by giuliettamasina):

 It is about disabling all dates before the current date in the calendar,
 so that you can only select today or later.

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

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

Re: [Django] #25180: ArrayFields should not have varchar_patterns_ops or text_patterns_ops indexes

[Django]

#25180: ArrayFields should not have varchar_patterns_ops or text_patterns_ops
indexes
--+--
 Reporter:  fabianbuechler|Owner:  caioariede
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by caioariede):

 Seems to happen only when the table is created. Adding the field later
 does not trigger the error.

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

Re: [Django] #25233: Unable save model in admin with HStoreField field after manually saving invalid data

[Django]

#25233: Unable save model in admin with HStoreField field after manually saving
invalid data
-+-
 Reporter:  hongphi  |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"ad2ac53054f1deea6818d05220db73f6c09c1702" ad2ac53]:
 {{{
 #!CommitTicketReference repository=""
 revision="ad2ac53054f1deea6818d05220db73f6c09c1702"
 [1.8.x] Fixed #25233 -- Fixed HStoreField.has_changed() handling of
 initial values.

 Thanks Simon Charette for review.

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

Re: [Django] #25233: Unable save model in admin with HStoreField field after manually saving invalid data

[Django]

#25233: Unable save model in admin with HStoreField field after manually saving
invalid data
-+-
 Reporter:  hongphi  |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.8
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"a7b7f27c05244d69a11545261eb3bbd73791b3d2" a7b7f27c]:
 {{{
 #!CommitTicketReference repository=""
 revision="a7b7f27c05244d69a11545261eb3bbd73791b3d2"
 Fixed #25233 -- Fixed HStoreField.has_changed() handling of initial
 values.

 Thanks Simon Charette for review.
 }}}

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

Re: [Django] #25233: Unable save model in admin with HStoreField field after manually saving invalid data

[Django]

#25233: Unable save model in admin with HStoreField field after manually saving
invalid data
-+-
 Reporter:  hongphi  |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  1.8
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #25233: Unable save model in admin with HStoreField field after manually saving invalid data

[Django]

#25233: Unable save model in admin with HStoreField field after manually saving
invalid data
--+-
 Reporter:  hongphi   |Owner:  timgraham
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #25233: Unable save model in admin with HStoreField field after manually saving invalid data

[Django]

#25233: Unable save model in admin with HStoreField field after manually saving
invalid data
--+-
 Reporter:  hongphi   |Owner:  timgraham
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.8
 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):

 * owner:   => timgraham
 * status:  new => assigned
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #25163: Add a hint to the admin login page when a user is redirected there due to lack of permissions

[Django]

#25163: Add a hint to the admin login page when a user is redirected there due 
to
lack of permissions
-+-
 Reporter:  adelton  |Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  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 Claude Paroz ):

 In [changeset:"6ed613b2a52f8719b92b94d815e9f997d262412c" 6ed613b2]:
 {{{
 #!CommitTicketReference repository=""
 revision="6ed613b2a52f8719b92b94d815e9f997d262412c"
 Refs #25163 -- Added trimmed option to recent blocktrans addition
 }}}

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

Re: [Django] #25233: Unable save model in admin with HStoreField field after manually saving invalid data

[Django]

#25233: Unable save model in admin with HStoreField field after manually saving
invalid data
--+--
 Reporter:  hongphi   |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.8
 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 mcastle):

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


Comment:

 I see this same error in the Admin even when entering valid data with
 double quotes, using Django 1.8.3 and Python 2.7.10:
 {{{
 patient = Patient.objects.create(user=user, gender="male",
 mobile_telecom="555-555-4456",
 emergency_contacts={"urgent_care":"555-555-"}, utc_offset=0,
 birthdate=datetime.datetime.now())
 }}}

 Returning emergency_contacts from the shell results in single quoted data:
 {{{
 In [21]: patient.emergency_contacts
 Out[21]: {'urgent_care': '6467702435'}
 }}}

 From the traceback, it seems django's changed_data in forms.py is
 transforming the double-quoted data to single-quoted data:

 {{{
 /lib/python2.7/site-packages/django/forms/forms.py in changed_data

 try:

 initial_value =
 field.to_python(hidden_widget.value_from_datadict(

 self.data, self.files,
 initial_prefixed_name))

 except ValidationError:

 # Always assume data has changed if validation
 fails.

 self._changed_data.append(name)

 continue

 if field.has_changed(initial_value,
 data_value):

  ...

 self._changed_data.append(name)

 return self._changed_data

 @property

 def media(self):

 """

 ▼ Local vars
 VariableValue
 data_value

 u'{"urgent_care": "555-555-"}'

 name

 'emergency_contacts'

 initial_value

 {u'urgent_care': u'555-555-'}

 self

 

 field

 

 prefixed_name

 'emergency_contacts'
 }}}


 This is using the following model:

 {{{
 class Patient(TimeStampedModel):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 user = models.OneToOneField(settings.AUTH_USER_MODEL)
 gender = models.CharField(max_length=10, choices=GENDER_CHOICES)
 birthdate = models.DateField()
 mobile_telecom = PhoneNumberField(unique=True)
 emergency_contacts = HStoreField(default={"urgent_care": ""})
 utc_offset = models.IntegerField(default=0)
 hipaa_authorization_timestamp = models.DateTimeField(null=True,
 blank=True)
 }}}

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

[Django] #25245: Incorrect query arising from using NOT-clauses & multiple relation references affected node position in Q

[Django]

#25245: Incorrect query arising from using NOT-clauses & multiple relation
references affected node position in Q
-+-
 Reporter:  ris  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.8
  (models, ORM)  |   Keywords:  exclude exclude
 Severity:  Normal   |  manytomany Q order
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 This may (or may not) be related to the bug being fixed in PR4385
 (https://github.com/django/django/pull/4385) and/or #14645, however even
 if it is I think this displays an interesting facet to this.

 The order Q clauses are specified in the Q expression will affect the
 (in)correctness of the generated query.

 Using django 1.8.3 example models.py:

 {{{
 from django.db import models

 class ModelA ( models.Model ):
 pass

 class ModelB ( models.Model ):
 a = models.ForeignKey ( ModelA )

 field_f = models.IntegerField ()
 field_g = models.IntegerField ()
 }}}

 Specify the query one way around:

 {{{
 >>> x = ModelA.objects.filter ( ( Q ( modelb__field_f = 3 ) & Q (
 modelb__field_g__gte = 50 ) ) | ~Q ( modelb__field_f = 3 ) ).distinct ()
 >>> str ( x.query )
 'SELECT DISTINCT "dummy_modela"."id" FROM "dummy_modela" LEFT OUTER JOIN
 "dummy_modelb" ON ( "dummy_modela"."id" = "dummy_modelb"."a_id" ) WHERE
 (("dummy_modelb"."field_f" = 3 AND "dummy_modelb"."field_g" >= 50) OR NOT
 ("dummy_modela"."id" IN (SELECT U1."a_id" AS Col1 FROM "dummy_modelb" U1
 WHERE (U1."field_f" = 3 AND U1."id" = ("dummy_modelb"."id")'
 }}}

 Generates one piece of SQL. Specify it in a different order:

 {{{
 >>> y = ModelA.objects.filter ( (~Q ( modelb__field_f = 3 )) | ( Q (
 modelb__field_f = 3 ) & Q ( modelb__field_g__gte = 50 ) ) ).distinct ()
 >>> str ( y.query )
 'SELECT DISTINCT "dummy_modela"."id" FROM "dummy_modela" LEFT OUTER JOIN
 "dummy_modelb" ON ( "dummy_modela"."id" = "dummy_modelb"."a_id" ) WHERE
 (NOT ("dummy_modela"."id" IN (SELECT U1."a_id" AS Col1 FROM "dummy_modelb"
 U1 WHERE U1."field_f" = 3)) OR ("dummy_modelb"."field_f" = 3 AND
 "dummy_modelb"."field_g" >= 50))'
 }}}

 Generates quite different SQL, which returns different results.

 Would like to be sure PR4385 fixes this case.

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

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

Re: [Django] #25244: Not working query_set.query.group_by = [..] in v1.8

[Django]

#25244: Not working query_set.query.group_by = [..] in v1.8
-+-
 Reporter:  Elec |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Since `QuerySet.query.group_by` is not a public API and therefore not
 covered by the stability policy, this isn't a bug.

 Try asking for help on the django-users mailing list or the #django IRC
 channel instead.

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

Re: [Django] #25175: Create an alias for the postgresql_psycopg2 database backend

[Django]

#25175: Create an alias for the postgresql_psycopg2 database backend
-+-
 Reporter:  bmispelon|Owner:
 Type:   |  caioariede
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"bcb4fe0012f8f869348ea83f5a35706f4545c44a" bcb4fe00]:
 {{{
 #!CommitTicketReference repository=""
 revision="bcb4fe0012f8f869348ea83f5a35706f4545c44a"
 Refs #25175 -- Added backwards compatibility for importing
 postgresql_psycopg2 backend.
 }}}

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

Re: [Django] #25175: Create an alias for the postgresql_psycopg2 database backend

[Django]

#25175: Create an alias for the postgresql_psycopg2 database backend
-+-
 Reporter:  bmispelon|Owner:
 Type:   |  caioariede
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"ec9004728ee136e3b7e2b7cd2610203e16b6ce9b" ec900472]:
 {{{
 #!CommitTicketReference repository=""
 revision="ec9004728ee136e3b7e2b7cd2610203e16b6ce9b"
 Fixed #25175 -- Renamed the postgresql_psycopg2 database backend to
 postgresql.
 }}}

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

Re: [Django] #25241: ModelForm.save() gives wrong message when saving invalid form with UUIDField pk

[Django]

#25241: ModelForm.save() gives wrong message when saving invalid form with
UUIDField pk
---+-
 Reporter:  timgraham  |Owner:  timgraham
 Type:  Bug|   Status:  closed
Component:  Forms  |  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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"f2b665f88610b208196b5753b09b4a5cfb322417" f2b665f8]:
 {{{
 #!CommitTicketReference repository=""
 revision="f2b665f88610b208196b5753b09b4a5cfb322417"
 Fixed #25241 -- Corrected ModelForm.save() error message when saving
 invalid form with UUIDField pk.
 }}}

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

Re: [Django] #24629: Allow Func Expressions to be used as Transforms

[Django]

#24629: Allow Func Expressions to be used as Transforms
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

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


Comment:

 https://github.com/django/django/pull/5090 is the newest PR to tackle this
 patch. It still needs some tidying up, docs, and maybe some tests. But I'm
 happier with the approach used here than the previous couple we've thrown
 together.

 There's no bridge/compat layer here. Instead, Transforms are now handled
 independently from Lookups, allowing Transform to be removed and replaced
 with Func. A nice side effect of converting Transforms to expressions is
 that the RHS of lookups can now be an expression, paving the way for an
 object based filtering pattern similar to:

 {{{
 Model.objects.filter(StartsWith(F('field'), Lower(Value('my_value')))
 }}}

 This trivial example isn't as nice as the traditional string based
 filtering, but it's easy to imagine situations where you're passing around
 objects that can be used as annotations or filters, and just dumping them
 straight in unaltered.

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

Re: [Django] #24754: Implementation of global permissions

[Django]

#24754: Implementation of global permissions
--+
 Reporter:  autrilla  |Owner:  nobody
 Type:  New feature   |   Status:  new
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:  0 |UI/UX:  0
--+
Changes (by adamchainz):

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

Re: [Django] #25243: inspectdb crashes if SQLite foreign key references sqlite_master

[Django]

#25243: inspectdb crashes if SQLite foreign key references sqlite_master
-+-
 Reporter:  ssokolow |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.8
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
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/066.9a2fbb807aef7efe961628b79a7b906d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25198: Django's model_to_dict should return ALL fields, including hidden

[Django]

#25198: Django's model_to_dict should return ALL fields, including hidden
-+-
 Reporter:  1st  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core |  Version:  master
  (Serialization)|
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  model serialization  | 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:   => needsinfo


Comment:

 Closing, pending a discussion on the mailing list.

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

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

Re: [Django] #25164: The django.contrib.auth.views.login does not observe authentication via RemoteUserMiddleware

[Django]

#25164: The django.contrib.auth.views.login does not observe authentication via
RemoteUserMiddleware
--+--
 Reporter:  adelton   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by timgraham):

 About "be more explicit that the user is already authentication and that
 re-authentication will happen" -- it seems like could be done in the
 project's login template (Django doesn't ship one, except for the admin,
 but it doesn't seem relevant there since it doesn't allow viewing the
 login page for logged in users).

 About "I'd really assume that the expected behaviour is to just accept
 that external authentication and skip the logon page" -- as noted before,
 adding this behavior would be backwards incompatible and seems better left
 to a custom login view.

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

Re: [Django] #25242: Admin not redirecting to login for custom AdminSite

[Django]

#25242: Admin not redirecting to login for custom AdminSite
-+--
 Reporter:  shadow   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by shadow):

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


Comment:

 Sorry, just realised this was my fault.

 I forgot that I had previously extended the admin's index view, but forgot
 to wrap the original view in admin_view() when calling it.

 I guess I was logged-in the whole time and never noticed...

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

Re: [Django] #20605: Allow extending the default auth permissions

[Django]

#20605: Allow extending the default auth permissions
--+
 Reporter:  philipn   |Owner:  nobody
 Type:  New feature   |   Status:  new
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:  0 |UI/UX:  0
--+
Changes (by adamchainz):

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

Re: [Django] #25242: Admin not redirecting to login for custom AdminSite

[Django]

#25242: Admin not redirecting to login for custom AdminSite
-+--
 Reporter:  shadow   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   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
 * easy:  1 => 0
 * needs_docs:   => 0


Comment:

 Can you show your custom admin site class?

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

[Django] #25244: Not working query_set.query.group_by = [..] in v1.8

[Django]

#25244: Not working query_set.query.group_by = [..] in v1.8
--+
 Reporter:  Elec  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I am upgrade from Django v 1.6 to v1.8. I use this code:

 {{{
 query_set =
 Rubrica.objects.filter(...).annotate(count=Count('..')).order_by('user',
 '-pub_date')
 query_set.query.group_by = ['user_id']
 }}}

 On Django version 1.6 this is works fine, but on version 1.8 results is
 not grouped by `user_id` field.
 How can I solve this 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/047.f95cca3792f9a098fe07560b7cb41bee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20597: Replace admin icons images by inline SVG

[Django]

#20597: Replace admin icons images by inline SVG
-+-
 Reporter:  loic84   |Owner:  anonymous
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by mjtamlyn):

 This isn't a clear cut argument either way at the moment. Icon fonts are
 simpler to use in many cases, they can easily be coloured etc. Inline SVG
 I agree is not worth the extra work most of the time - unless you are
 wanting to change the SVG content a background is much easier and can be
 achieved with similar CSS.

 SVG definitely wins on accessibility, which is something we need to
 consider, but I'm also happy with "working code".

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

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

Re: [Django] #24777: Add support for statement_timeout

[Django]

#24777: Add support for statement_timeout
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 ris):

 Keep in mind not everybody has admin access to their postgres installation
 (shared hosting?).

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

Re: [Django] #24201: order_with_respect_to GenericForeignKey

[Django]

#24201: order_with_respect_to GenericForeignKey
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by AlexHill):

 * needs_better_patch:  1 => 0


Comment:

 I've rebased and deduplicated that logic so it's shared by order with
 respect to and the descriptors.

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

Re: [Django] #25230: Change to Query.get_count() causes big performance hit

[Django]

#25230: Change to Query.get_count() causes big performance hit
-+-
 Reporter:  dexity   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I'm not against fixing this. We could in general remove distinct from
 queries when we can prove it is redundant.

 But, I don't think this is that high priority issue. I probably will get
 to fixing this at some point, and I'm definitely willing to review
 patches.

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

Re: [Django] #25064: Join.as_sql() emits invalid SQL if get_joining_columns() returns an empty tuple

[Django]

#25064: Join.as_sql() emits invalid SQL if get_joining_columns() returns an 
empty
tuple
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by AlexHill):

 * needs_better_patch:  1 => 0


Comment:

 I've updated the example used in the tests which should hopefully clarify
 things a bit, and made the recommended style edits.

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

Re: [Django] #25243: inspectdb crashes if SQLite foreign key references sqlite_master

[Django]

#25243: inspectdb crashes if SQLite foreign key references sqlite_master
-+-
 Reporter:  ssokolow |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.8
  commands)  |
 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 ssokolow):

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


Comment:

 Oh, please note that I'll have to manually check this for updates as this
 Trac installation requires some kind of authentication to access RSS
 feeds.

 (After many bad experiences with leaks to spammers, I've learned to not
 trust Trac installations with my e-mail aliases.)

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

[Django] #25243: inspectdb crashes if SQLite foreign key references sqlite_master

[Django]

#25243: inspectdb crashes if SQLite foreign key references sqlite_master
+
 Reporter:  ssokolow|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.8
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 While trying to import an SQLite database from an old legacy codebase, I
 ran up against the following exception in Django 1.8.3:

 {{{
 #!sh
 ssokolow@monolith XXX [django] % python manage.py inspectdb >|
 models.py
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/ssokolow/.virtualenvs/XXX/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 338, in
 execute_from_command_line
 utility.execute()
   File "/home/ssokolow/.virtualenvs/XXX/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 330, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/ssokolow/.virtualenvs/XXX/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 393, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/ssokolow/.virtualenvs/XXX/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 444, in execute
 output = self.handle(*args, **options)
   File "/home/ssokolow/.virtualenvs/XXX/local/lib/python2.7/site-
 packages/django/core/management/commands/inspectdb.py", line 25, in handle
 for line in self.handle_inspection(options):
   File "/home/ssokolow/.virtualenvs/XXX/local/lib/python2.7/site-
 packages/django/core/management/commands/inspectdb.py", line 64, in
 handle_inspection
 relations = connection.introspection.get_relations(cursor, table_name)
   File "/home/ssokolow/.virtualenvs/XXX/local/lib/python2.7/site-
 packages/django/db/backends/sqlite3/introspection.py", line 128, in
 get_relations
 result = cursor.fetchall()[0]
 IndexError: list index out of range
 }}}

 Examining the output revealed that it was dying in a table named "todos"
 and, examing that further, I discovered that inspectdb did '''not''' like
 what the code was doing to partially enforce a home-built generic foreign
 key constraint.

 Here's the schema which caused it to fail:
 {{{
 #!sql
 CREATE TABLE todos (
 id INTEGER PRIMARY KEY,
 row_id INTEGER,
 table_name VARCHAR(64) DEFAULT 'stories' REFERENCES sqlite_master
 (tbl_name) ON DELETE RESTRICT ON UPDATE CASCADE COLLATE NOCASE,
 content TEXT NOT NULL CHECK(TRIM(content) <> '' AND TRIM(content) =
 content AND content NOT LIKE '%  %' AND content NOT GLOB '*[

 ]*')
 );
 }}}

 I had to manually dump the database to SQL, edit out this clause in vim
 (because SQLite's ALTER TABLE is so limited), and then re-create the
 database before inspectdb would successfully complete:
 {{{
 #!sql
 REFERENCES sqlite_master (tbl_name) ON DELETE RESTRICT ON UPDATE CASCADE
 }}}

 At the very least, it should probably have a clearer error message.

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