date:20130612

Re: [Django] #20589: contrib.auth.handlers.modwsgi fails for some backends

2013-06-12 Thread Django

#20589: contrib.auth.handlers.modwsgi fails for some backends
---+
 Reporter:  graham4django  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.auth   |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords:  handlers, modwsgi  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by grahamd):

 Returning None allows Apache to try a different authentication provider if
 more than one was setup in Apache. The question is whether when using
 Django for authentication that people would even want to do that or
 whether one views Django as the only authoritative source.

-- 
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.f816c277f8d9d862c3870352e8d89e61%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19031: Add a warning that @override_settings may not work with DATABASES and CACHES (was: Using @override_settings doesn't override DATABASES in threads +SQLite)

2013-06-12 Thread Django

#19031: Add a warning that @override_settings may not work with DATABASES and
CACHES
---+
 Reporter:  jonash |Owner:  joeri
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+
Changes (by timo):

 * cc: timograham@… (added)
 * needs_better_patch:  0 => 1
 * type:  Bug => New feature


Comment:

 Left some comments on the 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/064.52cc3d405f4642bc93c5d8bf282d0f37%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20594: models.SlugField doesn't validate against slug_re

2013-06-12 Thread Django

#20594: models.SlugField doesn't validate against slug_re
--+
 Reporter:  carbonXT  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 This appears to be a bug to me:

 {{{
 from django.db import models

 class MyModel(models.Model):
 slug = models.SlugField()

 mymodel = MyModel(slug='this is an invalid % $ ## slug')
 mymodel.full_clean() # it'd expect this to raise a validation error... it
 does not.
 }}}

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

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

Re: [Django] #20593: Disagreement between User.set_password("") and User.check_password("")

2013-06-12 Thread Django

Comment (by wim@…):

In my opinion, set_password("") should raise an exception.

Rationale: passwords are used to identify users. Allowing them to have
empty passwords is unsafe; and if you want people to be able to enter a
website without having a password then use a different authentication
backend which does not check for an empty password.

In practice, all django authentication forms require the password field to
be filled, and people have to enter characters for the form to be valid,
otherwise the form raises an error.

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

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

Re: [Django] #6903: Go back to old change_list view after hitting save

2013-06-12 Thread Django

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:  oinopion
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by oinopion):

 * needs_docs:  1 => 0


Comment:

 I'm not really sure what kind of documentation this would need: Functional
 details of admin are not documented. Release notes might be a good place,
 but should I put it in 1.6?

-- 
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.8361a12af60e60b88f5e23392f393f8f%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6903: Go back to old change_list view after hitting save

2013-06-12 Thread Django

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:  oinopion
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by oinopion):

 * needs_better_patch:  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/064.be368a1f8f52d5dba86fde87e526d1a1%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6903: Go back to old change_list view after hitting save

2013-06-12 Thread Django

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:  oinopion
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+

Comment (by oinopion):

 I've submitted [https://github.com/django/django/pull/1264 pull request]
 from previous ticket with some small corrections.

-- 
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.04bb6eebe245d56e6aa314b3590f707a%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20593: Disagreement between User.set_password("") and User.check_password("")

2013-06-12 Thread Django

#20593: Disagreement between User.set_password("") and User.check_password("")
+
 Reporter:  jonaskoelker|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.auth|  Version:  1.4
 Severity:  Normal  |   Resolution:
 Keywords:  blank password  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by bmispelon):

 * cc: bmispelon@… (added)
 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 The backwards-incompatible change was made in commit
 90e05aaeac612a4251640564aa65f103ac635e12 (which, as you noted, landed in
 1.4).
 There is no reference to a ticket nor is there a note in the release notes
 so I'm not sure the change was intentional.

 I'm accepting this on the basis that this backwards-incompatible change
 should at least be documented, if not even reverted.

 Thanks for the thorough report.

