date:20151211

Re: [Django] #25878: APPEND_SLASH doesn't work with DEBUG=False when template/404.html is erroneous

2015-12-11 Thread Django

Comment (by electricjay):

Rendering the 404 template before redirection is an unfortunate side
effect of the above mentioned patch. Fortunately the overhead this
rendering is very minor compared to the overhead of a client side
redirect.

I think the developer overhead of understanding what is happening when
things wrong in the 404 rendering is not nearly so minor.

Ideally the 404 would be caught before the template is rendered, but my
recollection is that 404 exceptions are not sent through the
//process_exception// middleware

In my opinion the cleanest solution would be to feed all exceptions
through the //process_exception// middleware, and then modify the common
middleware to take advantage of this. There would however be some risk of
this interacting badly with existing //process_exception// middleware.

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

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

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

2015-12-11 Thread Django

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

Comment (by vincepandolfo):

 New commit diff:
 
[https://github.com/vincepandolfo/django/commit/99ac598e903c18dadca8dcc55a5d28aa6c95b47c]

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

Re: [Django] #24475: Add a new testconnections management command

2015-12-11 Thread Django

Comment (by alexmorozov):

@shaib, the whole "checks" framework seems to me to be a registry of
various checks of "system health". Remote dependencies are (for me) the
perfect fit for that. Introducing another command seems to be an real
cognitive overhead.
As for the "remote" connections - I'm quite fine with that, it would help
a lot on deploy. Though such kind of checks surely should be warnings, not
errors.

@timgraham, speaking of starting this as a separate project - I'm not sure
there's an easy way to register those tests as 'checks', while having the
check framework skipping them for the 'common' run. And implementing a
separate 'remote checks' registry (mostly copy-pasting the checks' code)
looks like a total mess for me.

If we could mark some checks tags to be skipped at the plain run (more
generic way of that "deploy" thing), would it be of help?

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

Re: [Django] #25920: Add number formatting support for locales that use non-uniform digit grouping (e.g. India) (was: django.contrib.humanize filters are not well localized for en_IN)

2015-12-11 Thread Django

#25920: Add number formatting support for locales that use non-uniform digit
grouping (e.g. India)
--+
 Reporter:  dbinoj|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  en-IN | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * component:  contrib.humanize => Internationalization


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

Re: [Django] #25920: django.contrib.humanize filters are not well localized for en_IN

2015-12-11 Thread Django

#25920: django.contrib.humanize filters are not well localized for en_IN
--+
 Reporter:  dbinoj|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.humanize  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  en-IN | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * type:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 Confirmed, Django doesn't support this sort of grouping yet.

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

Re: [Django] #22822: Javascript en_* translations ignored if no en or en_us translations exist

2015-12-11 Thread Django

#22822: Javascript en_* translations ignored if no en or en_us translations 
exist
-+-
 Reporter:  pforth@… |Owner:  anonymous
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.6
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 [https://github.com/django/django/pull/5809 PR] (currently lacks tests)

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

Re: [Django] #25918: Remove unused LOGOUT_URL setting

2015-12-11 Thread Django

#25918: Remove unused LOGOUT_URL setting
--+
 Reporter:  hop   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"030ee15850182dc2db78c6250f5f5a19d1d2e0bc" 030ee158]:
 {{{
 #!CommitTicketReference repository=""
 revision="030ee15850182dc2db78c6250f5f5a19d1d2e0bc"
 Refs #25918 -- Fixed typo in 1.10 release notes.
 }}}

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

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

Re: [Django] #25918: Remove unused LOGOUT_URL setting

2015-12-11 Thread Django

#25918: Remove unused LOGOUT_URL setting
--+
 Reporter:  hop   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"59f861fcb49a43acfbf2f75e683a7cb971600f52" 59f861f]:
 {{{
 #!CommitTicketReference repository=""
 revision="59f861fcb49a43acfbf2f75e683a7cb971600f52"
 Fixed #25918 -- Removed unused LOGOUT_URL setting.

 Thanks hop for the report and patch.
 }}}

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

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

Re: [Django] #25921: Make runserver handle HTTPS requests.

2015-12-11 Thread Django

#25921: Make runserver handle HTTPS requests.
-+-
 Reporter:  azmeuk   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  runserver, ssl,  | Triage Stage:
  https  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 This was previously proposed on [https://groups.google.com/d/topic/django-
 developers/PgBcSEiUdw0/discussion django-developers] and declined in favor
 of other options.

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

Re: [Django] #25921: Make runserver handle HTTPS requests.

2015-12-11 Thread Django

#25921: Make runserver handle HTTPS requests.
-+-
 Reporter:  azmeuk   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  runserver, ssl,  | Triage Stage:
  https  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by azmeuk):

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


