date:20150111

Re: [Django] #15602: Using get_readonly_fields and StackedInline/TabularInline admin objects doesn't allow creating new objects, immutible existing objects

2015-01-11 Thread Django

#15602: Using get_readonly_fields and StackedInline/TabularInline admin objects
doesn't allow creating new objects, immutible existing objects
-+
 Reporter:  bradwhittington  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 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 zachborboa):

 * cc: zachborboa (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/073.2a62777e94fe2a90076a7dfa68f8a7d4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24089: Misleading error raised during system check related to ModelAdmin

2015-01-11 Thread Django

#24089: Misleading error raised during system check related to ModelAdmin
-+-
 Reporter:  okrutny  |Owner:
 Type:   |  arcturusannamalai
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by arcturusannamalai):

 * status:  assigned => closed
 * needs_better_patch:  1 => 0
 * resolution:   => fixed
 * 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.9cd5e6a5fc2921b7ca588c11883172ef%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24133: DeleteView success_url = reverse_lazy(...) bug for non ascii urls

2015-01-11 Thread Django

#24133: DeleteView success_url = reverse_lazy(...) bug for non ascii urls
-+-
 Reporter:  laurentpayot |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.7
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  DeleteView   | Triage Stage:
  reverse_lazy   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by laurentpayot:

Old description:

> When using `DeleteView` mixin `with success_url = reverse_lazy('www
> :media-list')` for a non-ASCII "delete URL" (e.g. //
> /fr/m**é**dias/2139079220/Jules-Verne-cinq-semaines-en-
> ballon/suppression/ //) I get the following error :
>
> {{{
> Internal Server Error: /fr/médias/2139079220/Jules-Verne-cinq-semaines-
> en-ballon/suppression/
> Traceback (most recent call last):
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/core/handlers/base.py", line 111, in get_response
> response = wrapped_callback(request, *callback_args,
> **callback_kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/base.py", line 69, in view
> return self.dispatch(request, *args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/utils/decorators.py", line 29, in _wrapper
> return bound_func(*args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/contrib/auth/decorators.py", line 22, in _wrapped_view
> return view_func(request, *args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/utils/decorators.py", line 25, in bound_func
> return func.__get__(self, type(self))(*args2, **kwargs2)
>   File "/opt/VENV/publiberty/publiberty/django/www/views.py", line 485,
> in dispatch
> return super().dispatch(*args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/base.py", line 87, in dispatch
> return handler(request, *args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/edit.py", line 259, in post
> return self.delete(request, *args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/edit.py", line 253, in delete
> success_url = self.get_success_url()
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/edit.py", line 263, in get_success_url
> return self.success_url % self.object.__dict__
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/utils/functional.py", line 179, in __mod__
> return six.text_type(self) % rhs
> ValueError: unsupported format character 'C' (0x43) at index 6
> }}}
>
> For "normal" ASCII urls everything works fine.
> Following workaround is working:
> {{{
> #!python
> def get_success_url(self):
> return reverse('www:media-list')
> }}}
>
> Could it be linked to the "accidental" fix of ticket [ticket:22693] ? I'm
> using Python 3.4.2 with Ubuntu 14.10.

New description:

 When using `DeleteView` mixin with `success_url = reverse_lazy('www:media-
 list')` for a non-ASCII "delete URL" (e.g. // /fr/m**é**dias/2139079220
 /Jules-Verne-cinq-semaines-en-ballon/suppression/ //) I get the following
 error :

 {{{
 Internal Server Error: /fr/médias/2139079220/Jules-Verne-cinq-semaines-en-
 ballon/suppression/
 Traceback (most recent call last):
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/core/handlers/base.py", line 111, in get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/base.py", line 69, in view
 return self.dispatch(request, *args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/utils/decorators.py", line 29, in _wrapper
 return bound_func(*args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/contrib/auth/decorators.py", line 22, in _wrapped_view
 return view_func(request, *args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/utils/decorators.py", line 25, in bound_func
 return func.__get__(self, type(self))(*args2, **kwargs2)
   File "/opt/VENV/publiberty/publiberty/django/www/views.py", line 485, in
 dispatch
 return super().dispatch(*args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/base.py", line 87, in dispatch
 return handler(request, *args,

Re: [Django] #24133: DeleteView success_url = reverse_lazy(...) bug for non ascii urls

2015-01-11 Thread Django

#24133: DeleteView success_url = reverse_lazy(...) bug for non ascii urls
-+-
 Reporter:  laurentpayot |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.7
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  DeleteView   | Triage Stage:
  reverse_lazy   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by laurentpayot):

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


Old description:

> When using `DeleteView` mixin `with success_url = reverse_lazy('www
> :media-list')` for a non-ASCII "delete URL" (e.g. //
> /fr/m**é**dias/2139079220/Jules-Verne-cinq-semaines-en-
> ballon/suppression/ //) I get the following error :
>
> {{{
> Internal Server Error: /fr/médias/2139079220/Jules-Verne-cinq-semaines-
> en-ballon/suppression/
> Traceback (most recent call last):
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/core/handlers/base.py", line 111, in get_response
> response = wrapped_callback(request, *callback_args,
> **callback_kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/base.py", line 69, in view
> return self.dispatch(request, *args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/utils/decorators.py", line 29, in _wrapper
> return bound_func(*args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/contrib/auth/decorators.py", line 22, in _wrapped_view
> return view_func(request, *args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/utils/decorators.py", line 25, in bound_func
> return func.__get__(self, type(self))(*args2, **kwargs2)
>   File "/opt/VENV/publiberty/publiberty/django/www/views.py", line 485,
> in dispatch
> return super().dispatch(*args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/base.py", line 87, in dispatch
> return handler(request, *args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/edit.py", line 259, in post
> return self.delete(request, *args, **kwargs)
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/edit.py", line 253, in delete
> success_url = self.get_success_url()
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/views/generic/edit.py", line 263, in get_success_url
> return self.success_url % self.object.__dict__
>   File "/opt/VENV/publiberty/lib/python3.4/site-
> packages/django/utils/functional.py", line 179, in __mod__
> return six.text_type(self) % rhs
> ValueError: unsupported format character 'C' (0x43) at index 6
> }}}
>
> For "normal" ascii url no problem at all.
> Following workaround is working:
> {{{
> #!python
> def get_success_url(self):
> return reverse('www:media-list')
> }}}
>
> Could it be linked to the "accidental" fix of ticket [ticket:22693] ? I'm
> using Python 3.4.2 with Ubuntu 14.10.

New description:

 When using `DeleteView` mixin `with success_url = reverse_lazy('www:media-
 list')` for a non-ASCII "delete URL" (e.g. // /fr/m**é**dias/2139079220
 /Jules-Verne-cinq-semaines-en-ballon/suppression/ //) I get the following
 error :

 {{{
 Internal Server Error: /fr/médias/2139079220/Jules-Verne-cinq-semaines-en-
 ballon/suppression/
 Traceback (most recent call last):
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/core/handlers/base.py", line 111, in get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/base.py", line 69, in view
 return self.dispatch(request, *args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/utils/decorators.py", line 29, in _wrapper
 return bound_func(*args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/contrib/auth/decorators.py", line 22, in _wrapped_view
 return view_func(request, *args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/utils/decorators.py", line 25, in bound_func
 return func.__get__(self, type(self))(*args2, **kwargs2)
   File "/opt/VENV/publiberty/publiberty/django/www/views.py", line 485, in
 dispatch
 return super().dispatch(*args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/base.

[Django] #24133: DeleteView success_url = reverse_lazy(...) bug for non ascii urls

2015-01-11 Thread Django

#24133: DeleteView success_url = reverse_lazy(...) bug for non ascii urls
--+
 Reporter:  laurentpayot  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Internationalization  |Version:  1.7
 Severity:  Normal|   Keywords:  DeleteView
  |  reverse_lazy
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 When using `DeleteView` mixin `with success_url = reverse_lazy('www:media-
 list')` for a non-ASCII "delete URL" (e.g. // /fr/m**é**dias/2139079220
 /Jules-Verne-cinq-semaines-en-ballon/suppression/ //) I get the following
 error :

 {{{
 Internal Server Error: /fr/médias/2139079220/Jules-Verne-cinq-semaines-en-
 ballon/suppression/
 Traceback (most recent call last):
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/core/handlers/base.py", line 111, in get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/base.py", line 69, in view
 return self.dispatch(request, *args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/utils/decorators.py", line 29, in _wrapper
 return bound_func(*args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/contrib/auth/decorators.py", line 22, in _wrapped_view
 return view_func(request, *args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/utils/decorators.py", line 25, in bound_func
 return func.__get__(self, type(self))(*args2, **kwargs2)
   File "/opt/VENV/publiberty/publiberty/django/www/views.py", line 485, in
 dispatch
 return super().dispatch(*args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/base.py", line 87, in dispatch
 return handler(request, *args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/edit.py", line 259, in post
 return self.delete(request, *args, **kwargs)
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/edit.py", line 253, in delete
 success_url = self.get_success_url()
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/views/generic/edit.py", line 263, in get_success_url
 return self.success_url % self.object.__dict__
   File "/opt/VENV/publiberty/lib/python3.4/site-
 packages/django/utils/functional.py", line 179, in __mod__
 return six.text_type(self) % rhs
 ValueError: unsupported format character 'C' (0x43) at index 6
 }}}

 For "normal" ascii url no problem at all.
 Following workaround is working:
 {{{
 #!python
 def get_success_url(self):
 return reverse('www:media-list')
 }}}

 Could it be linked to the "accidental" fix of ticket [ticket:22693] ? I'm
 using Python 3.4.2 with Ubuntu 14.10.

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

Re: [Django] #24075: Can't migrate contenttypes and auth to zero

2015-01-11 Thread Django

#24075: Can't migrate contenttypes and auth to zero
-+
 Reporter:  apollo13 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by MarkusH):

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


Comment:

 I created an initial PR that tackles the problem until #24100 is fixed.

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

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

Re: [Django] #24100: Make `post_migrate` dispatch the migration plan.

2015-01-11 Thread Django

#24100: Make `post_migrate` dispatch the migration plan.
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 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 MarkusH):

 * cc: info+coding@… (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * needs_docs:  0 => 1


Comment:

 As already mentioned on the PR, I'm not sure the current API is stable
 enough (in terms of "Django doesn't crash", not in terms of "We change a
 function signature") for public usage. I'd like to have the alpha and beta
 for tests. Tim noted on IRC that changing the API after beta isn't really
 a thing we should do which I do understand.

 A workaround we could also simply backport to 1.7 (and add `plan` and
 `state` in 1.9), is a check for the respective first migrations being
 applied:

 In `django.contrib.contenttypes.management`:

 {{{#!python
 def update_contenttypes(...):
 from django.db.migration.loader import MigrationLoader
 loader = MigrationLoader(connection)
 loader.load_disk()
 if not ('contenttypes', '0001_initial') in loader.applied_migrations:
 return
 }}}

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

Re: [Django] #24132: auth_permission name field is too short

2015-01-11 Thread Django

#24132: auth_permission name field is too short
---+--
 Reporter:  mark0978   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.auth   |  Version:  1.7
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by MarkusH):

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


Comment:

 Duplicate of #8162. Fixed in 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/066.56e0b76b6372856b4db2a7e255884701%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24118: Add --debug-sql option to tests to print SQL queries on failure

2015-01-11 Thread Django

#24118: Add --debug-sql option to tests to print SQL queries on failure
-+-
 Reporter:  mjtamlyn |Owner:  mjtamlyn
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #24132: auth_permission name field is too short

2015-01-11 Thread Django

#24132: auth_permission name field is too short
---+--
 Reporter:  mark0978   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by mark0978):

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


Old description:

> CREATE TABLE `auth_permission` (
>   `id` int(11) NOT NULL AUTO_INCREMENT,
>   `name` varchar(50) NOT NULL,
>   `content_type_id` int(11) NOT NULL,
>   `codename` varchar(100) NOT NULL,
> )
>
> codename and name are almost identical fields, except name has added
> spaces and the string "Can" stuck in front of it.  Why then is the
> codename field varchar(100) and the name field varchar(50).
>
> Right now this is causing me grief because one of the model names is long
> enough to make the name field more than 50 characters.
>
> Now that migrations are part of the core of Django, this should be easy
> to fix.

New description:

 {{{
 CREATE TABLE `auth_permission` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `name` varchar(50) NOT NULL,
   `content_type_id` int(11) NOT NULL,
   `codename` varchar(100) NOT NULL,
 )
 }}}


 codename and name are almost identical fields, except name has added
 spaces and the string "Can" stuck in front of it.  Why then is the
 codename field varchar(100) and the name field varchar(50).

 Right now this is causing me grief because one of the model names is long
 enough to make the name field more than 50 characters.

 Now that migrations are part of the core of Django, this should be easy to
 fix.

--

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

[Django] #24132: auth_permission name field is too short

2015-01-11 Thread Django

#24132: auth_permission name field is too short
---+
 Reporter:  mark0978   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.auth   |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 CREATE TABLE `auth_permission` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `name` varchar(50) NOT NULL,
   `content_type_id` int(11) NOT NULL,
   `codename` varchar(100) NOT NULL,
 )

 codename and name are almost identical fields, except name has added
 spaces and the string "Can" stuck in front of it.  Why then is the
 codename field varchar(100) and the name field varchar(50).

 Right now this is causing me grief because one of the model names is long
 enough to make the name field more than 50 characters.

 Now that migrations are part of the core of Django, this should be easy to
 fix.

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

Re: [Django] #20377: BinaryField doesn't work on MySQL and Python 3

2015-01-11 Thread Django

#20377: BinaryField doesn't work on MySQL and Python 3
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => closed
 * resolution:   => 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/067.374f1091d0a2e69e31d6ae30766ba6df%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20377: BinaryField doesn't work on MySQL and Python 3

2015-01-11 Thread Django

#20377: BinaryField doesn't work on MySQL and Python 3
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"68a439a18da17a6832eff0a7c2090655b583"]:
 {{{
 #!CommitTicketReference repository=""
 revision="68a439a18da17a6832eff0a7c2090655b583"
 Removed supports_binary_field flag as all backends support them

 It was mainly for MySQL on Python 3, but now the current
 recommended MySQL driver for Python 3 (mysqlclient) does support
 binary fields, it is unneeded. Refs #20377.
 }}}

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

Re: [Django] #24031: Implement a Case/When expression

2015-01-11 Thread Django

#24031: Implement a Case/When expression
-+-
 Reporter:  jarshwah |Owner:  michalmo
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-alpha| 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 jarshwah):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin
 * needs_docs:  1 => 0


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

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

Re: [Django] #24115: Bcrypt hashers don't implement must_update

2015-01-11 Thread Django

#24115: Bcrypt hashers don't implement must_update
---+--
 Reporter:  cancan101  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by cancan101:

Old description:

> If the number of rounds is changed for the
> [https://github.com/django/django/blob/579433ceb88ab67d9851b49a44ce5b8f509c/django/contrib/auth/hashers.py#L273
> bcrypt hashers] it does not appear that the must_update will never return
> True. This is because the
> [https://github.com/django/django/blob/579433ceb88ab67d9851b49a44ce5b8f509c/django/contrib/auth/hashers.py#L216
> default implementation is used].
>
> For comparison, see
> [https://pythonhosted.org/passlib/lib/passlib.context.html#hash-migration
> passlib] which does in fact perform migrations for bcrypt.

New description:

 If the number of rounds is changed for the
 
[https://github.com/django/django/blob/579433ceb88ab67d9851b49a44ce5b8f509c/django/contrib/auth/hashers.py#L273
 bcrypt hashers] it does not appear that the must_update will ever return
 True. This is because the
 
[https://github.com/django/django/blob/579433ceb88ab67d9851b49a44ce5b8f509c/django/contrib/auth/hashers.py#L216
 default implementation is used].

 For comparison, see
 [https://pythonhosted.org/passlib/lib/passlib.context.html#hash-migration
 passlib] which does in fact perform migrations for bcrypt.

--

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

Re: [Django] #24115: Bcrypt hashers don't implement must_update

2015-01-11 Thread Django

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

Old description:

> If the number of rounds is changed for the bcrypt hashers it does not
> appear that the must_update will ever return True.

New description:

If the number of rounds is changed for the

[https://github.com/django/django/blob/579433ceb88ab67d9851b49a44ce5b8f509c/django/contrib/auth/hashers.py#L273
bcrypt hashers] it does not appear that the must_update will never return
True. This is because the

[https://github.com/django/django/blob/579433ceb88ab67d9851b49a44ce5b8f509c/django/contrib/auth/hashers.py#L216
default implementation is used].

For comparison, see
[https://pythonhosted.org/passlib/lib/passlib.context.html#hash-migration
passlib] which does in fact perform migrations for bcrypt.

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

Re: [Django] #24131: Docs: Shouldn't have ligatures enabled for monospace text

2015-01-11 Thread Django

#24131: Docs: Shouldn't have ligatures enabled for monospace text
-+-
 Reporter:  davidfstr|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by timgraham):

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


Comment:

 Thanks for the report. Moved to
 https://github.com/django/djangoproject.com/issues/304.

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

Re: [Django] #24131: Docs: Shouldn't have ligatures enabled for monospace text

2015-01-11 Thread Django

#24131: Docs: Shouldn't have ligatures enabled for monospace text
-+-
 Reporter:  davidfstr|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by davidfstr):

 * cc: davidfstr@… (added)
 * needs_better_patch:   => 0
 * 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/067.8717c2d012bbbc04c2a3ba728a69796e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24130: Docs: FastCGI deployment: flup6 as alternative to flup

2015-01-11 Thread Django

#24130: Docs: FastCGI deployment: flup6 as alternative to flup
---+--
 Reporter:  davidfstr  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 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
---+--
Changes (by timgraham):

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


Comment:

 Sorry, but as FastCGI support is deprecated, I don't think we should
 improve the docs.

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

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

[Django] #24131: Docs: Shouldn't have ligatures enabled for monospace text

2015-01-11 Thread Django

#24131: Docs: Shouldn't have ligatures enabled for monospace text
--+
 Reporter:  davidfstr |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  1
--+
 It's ugly.

 See attached screenshot.

 Multiple pages affected. Example:
 https://docs.djangoproject.com/en/1.7/topics/logging/

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

Re: [Django] #24129: Add indicator that migrations are rendering model states before applying the first migration

2015-01-11 Thread Django

#24129: Add indicator that migrations are rendering model states before applying
the first migration
-+-
 Reporter:  MarkusH  |Owner:  MarkusH
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by MarkusH):

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


Comment:

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

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

Re: [Django] #24123: LookupError when rolling back migrations

2015-01-11 Thread Django

#24123: LookupError when rolling back migrations
-+
 Reporter:  MarkusH  |Owner:  MarkusH
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 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 MarkusH):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #24130: Docs: FastCGI deployment: flup6 as alternative to flup

2015-01-11 Thread Django

#24130: Docs: FastCGI deployment: flup6 as alternative to flup
---+--
 Reporter:  davidfstr  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  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
---+--
Changes (by davidfstr):

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

Re: [Django] #24130: Docs: FastCGI deployment: flup6 as alternative to flup

2015-01-11 Thread Django

#24130: Docs: FastCGI deployment: flup6 as alternative to flup
---+--
 Reporter:  davidfstr  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  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
---+--
Changes (by davidfstr):

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


Comment:

 Created pull request here:
 https://github.com/django/django/pull/3893

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

Re: [Django] #23913: = comparison does work in templates although it shouldn't

2015-01-11 Thread Django

#23913: = comparison does work in templates although it shouldn't
-+-
 Reporter:  googol7  |Owner:
 Type:   |  olasitarska
  Cleanup/optimization   |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  1.8-alpha| 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:"d563e3be68369694a3bac1efd7779d8e03bb6a51"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d563e3be68369694a3bac1efd7779d8e03bb6a51"
 Fixed #23913 -- Deprecated the `=` comparison in `if` template tag.
 }}}

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

[Django] #24130: Docs: FastCGI deployment: flup6 as alternative to flup

2015-01-11 Thread Django

#24130: Docs: FastCGI deployment: flup6 as alternative to flup
---+
 Reporter:  davidfstr  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The current deployment docs related to FastCGI mention flup as a required
 module. However this module does not run on Python 3.x.

 flup6 is a drop in replacement fork of flup which does run on Python 3.x
 and I am successfully using it on a deployed site I administer.

 Therefore I think updating the docs to mention flup6 would be useful to
 other site admins who are trying to deploy Django with Python 3.x in a
 FastCGI configuration, not uncommon for shared hosting.

 Affected page:
 https://docs.djangoproject.com/en/1.7/howto/deployment/fastcgi/

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

Re: [Django] #24053: Drop IE6/7 admin CSS/icons

2015-01-11 Thread Django

#24053: Drop IE6/7 admin CSS/icons
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   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
--+

Comment (by seanwestfall):

 the patch I attached removes the file
 "django/contrib/admin/static/admin/css/ie.css" since  the whole file is
 used for the ie6&7 admins page. I also removed the image referenced by it:
 "django/contrib/admin/static/admin/img/inline-delete-8bit.png" and the
 line in the admin template that references the css file:
 "/django/contrib/admin/templates/admin/base.html".

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

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

Re: [Django] #23878: Query object/expression documentation needs to tidied

2015-01-11 Thread Django

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

Comment:

As per the suggestions I have moved the description of `Q` objects and
`Prefetch` objects from `queries.txt` into `querysets.txt`.
I've also added links from `filter` and `exclude` to `Q`, although the
wording there may not be the best.
There is already a link from `prefetch_related` paragraph to `Prefetch`,
so I didn't add any new description there.

This is currently on GitHub as a pull request
[https://github.com/django/django/pull/3889]

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

Re: [Django] #23913: = comparison does work in templates although it shouldn't

2015-01-11 Thread Django

#23913: = comparison does work in templates although it shouldn't
-+-
 Reporter:  googol7  |Owner:
 Type:   |  olasitarska
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-alpha| 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 berkerpeksag):

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

Re: [Django] #20380: MySQL doesn't support dates below 1000 on Python 3.2

2015-01-11 Thread Django

#20380: MySQL doesn't support dates below 1000 on Python 3.2
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => closed
 * resolution:   => 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/067.07d5b3eaa5230f2b487324095775a83f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20380: MySQL doesn't support dates below 1000 on Python 3.2

2015-01-11 Thread Django

#20380: MySQL doesn't support dates below 1000 on Python 3.2
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"412066e71e81e899bca63523f239e56138ec9e9d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="412066e71e81e899bca63523f239e56138ec9e9d"
 Revert "Marked a test as an expected failure on MySQL and Python 3.2."

 This reverts commit 832b4a5722ba6b55e7b17c3bac6614ecca9aa88d.
 We officially don't support MySQL on Python 3.2. Refs #20380.
 }}}

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

[Django] #24129: Add indicator that migrations are rendering model states before applying the first migration

2015-01-11 Thread Django

#24129: Add indicator that migrations are rendering model states before applying
the first migration
+-
 Reporter:  MarkusH |  Owner:  MarkusH
 Type:  New feature | Status:  new
Component:  Core (Management commands)  |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  1   |  UI/UX:  0
+-
 When running migrations, right before the "Applying
 someapp.0001_initial... OK" output, the process seems to hang. I propose
 to add an indicator like "Rendering model states... DONE" to make users
 aware of the fact that Django is still doing something.

 This is a simple fix after #24123 is 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/050.626ce4c76cf67898fea3f6dd61e06bed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23913: = comparison does work in templates although it shouldn't

2015-01-11 Thread Django

#23913: = comparison does work in templates although it shouldn't
-+-
 Reporter:  googol7  |Owner:
 Type:   |  olasitarska
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-alpha| 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.8-alpha
 * needs_better_patch:  1 => 0


Comment:

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

Re: [Django] #24116: Refactor AdminSite.check_dependencies with the checks framework

2015-01-11 Thread Django

#24116: Refactor AdminSite.check_dependencies with the checks framework
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by aaugustin:

Old description:

> The title says it all.

New description:

 The title says it all.

 This ticket should also consider improving or dropping the check for the
 `auth` context processor. Currently it's skipped when there isn't exactly
 one Django templates engine configured in `TEMPLATES`. This could be
 improved. It doesn't account for the possibility that a developer will
 provide their own customized version. This is intractable.

--

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

[Django] #24128: Admindocs doesn't account for template loaders

2015-01-11 Thread Django

#24128: Admindocs doesn't account for template loaders
-+
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admindocs  |Version:  master
   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  |
-+
 `TemplateDetailView` only considers `dirs` and assumes that the
 `filesystem` loader is enabled. It doesn't account for other loaders such
 as `app_directories`.

 The code changed a bit during the multiple-template-engines refactor but
 this bug existed before and still exists.

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

[Django] #24127: Automatically set the current URL namespace based on the URL of the current request

2015-01-11 Thread Django

#24127: Automatically set the current URL namespace based on the URL of the 
current
request
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Core   |Version:  master
  (URLs) |   Keywords:  multiple-template-
   Severity:  Normal |  engines
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The [https://docs.djangoproject.com/en/dev/topics/http/urls/#reversing-
 namespaced-urls documentation on URL namespaces] shows the following
 example:

 {{{
 def render_to_response(self, context, **response_kwargs):
 self.request.current_app = self.request.resolver_match.namespace
 return super(DetailView, self).render_to_response(context,
 **response_kwargs)
 }}}

 `self.request.current_app = self.request.resolver_match.namespace` looks
 like something that makes sense in general and could be done automatically
 for all requests.

 This became possible in Django 1.8 because `current_app` is now an
 attribute of the `request` object.

 There are some fairly obvious backwards-compatibility concerns, but this
 change looks like it could save a lot of boilerplate 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/052.2b1062f09cbec06a2709d49b97b84c96%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24126: Consider deprecating the current_app argument of auth views

2015-01-11 Thread Django

#24126: Consider deprecating the current_app argument of auth views
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  master
  contrib.auth   |   Keywords:  multiple-template-
   Severity:  Normal |  engines
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 All views defined in `django.contrib.auth.views` have the following
 structure:

 {{{
 def view(request, ..., current_app=None, ...):

 ...

 if current_app is not None:
 request.current_app = current_app

 return TemplateResponse(request, template_name, context)
 }}}

 As of Django 1.8 `current_app` is set on the `request` object. (This is
 debated but no other concrete proposal has been made at this time.)

 For consistency the auth views should require the caller to set it on the
 `request` instead of passing it in a separate argument.

 That would also avoid the risk of conflicts between a `current_app` set on
 the `request` and another `current_app` passed in argument. Currently the
 latter overrides the former.

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

[Django] #24125: TemplateDetailView in admindocs requires a single Django templates engine

2015-01-11 Thread Django

#24125: TemplateDetailView in admindocs requires a single Django templates 
engine
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  master
  contrib.admindocs  |
   Severity:  Release|   Keywords:  multiple-template-
  blocker|  engines
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `TemplateDetailView.get_context_data()` calls `Engine.get_default()` which
 raises `ImproperlyConfigured` if zero or several Django templates engines
 are configured.

 This limitation should either be lifted or documented. Gracefully showing
 an error message would already be better than failing with an uncaught
 exception.

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

[Django] #24124: Review the list of default context processors

2015-01-11 Thread Django

#24124: Review the list of default context processors
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Template   |Version:  master
  system |   Keywords:  multiple-template-
   Severity:  Normal |  engines
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In the settings file generated by the default project template,
 `TEMPLATES` contains a list of template context processors.

 Currently this list is the same as the default
 `TEMPLATE_CONTEXT_PROCESSORS`. This doesn't seem optimal. For instance,
 the `request` context processor is missing.

 We should think a bit about what the correct default value is. See this
 [https://groups.google.com/d/msg/django-
 developers/WlK_7OoThaQ/9UFj2aAr7IAJ django-developers discussion].

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

Re: [Django] #24123: LookupError when rolling back migrations

2015-01-11 Thread Django

#24123: LookupError when rolling back migrations
-+
 Reporter:  MarkusH  |Owner:  MarkusH
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 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 collinanderson):

 * cc: cmawebsite@… (added)
 * 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.65d22766fe94a8a185b820e01872f6a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24123: LookupError when rolling back migrations

2015-01-11 Thread Django

#24123: LookupError when rolling back migrations
-+--
 Reporter:  MarkusH  |Owner:  MarkusH
 Type:  Bug  |   Status:  new
Component:  Migrations   |  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 MarkusH):

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


Old description:

> The `MigrationExecutor.migrate()` method generates the initial project
> state from the first migration that is being applied/unapplied. If this
> migration has no relations to other apps that are also being (un)applied,
> this can lead to `LookupError`s due to missing models:
>
> {{{#!python
> Traceback (most recent call last):
>   File "/home/markus/Coding/django/django/apps/registry.py", line 148, in
> get_app_config
> return self.app_configs[app_label]
> KeyError: 'app_b'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/markus/Coding/django/django/db/migrations/state.py", line
> 181, in __init__
> model = self.get_model(lookup_model[0], lookup_model[1])
>   File "/home/markus/Coding/django/django/apps/registry.py", line 202, in
> get_model
> return self.get_app_config(app_label).get_model(model_name.lower())
>   File "/home/markus/Coding/django/django/apps/registry.py", line 150, in
> get_app_config
> raise LookupError("No installed app with label '%s'." % app_label)
> LookupError: No installed app with label 'app_b'.
>
> 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 "/home/markus/Coding/django/django/core/management/__init__.py",
> line 338, in execute_from_command_line
> utility.execute()
>   File "/home/markus/Coding/django/django/core/management/__init__.py",
> line 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/home/markus/Coding/django/django/core/management/base.py", line
> 390, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/home/markus/Coding/django/django/core/management/base.py", line
> 444, in execute
> output = self.handle(*args, **options)
>   File
> "/home/markus/Coding/django/django/core/management/commands/migrate.py",
> line 213, in handle
> executor.migrate(targets, plan, fake=options.get("fake", False))
>   File "/home/markus/Coding/django/django/db/migrations/executor.py",
> line 75, in migrate
> state = self.unapply_migration(state, migration, fake=fake)
>   File "/home/markus/Coding/django/django/db/migrations/executor.py",
> line 130, in unapply_migration
> state = migration.unapply(state, schema_editor)
>   File "/home/markus/Coding/django/django/db/migrations/migration.py",
> line 157, in unapply
> operation.database_backwards(self.app_label, schema_editor,
> from_state, to_state)
>   File
> "/home/markus/Coding/django/django/db/migrations/operations/models.py",
> line 62, in database_backwards
> model = from_state.apps.get_model(app_label, self.name)
>   File "/home/markus/Coding/django/django/utils/functional.py", line 60,
> in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "/home/markus/Coding/django/django/db/migrations/state.py", line
> 82, in apps
> return StateApps(self.real_apps, self.models)
>   File "/home/markus/Coding/django/django/db/migrations/state.py", line
> 191, in __init__
> raise ValueError(msg.format(field=operations[0][1],
> model=lookup_model))
> ValueError: Lookup failed for model referenced by field app_a.A3.b2:
> app_b.B2
> }}}
>
> Given the attached migration dependencies, the backwards plan for
> `('app_a', None)` is
>
> {{{#!python
> [
> (, True),
> (, True),
> (, True),
> (, True),
> (, True),
> (, True),
> (, True),
> (, True)
> ]
> }}}
>
> The initial state generated from `app_c.0003_c3` is
>
> {{{
>   app_a.a1:
>   app_a.a2:
>   app_c.c1:
>   app_c.c2:
> }}}
>
> As one can see, there are no models of `app_b`, which eventually leads to
> an error when unapplying `app_1.0003_a3` which tries to look up model
> `app_b.B2`.

New description:

 The `MigrationExecutor.migrate()` method generates the initial project
 state from the first migration that is being applied/unapplied. If this
 migration has no relations to other apps that are also being (un)applied,
 this can lead to `LookupError`s due to missing models:

 {{{#!py

[Django] #24123: LookupError when rolling back migrations

2015-01-11 Thread Django

#24123: LookupError when rolling back migrations
-+-
 Reporter:  MarkusH  |  Owner:  MarkusH
 Type:  Bug  | Status:  new
Component:  Migrations   |Version:  master
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 The `MigrationExecutor.migrate()` method generates the initial project
 state from the first migration that is being applied/unapplied. If this
 migration has no relations to other apps that are also being (un)applied,
 this can lead to `LookupError`s due to missing models:

 {{{#!python
 Traceback (most recent call last):
   File "/home/markus/Coding/django/django/apps/registry.py", line 148, in
 get_app_config
 return self.app_configs[app_label]
 KeyError: 'app_b'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/home/markus/Coding/django/django/db/migrations/state.py", line
 181, in __init__
 model = self.get_model(lookup_model[0], lookup_model[1])
   File "/home/markus/Coding/django/django/apps/registry.py", line 202, in
 get_model
 return self.get_app_config(app_label).get_model(model_name.lower())
   File "/home/markus/Coding/django/django/apps/registry.py", line 150, in
 get_app_config
 raise LookupError("No installed app with label '%s'." % app_label)
 LookupError: No installed app with label 'app_b'.

 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 "/home/markus/Coding/django/django/core/management/__init__.py",
 line 338, in execute_from_command_line
 utility.execute()
   File "/home/markus/Coding/django/django/core/management/__init__.py",
 line 330, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/markus/Coding/django/django/core/management/base.py", line
 390, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/markus/Coding/django/django/core/management/base.py", line
 444, in execute
 output = self.handle(*args, **options)
   File
 "/home/markus/Coding/django/django/core/management/commands/migrate.py",
 line 213, in handle
 executor.migrate(targets, plan, fake=options.get("fake", False))
   File "/home/markus/Coding/django/django/db/migrations/executor.py", line
 75, in migrate
 state = self.unapply_migration(state, migration, fake=fake)
   File "/home/markus/Coding/django/django/db/migrations/executor.py", line
 130, in unapply_migration
 state = migration.unapply(state, schema_editor)
   File "/home/markus/Coding/django/django/db/migrations/migration.py",
 line 157, in unapply
 operation.database_backwards(self.app_label, schema_editor,
 from_state, to_state)
   File
 "/home/markus/Coding/django/django/db/migrations/operations/models.py",
 line 62, in database_backwards
 model = from_state.apps.get_model(app_label, self.name)
   File "/home/markus/Coding/django/django/utils/functional.py", line 60,
 in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "/home/markus/Coding/django/django/db/migrations/state.py", line
 82, in apps
 return StateApps(self.real_apps, self.models)
   File "/home/markus/Coding/django/django/db/migrations/state.py", line
 191, in __init__
 raise ValueError(msg.format(field=operations[0][1],
 model=lookup_model))
 ValueError: Lookup failed for model referenced by field app_a.A3.b2:
 app_b.B2
 }}}

 Given the attached migration dependencies, the backwards plan for
 `('app_a', None)` is

 {{{#!python
 [
 (, True),
 (, True),
 (, True),
 (, True),
 (, True),
 (, True),
 (, True),
 (, True)
 ]
 }}}

 The initial state generated from `app_c.0003_c3` is

 {{{
   app_a.a1:
   app_a.a2:
   app_c.c1:
   app_c.c2:
 }}}

 As one can see, there are no models of `app_b`, which eventually leads to
 an error when unapplying `app_1.0003_a3` which tries to look up model
 `app_b.B2`.

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

[Django] #24122: Redirect to translated url after setting language

2015-01-11 Thread Django

#24122: Redirect to translated url after setting language
-+-
 Reporter:  gbdlin   |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:   |Version:  1.7
  Internationalization   |   Keywords:  set_language,
 Severity:  Normal   |  i18n_patterns, translating urls
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+-
 When user change language using set_language view, we can redirect him
 either to url from 'next' post value or 'HTTP_REFERER' header. But if
 i18n_patterns is in use or urls are translated, user will be redirected to
 old url (if no next url) or we must provide new, translated url into next
 value which involves javascript when we want to have dropdown to select
 new language. This can cause:
  - language not changed if i18n_patterns is in use,
  - redirect to 404 or different page when urls are translated.

 I'm proposing patch to translate url taken from 'next' or 'HTTP_REFERER'
 into new language:


 {{{
 def set_language(request):
 """
 Redirect to a given url while setting the chosen language in the
 session or cookie. The url and the language code need to be
 specified in the request parameters.

 Since this view changes how the user will see the rest of the site, it
 must
 only be accessed as a POST request. If called as a GET request, it
 will
 redirect to the page in the request (the 'next' parameter) without
 changing
 any state.
 """
 next = request.POST.get('next', request.GET.get('next'))
 if not is_safe_url(url=next, host=request.get_host()):
 next = request.META.get('HTTP_REFERER')
 if not is_safe_url(url=next, host=request.get_host()):
 next = '/'
 response = http.HttpResponseRedirect(next)
 if request.method == 'POST':
 lang_code = request.POST.get('language', None)
 if lang_code and check_for_language(lang_code):
 parsed = urlsplit(next)
 try:
 match = resolve(parsed.path)
 except Resolver404:
 pass
 else:
 activate(lang_code)
 try:
 url = reverse("%s:%s" % (match.namespace,
 match.url_name) if match.namespace else match.url_name, args=match.args,
 kwargs=match.kwargs)
 except NoReverseMatch:
 pass
 else:
 next = urlunsplit((parsed.scheme, parsed.netloc, url,
 parsed.query, parsed.fragment))
 response = http.HttpResponseRedirect(next)
 if hasattr(request, 'session'):
 request.session[LANGUAGE_SESSION_KEY] = lang_code
 else:
 response.set_cookie(settings.LANGUAGE_COOKIE_NAME,
 lang_code,
 max_age=settings.LANGUAGE_COOKIE_AGE,
 path=settings.LANGUAGE_COOKIE_PATH,
 domain=settings.LANGUAGE_COOKIE_DOMAIN)
 return response
 }}}

 I'm not sure if this is an bug report or new feature (for me, redirecting
 to 404 or not changing language is definetly a bug) so I left it
 uncategorized. [[BR]]
 Fork on github: https://github.com/gbdlin/django [[BR]]
 Old simmillar (not sure if same case, because of not much explanation from
 author) ticket: https://code.djangoproject.com/ticket/17569 [[BR]]

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

Re: [Django] #24096: GROUP BY on oracle fails with TextField and BinaryField

2015-01-11 Thread Django

#24096: GROUP BY on oracle fails with TextField and BinaryField
-+-
 Reporter:  jarshwah |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 shaib):

 The meta option is indeed attractive. I would add a twist: Allow a field
 to declare itself deferred (this would somewhat parallel), that is, a new
 field option `deferred=False`.

 Build into that some API which will let the LOB field find out that
 they're on Oracle (or, more generally, a backend with
 `can_compare_lobs=False`), and you also get the automatic-compatibility.

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

Re: [Django] #24109: Provide a way to mark a migration operation as elidable when squashing

2015-01-11 Thread Django

Comment (by shaib):

While this appears to be a generally good idea, I think a better solution
for the use-case would be a specific data-move operation, if we can come
up with one that is general enough. Usually, the data-migration is needed
because old-field and new-field are not on the same model (incl. moving
from FK to M2M) -- or because some explicit transformation is required
(e.g. turning some field from string to number). These, I suspect, can be
collected into an operation that the optimizer and the executor can
understand, and perhaps could even be auto-detected in some way.

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

Re: [Django] #24121: Provide a better repr() experience

2015-01-11 Thread Django

#24121: Provide a better repr() experience
---+
 Reporter:  kezabelle  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by berkerpeksag):

 > 
 >
 > 
 >
 > 

 `charset`, `name` and `loadname` should also be a string.

 {{{
 

 
 }}}

 Here's an example from Python:

 {{{
 >>> open('README')
 <_io.TextIOWrapper name='README' mode='r' encoding='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/067.62342930e3ed3d3938cd7a6121071931%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24121: Provide a better repr() experience

2015-01-11 Thread Django

#24121: Provide a better repr() experience
---+
 Reporter:  kezabelle  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  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 jarshwah):

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

Re: [Django] #24060: Allow expressions to be used in order_by queryset method

2015-01-11 Thread Django

#24060: Allow expressions to be used in order_by queryset method
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  expressions  | Triage Stage:  Ready for
  order_by 1.8-alpha |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin
 * needs_tests:  1 => 0
 * needs_docs:  1 => 0


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

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

[Django] #24121: Provide a better repr() experience

2015-01-11 Thread Django

#24121: Provide a better repr() experience
---+
 Reporter:  kezabelle  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 For a long time, Django has shipped with the debug 500 handler, which
 defaults to a view where "local vars" for every stack frame can be
 expanded and inspected to see the internal state at the various points in
 the stack trace.

 Between that renderer, the heavy usage of `django-debug-toolbar`, which
 ships with a template context inspector, and my preference throwing `pdb`
 everywhere, there is a notable lack of a good `repr()` experience in much
 of Django, both in debugging public API (that is, the bits a user will use
 and encounter), and internals that might be exposed, or could otherwise be
 served better by having a repr that says something more than it's
 address/id.

 A couple of previous tickets have addressed this in minor, one off ways -
 #23167, #22906, #22531 - but as I've begun collecting places they could
 supply useful info as I spot them in my stuff, they've become a hodgepodge
 across a number of modules.

 For example, a couple I've got implemented:
 {{{
 

 

 
 }}}
 All of which, IMHO, provide a more useful context in which to evaluate
 state.

 The branch I have implemented my reprs in is in no way merge ready yet,
 partially because there's no tests, and it'd need rebasing & squashing,
 but also because there are some parts I'd like to see reprs on but haven't
 landed on a good way to do so.
 An example being the concept of a `Loader`, which currently has no repr()
 and thus shows up as `` which at least
 tells us which loader is being referenced. Given the convention so far for
 reprs() is just the class name (rather than module + class), the fact all
 Loaders (and now Engines) all share the same class name means in exposing
 more useful internal state we lose knowledge of the loader in question's
 module namespace.

 As I write this, I've got at least rudimentary (as in, it was possibly to
 replace the 0x... with at least one object-state variable) reprs for:
 * `StaticNode`
 * `BlockTranslateNode`
 * `URLNode`
 * `Token`
 * `Lexer`
 * `Parser`
 * `FilterExpression`
 * `RedirectFallbackMiddleware`
 * `MessageMiddleware`
 * `RemoteUserMiddleware`
 * `Col`
 * `Lookup`
 * `BaseDatabaseWrapper`
 * `SQLCompiler`
 * `JoinPromoter`
 * `HttpResponseNotAllowed`
 * `PermWrapper`
 * `SessionStorage`
 * `CookieStorage`
 * `FallbackStorage`
 * `ChangeList`
 * `AdminForm`
 * `InlineAdminFormSet`
 * `CsrfViewMiddleware`
 * `Response`
 * `SimpleTemplateResponse`
 * `TemplateResponse`
 * `AdminSite`
 * `ModelAdmin`
 * `Origin`
 * `TemplateOrigin`
 * `BlockContext`
 * `IncludeNode`
 * `Template`/`Engine` (would need work still I think)


 If accepted, this ticket could just track whatever I can end up getting
 reviewed/merged, or it could be a meta-ticket for accepting as a
 principle, and I could spin off tickets for more targeted areas.

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

[Django] #24120: Backend-agnostic debug information on template loading failures

2015-01-11 Thread Django

#24120: Backend-agnostic debug information on template loading failures
-+-
Reporter: aaugustin | Owner: nobody
Type: Bug| Status: new
Component: Template |Version: master
system | Keywords: multiple-template-
Severity: Normal | engines
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+-
Currently ExceptionReporter.get_traceback_data() contains a special case
for exceptions raised when a template cannot be found.

It retries loading the template with each template loader to figure out
which paths were tried. Since the multiple templates engines refactor,
this still works, but only if there's only one Django templates engine
configured.

This logic should be embedded in the template engine. Third-part engines
should have access to similar functionality through a public API.

Some ideas were brought up in [https://groups.google.com/d/msg/django-
developers/VFBLAoPSplI/H_hQq29u8PcJ this django-developers discussion].

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

[Django] #24119: Backend-agnostic tracebacks on template rendering errors

2015-01-11 Thread Django

#24119: Backend-agnostic tracebacks on template rendering errors
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Template   |Version:  master
  system |   Keywords:  multiple-template-
   Severity:  Normal |  engines
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently `ExceptionReporter.get_traceback_data()` contains a special case
 for exceptions raised during template rendering.

 If the exception has a `django_template_source` attribute, which is set by
 the `Debug` variants of the Django template language's classes,
 information is gathered by
 `ExceptionReporter.get_template_exception_info()`

 This logic should be embedded in the template engine. Third-part engines
 should have access to similar functionality through a public API.

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

Re: [Django] #24118: Add --debug-sql option to tests to print SQL queries on failure

2015-01-11 Thread Django

#24118: Add --debug-sql option to tests to print SQL queries on failure
---+
 Reporter:  mjtamlyn   |Owner:  mjtamlyn
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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 mjtamlyn):

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


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

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

52 matches

Mail list logo