-- 
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.73e128422e31d61dcbc7fe748e917ca2%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20537: `request_finished` signal not being called with Django 1.5 and uWSGI < 1.2.6(?)

2013-06-12 Thread Django

#20537: `request_finished` signal not being called with Django 1.5 and uWSGI <
1.2.6(?)
-+-
 Reporter:  jaap3|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  uwsgi postgres   | Triage Stage:  Ready for
  mysql idle connections |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"60353458ae7105ea943dc425954403c581b05255"]:
 {{{
 #!CommitTicketReference repository=""
 revision="60353458ae7105ea943dc425954403c581b05255"
 [1.5.x] Warned that `request_finished` isn't sent by some buggy setups.

 Older versions of uWSGI and Sentry's middleware do not adhere to
 the WSGI spec and cause the `request_finished` signal to never
 fire. Added notes to the appropriate places in the docs.

 Fixed #20537.

 Backport of 3ce1d30.

 Conflicts:
 docs/howto/deployment/wsgi/index.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/063.73db9f7bfae6b661a99dad142882add8%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 603534: [1.5.x] Warned that `request_finished` isn't sent ...

2013-06-12 Thread GitHub

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 60353458ae7105ea943dc425954403c581b05255
  
https://github.com/django/django/commit/60353458ae7105ea943dc425954403c581b05255
  Author: Jaap Roes 
  Date:   2013-06-12 (Wed, 12 Jun 2013)

  Changed paths:
M docs/howto/deployment/wsgi/index.txt
M docs/howto/deployment/wsgi/uwsgi.txt
M docs/ref/signals.txt
M docs/releases/1.5.txt

  Log Message:
  ---
  [1.5.x] Warned that `request_finished` isn't sent by some buggy setups.

Older versions of uWSGI and Sentry's middleware do not adhere to
the WSGI spec and cause the `request_finished` signal to never
fire. Added notes to the appropriate places in the docs.

Fixed #20537.

Backport of 3ce1d30.

Conflicts:
docs/howto/deployment/wsgi/index.txt



-- 
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/51b8c4c676962_7924c91ddc705a2%40hookshot-fe1-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20537: `request_finished` signal not being called with Django 1.5 and uWSGI < 1.2.6(?)

2013-06-12 Thread Django

#20537: `request_finished` signal not being called with Django 1.5 and uWSGI <
1.2.6(?)
-+-
 Reporter:  jaap3|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  uwsgi postgres   | Triage Stage:  Ready for
  mysql idle connections |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"3ce1d303daa92ecb1bc3ba6344f1ec9746a79c70"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3ce1d303daa92ecb1bc3ba6344f1ec9746a79c70"
 Warned that `request_finished` isn't sent by some buggy setups.

 Older versions of uWSGI and Sentry's middleware do not adhere to
 the WSGI spec and cause the `request_finished` signal to never
 fire. Added notes to the appropriate places in the docs.

 Fixed #20537.
 }}}

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

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

[django/django] 3ce1d3: Warned that `request_finished` isn't sent by some ...

2013-06-12 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3ce1d303daa92ecb1bc3ba6344f1ec9746a79c70
  
https://github.com/django/django/commit/3ce1d303daa92ecb1bc3ba6344f1ec9746a79c70
  Author: Jaap Roes 
  Date:   2013-06-12 (Wed, 12 Jun 2013)

  Changed paths:
M docs/howto/deployment/wsgi/index.txt
M docs/howto/deployment/wsgi/uwsgi.txt
M docs/ref/signals.txt
M docs/releases/1.5.txt

  Log Message:
  ---
  Warned that `request_finished` isn't sent by some buggy setups.

Older versions of uWSGI and Sentry's middleware do not adhere to
the WSGI spec and cause the `request_finished` signal to never
fire. Added notes to the appropriate places in the docs.

Fixed #20537.



-- 
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/51b8c362a8b47_ffb12b5de41110e1%40hookshot-fe2-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20537: `request_finished` signal not being called with Django 1.5 and uWSGI < 1.2.6(?)