Old description:

> Hi. The builtin '''manage.py check --deploy''' encourages to enable all
> the available securities, including SECURE_SSL_REDIRECT that actually
> redirect any non HTTP request to a HTTPS request. However '''manage.py
> runserver''' does not allow HTTPS request. It is too bad that we cannot
> test all the available options in development before we deploy an app.
>
> The existing [https://github.com/teddziuba/django-sslserver django-
> sslserver] solves the issue, quite simply. But on the other hand,
> '''manage.py runsslserver''' does not allow simple HTTP request.
>
> I think this would be a good idea to enhance the current runsslserver
> with what we can find in django-sslserver, so in the end it can handle
> both HTTP and HTTPS requests.
>
> I am OK to make a merge request if you are interested.

New description:

 Hi. The builtin '''manage.py check --deploy''' encourages to enable all
 the available securities, including SECURE_SSL_REDIRECT that actually
 redirect any non HTTP request to a HTTPS request. However '''manage.py
 runserver''' does not allow HTTPS requests. It is too bad that we cannot
 test all the available options in development before we deploy an app.

 The existing [https://github.com/teddziuba/django-sslserver django-
 sslserver] solves the issue, quite simply. But on the other hand,
 '''manage.py runsslserver''' does not allow simple HTTP request.

 I think this would be a good idea to enhance the current runsslserver with
 what we can find in django-sslserver, so in the end it can handle both
 HTTP and HTTPS requests.

 I am OK to make a merge request if you are interested.

--

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

[Django] #25921: Make runserver handle HTTPS requests.

2015-12-11 Thread Django

#25921: Make runserver handle HTTPS requests.
---+---
Reporter: azmeuk | Owner: nobody
Type: New feature| Status: new
Component: HTTP handling |Version: master
Severity: Normal | Keywords: runserver, ssl, https
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+---
Hi. The builtin '''manage.py check --deploy''' encourages to enable all
the available securities, including SECURE_SSL_REDIRECT that actually
redirect any non HTTP request to a HTTPS request. However '''manage.py
runserver''' does not allow HTTPS request. It is too bad that we cannot
test all the available options in development before we deploy an app.

The existing [https://github.com/teddziuba/django-sslserver django-
sslserver] solves the issue, quite simply. But on the other hand,
'''manage.py runsslserver''' does not allow simple HTTP request.

I think this would be a good idea to enhance the current runsslserver with
what we can find in django-sslserver, so in the end it can handle both
HTTP and HTTPS requests.

I am OK to make a merge request if you are interested.

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

Re: [Django] #25918: Remove unused LOGOUT_URL setting

2015-12-11 Thread Django

#25918: Remove unused LOGOUT_URL setting
--+
 Reporter:  hop   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by hop):

 * Attachment "fix_25918_2.patch" 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/061.aec8bc1af8637f686e99337d39b3b3b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25918: Remove unused LOGOUT_URL setting

2015-12-11 Thread Django

#25918: Remove unused LOGOUT_URL setting
--+
 Reporter:  hop   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by hop):

 I'm blind and stupid.

 Updated patch is attached.

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

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

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

2015-12-11 Thread Django

#24116: Refactor AdminSite.check_dependencies with the checks framework
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  vincepandolfo
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Ideally we could also add some tests for this and documentation in
 `docs/ref/checks.txt`.

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

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

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

2015-12-11 Thread Django

#24116: Refactor AdminSite.check_dependencies with the checks framework
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  vincepandolfo
  Cleanup/optimization   |   Status:  assigned
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:  1|UI/UX:  0
-+-

Comment (by vincepandolfo):

 I was reading the docs for the admin site and it lists some dependencies
 that are not checked by the check_dependencies() method. Should I add
 checks for those other dependencies or are the docs outdated?

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

Re: [Django] #25918: Remove unused LOGOUT_URL setting

2015-12-11 Thread Django

#25918: Remove unused LOGOUT_URL setting
--+
 Reporter:  hop   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by timgraham):

 `docs/releases/1.10.txt` exists in master.

 There isn't really a way to deprecate the setting so removing it should be
 fine. Anyway using it can add it to their local settings.

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

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

Re: [Django] #25903: "Add another" related field buttons in list_editable don't open a popup (was: ModelAdmin popups won't close)

2015-12-11 Thread Django

#25903: "Add another" related field buttons in list_editable don't open a popup
--+
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Release blocker   |   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks, bisected to 0decef337f7f00d73b380531ac22cbc843d6e806 (#24405).

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

Re: [Django] #25918: Remove unused LOGOUT_URL setting

2015-12-11 Thread Django

#25918: Remove unused LOGOUT_URL setting
--+
 Reporter:  hop   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by hop):

 * Attachment "fix_25918.patch" 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/061.1c2af9b9b4a03f2ecc09650bc5a1704c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25918: Remove unused LOGOUT_URL setting

2015-12-11 Thread Django

#25918: Remove unused LOGOUT_URL setting
--+
 Reporter:  hop   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by hop):

 The patch itself is trivial, but there is not file for the release notes,
 yet.

 Does this have to be deprecated first?

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

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

Re: [Django] #25920: django.contrib.humanize filters are not well localized for en_IN

2015-12-11 Thread Django

#25920: django.contrib.humanize filters are not well localized for en_IN
--+--
 Reporter:  dbinoj|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.humanize  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  en-IN | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by dbinoj):

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


Comment:

 There is a complication in adding en_IN. Number grouping in en_IN is not
 grouped on 'n' number of digits. First 3 (ones, tens and hundreds) are
 grouped as a single group and the remaining digits are grouped as 2 digits
 per group. This can be achieved with a NUMBER_GROUPING setting. So I don't
 think this can be fixed by adding a locale.

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

Re: [Django] #25903: ModelAdmin popups won't close

2015-12-11 Thread Django

Comment (by muffinmad):

Replying to [comment:8 timgraham]:
> Could you please be more specific with a sample project and/or steps to
reproduce?

Sorry, forgot to mention that i'm using custom ModelAdmin with
list_editable field.
In attachment you can find sample project to reproduce the bug:

1. Create new Product. In the product creation form click on "Add another
category" will popup new window as expected.
2. Navigate to /admin/products/product/. Click on "Add another category"
near the product category will not open popup.

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

Re: [Django] #25903: ModelAdmin popups won't close

2015-12-11 Thread Django

#25903: ModelAdmin popups won't close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by muffinmad):

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

Re: [Django] #25920: django.contrib.humanize filters are not well localized for en_IN

2015-12-11 Thread Django

#25920: django.contrib.humanize filters are not well localized for en_IN
--+--
 Reporter:  dbinoj|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.humanize  |  Version:  1.9
 Severity:  Normal|   Resolution:  invalid
 Keywords:  en-IN | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

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


Comment:

 I think the solution here is to add formats for the `en_IN` locale (like
 ff2e0896a3f7b566c8a0802b2191d30c6070c8f6, for example). Please send a pull
 request if you can do that. I don't think there's much value in leaving an
 open ticket for each locale that we're missing. Thanks!

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

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

Re: [Django] #24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8

2015-12-11 Thread Django

#24622: Response "context" and "templates" not available in the Test Client when
using Jinja2 - Django 1.8
-+
 Reporter:  rivantis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  jinja2, test client  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by timgraham):

 Sure, feel free to submit a pull request.

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

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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

2015-12-11 Thread Django