2013-06-12 Thread Django

#20537: `request_finished` signal not being called with Django 1.5 and uWSGI <
1.2.6(?)
-+-
 Reporter:  jaap3|Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  uwsgi postgres   | Triage Stage:  Ready for
  mysql idle connections |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by aaugustin):

 PR looks good, thank you, I'll push it (with negligible edits).

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

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

Re: [Django] #20579: Define the expected state of the database between test cases

2013-06-12 Thread Django

#20579: Define the expected state of the database between test cases
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"55cbd65985bfad02512a64a4cb8468140f15ee84"]:
 {{{
 #!CommitTicketReference repository=""
 revision="55cbd65985bfad02512a64a4cb8468140f15ee84"
 Fixed #20579 -- Improved TransactionTestCase.available_apps.

 Also moved its documentation to the 'advanced' section. It doesn't
 belong to the 'overview'. Same for TransactionTestCase.reset_sequences.

 When available_apps is set, after a TransactionTestCase, the database
 is now totally empty. post_syncdb is fired at the beginning of the next
 TransactionTestCase.

 Refs #20483.
 }}}

-- 
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.577aaeb0d0a4208538e882f7a9936a19%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20483: Reduce the set of apps seen by individual tests

2013-06-12 Thread Django

Comment (by Aymeric Augustin ):

In [changeset:"55cbd65985bfad02512a64a4cb8468140f15ee84"]:
{{{
#!CommitTicketReference repository=""
revision="55cbd65985bfad02512a64a4cb8468140f15ee84"
Fixed #20579 -- Improved TransactionTestCase.available_apps.

Also moved its documentation to the 'advanced' section. It doesn't
belong to the 'overview'. Same for TransactionTestCase.reset_sequences.

When available_apps is set, after a TransactionTestCase, the database
is now totally empty. post_syncdb is fired at the beginning of the next
TransactionTestCase.

Refs #20483.
}}}

--
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.c8ad77a0f6f4b5cfd3514fc543240ae4%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 55cbd6: Fixed #20579 -- Improved TransactionTestCase.avail...

2013-06-12 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 55cbd65985bfad02512a64a4cb8468140f15ee84
  
https://github.com/django/django/commit/55cbd65985bfad02512a64a4cb8468140f15ee84
  Author: Aymeric Augustin 
  Date:   2013-06-12 (Wed, 12 Jun 2013)

  Changed paths:
M django/core/management/commands/flush.py
M django/test/testcases.py
M docs/topics/testing/advanced.txt
M docs/topics/testing/overview.txt

  Log Message:
  ---
  Fixed #20579 -- Improved TransactionTestCase.available_apps.

Also moved its documentation to the 'advanced' section. It doesn't
belong to the 'overview'. Same for TransactionTestCase.reset_sequences.

When available_apps is set, after a TransactionTestCase, the database
is now totally empty. post_syncdb is fired at the beginning of the next
TransactionTestCase.

Refs #20483.



-- 
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/51b8be0081089_7955959de0923d3%40hookshot-fe1-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20537: `request_finished` signal not being called with Django 1.5 and uWSGI < 1.2.6(?)

2013-06-12 Thread Django

#20537: `request_finished` signal not being called with Django 1.5 and uWSGI <
1.2.6(?)
-+-
 Reporter:  jaap3|Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  uwsgi postgres   | Triage Stage:  Ready for
  mysql idle connections |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timo):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks good to me, left one comment on the pull request. I'll let Aymeric
 review it as well.

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

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

[django/django] b79aa7: FormSet.forms is an iterable, so just iterate over...

2013-06-12 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b79aa796d8fe0d28778605b6b294e3e3a3f9ca65
  
https://github.com/django/django/commit/b79aa796d8fe0d28778605b6b294e3e3a3f9ca65
  Author: Wilfred Hughes 
  Date:   2013-06-11 (Tue, 11 Jun 2013)

  Changed paths:
M docs/topics/forms/formsets.txt

  Log Message:
  ---
  FormSet.forms is an iterable, so just iterate over it


  Commit: 0938970491eee41ccde11bf3efe5b307ced8dba6
  
https://github.com/django/django/commit/0938970491eee41ccde11bf3efe5b307ced8dba6
  Author: Tim Graham 
  Date:   2013-06-12 (Wed, 12 Jun 2013)

  Changed paths:
M docs/topics/forms/formsets.txt

  Log Message:
  ---
  Merge pull request #1259 from Wilfred/master

Simplified a formset example in the docs


Compare: https://github.com/django/django/compare/6e90bfde8813...0938970491ee

-- 
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/51b8acae42c9b_7955959de084228%40hookshot-fe1-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20592: Improve the 'Write a 404 (page not found) view' section in the tutorial

2013-06-12 Thread Django

#20592: Improve the 'Write a 404 (page not found) view' section in the tutorial
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  1.5
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  404, tutorial,   | Triage Stage:
  allowed_hosts  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 A warning about that was recently added, see #19875.

-- 
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.5249e7d0742e0578bdb60aede8672eac%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20577: Make prefetch_related faster by lazily creating related querysets

2013-06-12 Thread Django

#20577: Make prefetch_related faster by lazily creating related querysets
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by lukeplant):

 Nice work!

 I'm wondering if there is some overlap with `_sticky_filter` (or if that
 could be implemented using `chain_ops`).

-- 
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.5a00cc1d6a2b653de5a9eb38ceaf420e%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20577: Make prefetch_related faster by lazily creating related querysets

2013-06-12 Thread Django

#20577: Make prefetch_related faster by lazily creating related querysets
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I implemented a branch where it is possible to chain operations. The
 operations are executed on next queryset access. See
 https://github.com/akaariai/django/tree/chain_ops. The branch isn't meant
 to be committable, and it fails a couple of tests (one reason might be
 that cloning does a bit more than just clone(), so when chaining ops
 without clone things will break).

 The basic idea is to add a new QuerySet method chain_ops(). The usage is
 simple: qs.chain_ops(lambda qs:
 qs.filter(foo=bar).using(baz).order_by(xyzzy)). The chain_ops() method
 will *not* clone the queryset. The operations in the lambda function are
 executed when needed, that is on queryset evaluation, accessing qs.query,
 or cloning the queryset. When the operations in the lambda function are
 executed, the queryset isn't cloned in between.

 The result of this is 2.3x speedup in
 
[https://github.com/django/djangobench/blob/master/djangobench/benchmarks/query_prefetch_related/benchmark.py
 query_prefetch_related djangobench benchmark].

-- 
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.3322610c288096baa3af62ad86c29820%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20569: Add cleaned_form to supersede cleaned_data

2013-06-12 Thread Django

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

Comment:

This would introduce massive backwards incompatibility, due to the
ambiguity of this in a template:

{{{
form.subject
}}}

This currently becomes `form['subject']` and accesses the bound field, but
with this change that would be shadowed by the attribute.

This is just asking for trouble, and an additional method to swap things
back is going to make things even more complicated and error prone.
Overall I think this is a worse API, especially once you've taken
templates into account, but either way the cost of the change far
outweighs any benefits from making it.

Therefore closing INVALID.

--
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.aa49239cf056004b9791c7a60ea4abf8%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20292: Django 1.5.1: ORA-01843: not a valid month

2013-06-12 Thread Django

#20292: Django 1.5.1: ORA-01843: not a valid month
-+-
 Reporter:  CarstenF |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  Oracle, cx_oracle,   |  Needs documentation:  0
  unicode|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by mal):

 I confirm that the error with Django 1.5.1, Oracle Database 10g Release
 10.2.0.5.0 - 64bit Production and cx_Oracle 5.1.2.
 Same combination works fine with 11g.

 Oracle 10g is still very popular and sometimes its just not possible to
 upgrade to 11g.