#21608: Logged out sessions are resurrected by concurrent requests
--+-
 Reporter:  jonasborgstrom|Owner:  anonymous
 Type:  Bug   |   Status:  assigned
Component:  contrib.sessions  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by tltx):

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

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

2015-12-11 Thread Django

Comment (by tltx):

I have reproduced this bug with the test site
(https://github.com/jborg/django-21608) on both Django 1.8.7 and 1.9
(using SQLite).

These were the steps I used:
* Open the admin page in a tab and log in. http://localhost:8000/admin/
* Switch to a new tab and open the slow page. http://localhost:8000/slow/
Act fast after this step to complete the next three steps before the slow
page has finished loaded, <10 sec
* Switch back to tab with the admin page.
* Click the "Logout" link on the top right corner of the page. -> Now you
are on the logout page
* Reload page -> Now you are on the login page.
* Wait for slow page to finish loading.
* Reload the tab with the login page.
* Logged in again without entering credentials!

This is a security issue, not critical though, as someone might think that
they have logged out but is actually still logged in.
If you logout and leave a public computer while a page is still loading in
another tab there is a risk that the next person using that computer can
get access to your account.
It would be nice to have this fixed 1.8 and up.

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

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

Re: [Django] #25919: Wrong behavior after saving on changelist page when any field is list_editable

2015-12-11 Thread Django

#25919: Wrong behavior after saving on changelist page when any field is
list_editable
-+-
 Reporter:  c0ntribut0r  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  list_editable| Triage Stage:
  pagination cl.result_list  |  Unreviewed
  queryset   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by c0ntribut0r):

 I've investigated. It was because I didn't set up ordering like {{{
 ordering = ['-id'] }}}. The ordering was undefined for each page slice
 which led to these kind of errors.

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

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

Re: [Django] #24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8

2015-12-11 Thread Django

#24622: Response "context" and "templates" not available in the Test Client when
using Jinja2 - Django 1.8
-+
 Reporter:  rivantis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  jinja2, test client  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by phispi):

 Thanks! Maybe it's just me misunderstanding it... What about something
 like
 "This attribute is set to an empty list when not using the
 `django.template.backends.django.DjangoTemplates backend`." for the
 `templates` attribute and "This attribute is set to `None` when not using
 the `django.template.backends.django.DjangoTemplates backend`." for the
 `context` attribute?

 Initially I came across this bug report after spending an evening trying
 to find out why `assertTemplateUsed` does not work as expected (using a
 3rd party template engine). Maybe a warning at
 
https://docs.djangoproject.com/en/1.9/topics/testing/tools/#django.test.SimpleTestCase.assertTemplateUsed
 would be useful as well - especially for people who do not know how Django
 internally gets the information necessary for this test?

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

Re: [Django] #25905: Unsafe usage of urljoin() within FileStorageSystem

2015-12-11 Thread Django

#25905: Unsafe usage of urljoin() within FileStorageSystem
--+
 Reporter:  free-Runner   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  File uploads/storage  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  file, storage | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_tests:  0 => 1


Comment:

 A test is also needed. If you could send a pull request after adding that,
 it's easiest for review purposes.

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

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

Re: [Django] #25893: Custom Lookups & Transform example lhs/rhs swap

2015-12-11 Thread Django

#25893: Custom Lookups & Transform example lhs/rhs swap
-+-
 Reporter:  browniebroke |Owner:
 Type:   |  browniebroke
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"c0c2c7ecd6780b1207b18d96a60c807dbb98eb81" c0c2c7e]:
 {{{
 #!CommitTicketReference repository=""
 revision="c0c2c7ecd6780b1207b18d96a60c807dbb98eb81"
 [1.8.x] Fixed #25893 -- Corrected custom lookups example.

 Backport of ffcdb0b471d0afc72b42b0a2b0c0c4fb45d7b6b1 from master
 }}}

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

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

[Django] #25920: django.contrib.humanize filters are not well localized for en_IN

2015-12-11 Thread Django

#25920: django.contrib.humanize filters are not well localized for en_IN
--+
 Reporter:  dbinoj|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.humanize  |Version:  1.9
 Severity:  Normal|   Keywords:  en-IN
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When using 'en-IN' as locale (listed as valid in
 http://www.i18nguy.com/unicode/language-identifiers.html) 10.00 should
 look like 1,00,000.00 after using intcomma. Instead 100,000.00 is
 displayed.

 Works as expected in locale package as below (with en_IN installed, of
 course):
 {{{
 In [1]: import locale

 In [2]: locale.setlocale(locale.LC_ALL, 'en_IN')
 Out[2]: 'en_IN'

 In [3]: locale.format("%.2f", 10.00, grouping=True)
 Out[3]: '1,00,000.00'
 }}}

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

Re: [Django] #25893: Custom Lookups & Transform example lhs/rhs swap

2015-12-11 Thread Django

#25893: Custom Lookups & Transform example lhs/rhs swap
-+-
 Reporter:  browniebroke |Owner:
 Type:   |  browniebroke
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"740feb48017e92d1edc11e2d9eba5cf8b9eea3af" 740feb48]:
 {{{
 #!CommitTicketReference repository=""
 revision="740feb48017e92d1edc11e2d9eba5cf8b9eea3af"
 [1.9.x] Fixed #25893 -- Corrected custom lookups example.

 Backport of ffcdb0b471d0afc72b42b0a2b0c0c4fb45d7b6b1 from master
 }}}

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

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

Re: [Django] #25893: Custom Lookups & Transform example lhs/rhs swap

2015-12-11 Thread Django

#25893: Custom Lookups & Transform example lhs/rhs swap
-+-
 Reporter:  browniebroke |Owner:
 Type:   |  browniebroke
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ffcdb0b471d0afc72b42b0a2b0c0c4fb45d7b6b1" ffcdb0b]:
 {{{
 #!CommitTicketReference repository=""
 revision="ffcdb0b471d0afc72b42b0a2b0c0c4fb45d7b6b1"
 Fixed #25893 -- Corrected custom lookups example.
 }}}

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

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

Re: [Django] #25919: Wrong behavior after saving on changelist page when any field is list_editable

2015-12-11 Thread Django

#25919: Wrong behavior after saving on changelist page when any field is
list_editable
-+-
 Reporter:  c0ntribut0r  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  list_editable| Triage Stage:
  pagination cl.result_list  |  Unreviewed
  queryset   |
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:   => duplicate


Comment:

 Duplicate of #11313. Could you test the
 [https://github.com/django/django/pull/5686 pull request]?

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

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

Re: [Django] #25919: Wrong behavior after saving on changelist page when any field is list_editable

2015-12-11 Thread Django

#25919: Wrong behavior after saving on changelist page when any field is
list_editable
-+-
 Reporter:  c0ntribut0r  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  list_editable| Triage Stage:
  pagination cl.result_list  |  Unreviewed
  queryset   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by c0ntribut0r):

 * keywords:   => list_editable pagination cl.result_list queryset
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 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/069.72e9672ec51649a0393234c9276c8273%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25919: Wrong behavior after saving on changelist page when any field is list_editable

2015-12-11 Thread Django

#25919: Wrong behavior after saving on changelist page when any field is
list_editable
---+
 Reporter:  c0ntribut0r|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by c0ntribut0r):

 * Attachment "project.tar.gz" added.

 Sample project for quick testing (sqlite)

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

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

Re: [Django] #24475: Add a new testconnections management command

2015-12-11 Thread Django

#24475: Add a new testconnections management command
-+-
 Reporter:  gannetson|Owner:
 |  alexmorozov
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 One advantage of the the checks framework is that it makes it easy for
 users to register new checks if they want to check parts of their
 infrastructure that Django core doesn't know about.

 I don't know the answer to your second question. I have thought that it
 might be better to start this as a third-party project to allow it to
 iterate more quickly, see if it gains any traction and if so, how exactly
 users end up using it.

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

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

Re: [Django] #25919: Wrong behavior after saving on changelist page when any field is list_editable

2015-12-11 Thread Django

#25919: Wrong behavior after saving on changelist page when any field is
list_editable
---+
 Reporter:  c0ntribut0r|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by c0ntribut0r):

 * Attachment "diff.txt" added.


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

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