-- 
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.84542ad7bd0f5037140b3168a44aa75b%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20593: Disagreement between User.set_password("") and User.check_password("")

2013-06-12 Thread Django

#20593: Disagreement between User.set_password("") and User.check_password("")
--+
Reporter: jonaskoelker | Owner: nobody
Type: Bug | Status: new
Component: contrib.auth |Version: 1.4
Severity: Normal| Keywords: blank password
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 1 | UI/UX: 0
--+
At https://docs.djangoproject.com/en/1.4/topics/auth/, under
`set_unusable_password`, it says "Marks the user as having no password
set. This isn’t the same as having a blank string for a password", which
suggests that the latter is possible. Also, `set_password` doesn't say
anything about blank passwords not being allowed. Yet, when I run
{{{
user.set_password(form.cleaned_data['new0'])
assert user.check_password(form.cleaned_data['new1'])
}}}

with both new passwords being empty, I get an assertion failure.
According to at least two core developers*, allowing a blank password is
not a bug---which would indicate that `set_password` does the wrong thing.

(*)
one: https://code.djangoproject.com/ticket/4170
two: https://code.djangoproject.com/ticket/14354 plus
https://groups.google.com/forum/#!msg/django-developers/NtpFFdYh-
3g/erB1Qhd6m2UJ

Looking at hashers.py, I see
{{{
def make_password(password, salt=None, hasher='default'):
"""[... If password is None or blank then UNUSABLE_PASSWORD will be
returned ...]"""
if not password:
return UNUSABLE_PASSWORD
}}}

That looks rather deliberate. If that's so I think the documentation
should be updated, reflecting the fact that `User.set_password("")` does
something rather anti-intuitive, and that there even more anti-intuitively
exists a string `s` such that if you do `set_password(s)`, then
`check_password(s)` fails.

Also, I think '''silently''' forbidding blank passwords is really bad. If
`set_password` were to throw a `ValueError` with an explanation of why you
rather than I should decide whether to allow blank passwords, I would
dislike it but at least its anti-intuitiveness would be '''explicit'''.

As things are at present, given the silent transition (or did I look in
all the wrong places for the deprecation warnings?) users of Django
applications could lock themselves out when they intend to have a blank
password---the 180 degrees opposite effect of what they want.

I've set version=1.4 on this ticket, because that's the one I use in my
production environment, i.e. the one where I have exhibited this behavior.
Version 1.3 did something different, see
https://github.com/django/django/blob/1.3/django/contrib/auth/models.py#L251

I've set easy=true, because I think the fix is a one-line patch and a
four-line addition to/of a test case---which I'll be happy to write---or
some documentation rewriting (which I'll leave to someone else). I think
the best next step is for the group of core devs to agree on what the
right thing for `set_password("")` to do is, then add that information to
this ticket.

--
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.33c6634f644faaafbb3067c7bfef5608%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20592: Improve the 'Write a 404 (page not found) view' section in the tutorial

2013-06-12 Thread Django

#20592: Improve the 'Write a 404 (page not found) view' section in the tutorial
---+--
Reporter: anonymous | Owner: nobody
Type: Uncategorized | Status: new
Component: Documentation |Version: 1.5
Severity: Normal | Keywords: 404, tutorial, allowed_hosts
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+--
Hi.

I'm a django begginer, and when I was reading the 3rd part of your
tutorial, I saw myself in some troubles when I tried to do what you said
in the 'Write a 404 (page not found) view' section. As you said, I changed
the 'DEBUG' value to False. But that is not enough, you also have to set
the 'ALLOWED_HOSTS' variable after that change.

I consider that you should say that in the tutorial, because I tried
everything without changing that value, and obviously it didn't work.

Thanks for your attention, I hope that this helped.

--
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.7ea6ecc6e658e624b91dea3ed03c0e83%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20592: Improve the 'Write a 404 (page not found) view' section in the tutorial

2013-06-12 Thread Django

#20592: Improve the 'Write a 404 (page not found) view' section in the tutorial
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  404, tutorial,   | Triage Stage:
  allowed_hosts  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * 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.0385d276e0c1e3fbbc6a5b7ba2123b38%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20591: Documentation for django.utils.module_loading.import_by_path does not indicate Django version it was added in

2013-06-12 Thread Django

#20591: Documentation for django.utils.module_loading.import_by_path does not
indicate Django version it was added in
-+-
 Reporter:  micolous |Owner:  batisteo
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Marc Tamlyn ):

 In [changeset:"6e90bfde88136504915533a4f47d5ac043b62a76"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6e90bfde88136504915533a4f47d5ac043b62a76"
 Merge pull request #1262 from batisteo/ticket-20591

 Fixed #20591: added version in docs for
 utils.module_loading.import_by_path
 }}}

-- 
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.d5d3326b47776972148e3555fd407470%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 8821bc: Fixed #20591: added version in docs for utils.modu...

2013-06-12 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 8821bcb2a0b4d9a049a5b645afa5080b640928e2
  
https://github.com/django/django/commit/8821bcb2a0b4d9a049a5b645afa5080b640928e2
  Author: Baptiste Darthenay 
  Date:   2013-06-12 (Wed, 12 Jun 2013)

  Changed paths:
M docs/ref/utils.txt

  Log Message:
  ---
  Fixed #20591: added version in docs for utils.module_loading.import_by_path.


  Commit: 6e90bfde88136504915533a4f47d5ac043b62a76
  
https://github.com/django/django/commit/6e90bfde88136504915533a4f47d5ac043b62a76
  Author: Marc Tamlyn 
  Date:   2013-06-12 (Wed, 12 Jun 2013)

  Changed paths:
M docs/ref/utils.txt

  Log Message:
  ---
  Merge pull request #1262 from batisteo/ticket-20591

Fixed #20591: added version in docs for utils.module_loading.import_by_path


Compare: https://github.com/django/django/compare/92c49d6f0170...6e90bfde8813

-- 
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/51b83c3070d62_51c01283de4297e3%40hookshot-fe3-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20591: Documentation for django.utils.module_loading.import_by_path does not indicate Django version it was added in

2013-06-12 Thread Django

#20591: Documentation for django.utils.module_loading.import_by_path does not
indicate Django version it was added in
-+-
 Reporter:  micolous |Owner:  batisteo
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Baptiste Darthenay ):

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


Comment:

 In [changeset:"8821bcb2a0b4d9a049a5b645afa5080b640928e2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8821bcb2a0b4d9a049a5b645afa5080b640928e2"
 Fixed #20591: added version in docs for
 utils.module_loading.import_by_path.
 }}}

-- 
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.7ccd893c56c98948f978b4cbd011d997%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20591: Documentation for django.utils.module_loading.import_by_path does not indicate Django version it was added in

2013-06-12 Thread Django

#20591: Documentation for django.utils.module_loading.import_by_path does not
indicate Django version it was added in
-+-
 Reporter:  micolous |Owner:  batisteo
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by bmispelon):

 * stage:  Unreviewed => Ready for checkin


Comment:

 Looks good.

-- 
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.2a6e9cbb9200d7f57443ac0f95ff482a%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20591: Documentation for django.utils.module_loading.import_by_path does not indicate Django version it was added in

2013-06-12 Thread Django

#20591: Documentation for django.utils.module_loading.import_by_path does not
indicate Django version it was added in
---+--
 Reporter:  micolous   |Owner:  batisteo
 Type:  Bug|   Status:  assigned
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 batisteo):

 * has_patch:  0 => 1


Comment:

 Pull request here: https://github.com/django/django/pull/1262