[Django] #25919: Wrong behavior after saving on changelist page when any field is list_editable

2015-12-11 Thread Django

#25919: Wrong behavior after saving on changelist page when any field is
list_editable
---+
 Reporter:  c0ntribut0r|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 Assume there is a simple model
 {{{
 class SomeModel(models.Model):
 name = models.CharField('name', max_length=64)
 }}}
 and simple admin for it (note 2 items per page and in-line editable field
 "name")
 {{{
 @admin.register(SomeModel)
 class SomeModelAdmin(admin.ModelAdmin):
 list_display = ['id' ,'name']
 list_editable = ['name']
 list_per_page = 2
 }}}
 Go to admin page and create two instances of SomeModel with names, say,
 "alpha" and "beta". Then, open the same admin page
 ({{{/admin/testapp/somemodel/}}}) in another browser tab and create
 another instance ("gamma"). Return to the first tab (it's of course
 unchanged and there still remain "alpha" and "beta" instances) and change
 in-line field "name" from "alpha" to "lambda" and press "save". Then press
 "show all" and you'll see that you haven't changed "alpha" to "lambda" -
 you created new instance "lambda", and "alpha" also remains there!

 The source of this bug is in {{{ django/contrib/admin/options.py }}}:
 {{{
 # Handle POSTed bulk-edit data.
 if (request.method == "POST" and cl.list_editable and
 '_save' in request.POST and not action_failed):
 FormSet = self.get_changelist_formset(request)
 formset = cl.formset = FormSet(request.POST, request.FILES,
 queryset=cl.result_list)
 }}}
 When user clicks "save", the page sends correct POST data like this:
 {{{
 "form-0-id" = "0",
 "form-0-name" = "beta",
 "form-1-id" = "1",
 "form-1-name" = "lambda"  <-- was "alpha" before
 }}}
 But there is code ({{{ queryset=cl.result_list }}}) which restricts form's
 instances to those that are on current admin page ({{{
 /admin/testapp/somemodel/ }}}). As you remember, we have 3 instances -
 "alpha", "beta", "gamma", and according to {{{ list_per_page = 2 }}} only
 last two instances are shown - these are "beta" and "gamma".

 When the form's POST data ("beta", "alpha -> lambda") fits instances from
 queryset ("beta", "gamma"), it finds "beta" and changes it without errors,
 but it cannot find "alpha" and change it - so it thinks that we added new
 record and creates an instance with value "lambda". This is not a desired
 behavior.

 Removing the queryset restriction solves this problem. I am wondering
 whether that queryset was there at all.

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

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

Re: [Django] #25918: Remove unused LOGOUT_URL setting (was: `LOGOUT_URL` is no longer used anywhere in Django)

2015-12-11 Thread Django

#25918: Remove unused LOGOUT_URL setting
--+
 Reporter:  hop   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.9 => master
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Looks fine to remove, but should be noted in the release notes as a
 backwards-incompatible change.

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

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

Re: [Django] #25903: ModelAdmin popups won't close

2015-12-11 Thread Django

#25903: ModelAdmin popups won't close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by timgraham):

 Could you please be more specific with a sample project and/or steps to
 reproduce?

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

[Django] #25918: `LOGOUT_URL` is no longer used anywhere in Django

2015-12-11 Thread Django