-- 
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.8fa1c3e7a777f13b65abb56b0c68b732%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20591: Documentation for django.utils.module_loading.import_by_path does not indicate Django version it was added in

2013-06-12 Thread Django

#20591: Documentation for django.utils.module_loading.import_by_path does not
indicate Django version it was added in
---+--
 Reporter:  micolous   |Owner:  batisteo
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  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
---+--
Changes (by batisteo):

 * status:  new => assigned
 * cc: batisteo (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => batisteo
 * 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/066.29cb07e5cedabf6ccfb35b836526d007%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20589: contrib.auth.handlers.modwsgi fails for some backends

2013-06-12 Thread Django

#20589: contrib.auth.handlers.modwsgi fails for some backends
---+
 Reporter:  graham4django  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.auth   |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords:  handlers, modwsgi  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by bmispelon):

 * cc: bmispelon@… (added)


Comment:

 One issue (and probably the reason why `check_password` is implemented
 that way) is that, according to the mod_wsgi documentation [1], the
 handler function should return `None`, `True`, or `False` depending on
 whether the user exists in the database and whether the provided password
 is correct or not (respectively).

 With `authenticate`, we either get a user object or `None` which means we
 can't distinguish between a non-existing user and a bad password.

 I'm not sure how much of a problem it'd be to return `None` instead of
 `False` in case of an invalid password but it might break backwards-
 compatibility so we should tread carefully.

 [1]
 
http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms#Apache_Authentication_Provider

-- 
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.5d26f1b53cb0fd92aad63001cb66d31e%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20590: Documentation of "test execution order" in 1.6

2013-06-12 Thread Django

#20590: Documentation of "test execution order" in 1.6
-+
 Reporter:  apollo13 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  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
-+

Comment (by aaugustin):

 There's a small perversity here, it isn't the same `TestCase` in the two
 classes:
 - in the old (deprecated) runner, `TestCase` is `unittest.TestCase` (it's
 explicitly spelled like that).
 - in the new runner, `TestCase` is `from django.test import TestCase`.

-- 
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.f9a56790c7f4084d88c07c0b1ac32166%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20589: contrib.auth.handlers.modwsgi fails for some backends

2013-06-12 Thread Django

#20589: contrib.auth.handlers.modwsgi fails for some backends
---+
 Reporter:  graham4django  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.auth   |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords:  handlers, modwsgi  | 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):

 * needs_docs:   => 0
 * needs_better_patch:   => 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/071.0d5ed5d7843effd78df53e394edf25a6%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20591: Documentation for django.utils.module_loading.import_by_path does not indicate Django version it was added in

2013-06-12 Thread Django

#20591: Documentation for django.utils.module_loading.import_by_path does not
indicate Django version it was added in
---+
 Reporter:  micolous   |  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
---+
 Documentation for import_by_path was added in #19748:

 
https://docs.djangoproject.com/en/dev/ref/utils/#django.utils.module_loading.import_by_path

 However this documentation doesn't indicate which Django version it was
 added in (1.6).

 I was scratching my head for a bit why this function wasn't working in
 Django 1.5.

-- 
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.23c40cf86756631e4e03643eef6e9bf0%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20579: Define the expected state of the database between test cases

2013-06-12 Thread Django

Comment (by aaugustin):

This proposal for test case reordering still assumes that all
TransactionTestCase define available_apps. I'm not sure we can provide a
generic solution, and the current code (hack?) looks good enough for
Django's own test suite.

Indeed, our problem is that we want to express "between X and X" in terms
of "before X" and "after X", and we don't have enough context to optimize
things. One possibility would be to add a global variable to track
information about the state of the database, so the next test case could
know what the previous did. Still, as long as we try to maintain strict
backwards compatibility, there's no silver bullet.

--
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.559a6e1c5bbe8803147d5c8f494c12e8%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

37 matches

Mail list logo