#25918: `LOGOUT_URL` is no longer used anywhere in Django
---+
 Reporter:  hop|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The only code ever using it has been removed with changeset:cba9199.

 Some people also seem to confuse it with `LOGOUT_REDIRECT_URL` (which
 doesn't exist): http://stackoverflow.com/questions/11933361/django-logout-
 url-doesnt-redirect-well

 The setting should probably be removed entirely?

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

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

Re: [Django] #25899: manage.py tests requires database creation privileges

2015-12-11 Thread Django

#25899: manage.py tests requires database creation privileges
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


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

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

Re: [Django] #25899: manage.py tests requires database creation privileges

2015-12-11 Thread Django

#25899: manage.py tests requires database creation privileges
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"738bda8a6feea95d07b73246365e75b3d25e3466" 738bda8]:
 {{{
 #!CommitTicketReference repository=""
 revision="738bda8a6feea95d07b73246365e75b3d25e3466"
 Refs #25899 -- Improved visibility of TEST database settings in testing
 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/071.f685c71cfde89a413ba55a05c6e88da8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25899: manage.py tests requires database creation privileges

2015-12-11 Thread Django

#25899: manage.py tests requires database creation privileges
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"9f3ce6d987f2a78dc97f6147efac41071c2ec085" 9f3ce6d9]:
 {{{
 #!CommitTicketReference repository=""
 revision="9f3ce6d987f2a78dc97f6147efac41071c2ec085"
 [1.9.x] Refs #25899 -- Improved visibility of TEST database settings in
 testing docs.

 Backport of 738bda8a6feea95d07b73246365e75b3d25e3466 from master
 }}}

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

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

Re: [Django] #25903: ModelAdmin popups won't close

2015-12-11 Thread Django

#25903: ModelAdmin popups won't close
--+--
 Reporter:  Crzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  modeladmin popup  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by muffinmad):

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


Comment:

 Same here without those apps. Function {{{ showAdminPopup}}} is called
 from {{{ change_form.html}}} template but not from {{{
 change_list.html}}}. So from change_form popup is opened correctly, but in
 change_list it's just a link without js events.

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

Re: [Django] #25917: Confusing sentence in RemoveField's documentation

2015-12-11 Thread Django

#25917: Confusing sentence in RemoveField's documentation
-+-
 Reporter:  bmispelon|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by bmispelon):

 If the field is not nullable, is there a case where the reverse of
 `RemoveField` would not fail? If not, the use of "may" is confusing.


 As for the question about `default`, that's a good point. I haven't tried
 and it could make the reverse operation "work" in the sense that Django
 would be able to get back to a valid state but there's no guarantee that
 your data would be preserved (any non-default values for that column would
 be gone).

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

Re: [Django] #25917: Confusing sentence in RemoveField's documentation

2015-12-11 Thread Django

#25917: Confusing sentence in RemoveField's documentation
-+-
 Reporter:  bmispelon|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by rfleschenberg):

 As I understand it, the sentence means this: if the field is not nullable,
 the reverse of RemoveField (adding a field) may fail, because Django does
 not know which data to add for existing rows.

 Apart from that, the forward operation (removing the field) is of course
 never reversible in so far as it deletes the data in the field.

 Question: would RemoveField be reversible if the field has a default
 value?

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

[Django] #25917: Confusing sentence in RemoveField's documentation

2015-12-11 Thread Django

#25917: Confusing sentence in RemoveField's documentation
+
   Reporter:  bmispelon |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  1.9
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 The documentation for `RemoveField` [1] states that:

 > if the field is not nullable this may make this operation irreversible
 (apart from any data loss, which of course is irreversible)


 I find this sentence confusing.
 The note in parentheses implies opposition with the previous statement
 when it's in fact saying the same thing: the operation is irreversible.

 [1] https://docs.djangoproject.com/en/dev/ref/migration-
 operations/#django.db.migrations.operations.RemoveField

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

Re: [Django] #24475: Add a new testconnections management command

2015-12-11 Thread Django

#24475: Add a new testconnections management command
-+-
 Reporter:  gannetson|Owner:
 |  alexmorozov
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by shaib):

 What do we gain by folding it into the system checks framework? How is
 that better than a separate command?

 Also, is this intended mostly for "local" connections (mail, database,
 job-queue broker) or are "remote" connections (OAuth providers, other
 APIs) also on the plate?

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

Re: [Django] #25899: manage.py tests requires database creation privileges

2015-12-11 Thread Django

#25899: manage.py tests requires database creation privileges
---+--
 Reporter:  JorisBenschop  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by JorisBenschop):

 Apologies, I should have read more thoroughly. I will use the pointers
 given. Thanks for the docs improvement also. I guess this ticket can be
 resolved-fixed-closed?

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

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

51 matches

Mail list logo