Re: [Django] #16101: SingleObjectMixin should accept parameters for overriding the URL keywords for pk and slug

[Django]

#16101: SingleObjectMixin should accept parameters for overriding the URL 
keywords
for pk and slug
+---
   Reporter:  AndrewIngram  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Milestone:|  Component:  Generic views
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---

Comment (by julien):

 Thanks for the patch! I've slightly tweaked the doc, added release notes
 and removed the `get_slug_url_kwarg()` and `get_pk_url_kwarg()` as those
 complicated things and didn't add real value. I'll just seek for external
 opinion on the naming ("pk_url_kwarg" and "slug_url_kwarg") before RFC'ing
 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16134: django.db.models.fields.Field instance can not be compared with None

[Django]

#16134: django.db.models.fields.Field instance can not be compared with None
---+--
 Reporter:  amcharg@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Database layer (models, ORM)
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
---+--
 Instances of django.db.models.fields.Field can not be compared with None.
 Eg: field == None

 Repro: Compare a field instance with None. This fails since __cmp__
 assumes the other operand is a field instance and __eq__ and __ne__ are
 not defined.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16101: SingleObjectMixin should accept parameters for overriding the URL keywords for pk and slug

[Django]

#16101: SingleObjectMixin should accept parameters for overriding the URL 
keywords
for pk and slug
+---
   Reporter:  AndrewIngram  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Milestone:|  Component:  Generic views
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---
Changes (by AndrewIngram):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15878: Bad Link In Module Index

[Django]

#15878: Bad Link In Module Index
-+---
   Reporter:  Shane@…|  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+---
Changes (by julien):

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


Comment:

 Closing as dupe of #16133 which identifies the root cause and has a fix.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15064: DJANGO_SETTINGS_MODULE doesn't work with runserver

[Django]

#15064: DJANGO_SETTINGS_MODULE doesn't work with runserver
-+-
   Reporter:  olau   |  Owner:  ShawnMilo
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Management
Version:  1.3|  commands)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-

Comment (by lsaffre):

 Okay, I hadn't read this page for quite some time now, and I agree that
 they are clear. So I was using an undocumented feature. I now simply
 modified my local manage.py files so I can continue the old way:
 {{{
   import os
   os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15880: manage.py: difficult to run in background (and crashes when input isn't a terminal)

[Django]

#15880: manage.py: difficult to run in background (and crashes when input isn't 
a
terminal)
-+-
   Reporter: |  Owner:  nobody
  dstndstn@… | Status:  closed
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Release blocker
 Resolution:  needsinfo  |   Keywords:  regression
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by anonymous):

 Oh, but it now appears that piping /dev/null to stdin no longer causes a
 crash!

 {{{
 $ python manage.py runserver < /dev/null &
 ### starts up
 $ touch settings.py
 ### successfully reloads
 }}}

 and this works:

 {{{
 $ python manage.py runserver < /dev/null > man.log &
 }}}

 Thank-you!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16306 - django/trunk/docs/releases

[noreply]

Author: lukeplant
Date: 2011-05-31 14:29:35 -0700 (Tue, 31 May 2011)
New Revision: 16306

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Added info to release notes about CSRF improvements

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-05-31 15:43:19 UTC (rev 16305)
+++ django/trunk/docs/releases/1.4.txt  2011-05-31 21:29:35 UTC (rev 16306)
@@ -78,6 +78,16 @@
 ``template.Library`` to ease the creation of template tags that store some
 data in a specified context variable.
 
+CSRF improvements
+~
+
+We've made various improvements to our CSRF features, including the
+:func:`~django.views.decorators.csrf.ensure_csrf_cookie` decorator which can
+help with AJAX heavy sites, protection for PUT and DELETE, and settings
+:setting:`CSRF_COOKIE_SECURE` and :setting:`CSRF_COOKIE_PATH` which can improve
+the security and usefulness of the CSRF protection. See the :doc:`CSRF docs
+` for more information.
+
 .. _backwards-incompatible-changes-1.4:
 
 Backwards incompatible changes in 1.4

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15995: Problems in ModelForm._post_clean

[Django]

#15995: Problems in ModelForm._post_clean
+
   Reporter:  apollo13  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Forms
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 The idea makes sense. It would make the form validation slightly more
 tolerant, but that's not significantly backwards incompatible.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15880: manage.py: difficult to run in background (and crashes when input isn't a terminal)

[Django]

#15880: manage.py: difficult to run in background (and crashes when input isn't 
a
terminal)
-+-
   Reporter: |  Owner:  nobody
  dstndstn@… | Status:  closed
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Release blocker
 Resolution:  needsinfo  |   Keywords:  regression
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by dstndstn@…):

 Original bug-reporter here.

 In 1.3.X I am still getting stalls:

 {{{
 $ python -c "import django; print django.__file__"
 /usr/local/django-1.3.X/django/__init__.py
 $ svn info /usr/local/django-1.3.X/ | grep 'URL\|^Rev'
 URL: http://code.djangoproject.com/svn/django/branches/releases/1.3.X
 Revision: 16305
 $ python manage.py runserver &
 $ jobs
 [1]+  Stopped python manage.py runserver
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16034: get_field_display: Django needs a filter to allow get_field_display for a dynamic field

[Django]

#16034: get_field_display: Django needs a filter to allow get_field_display for 
a
dynamic field
-+-
   Reporter: |  Owner:  nobody
  thepapermen| Status:  new
   Type:  New|  Component:  Template system
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Design decision needed


Old description:

> {{ SomeModel.get_field_display }} is nice, but it is handy only for a
> specified field.
>
> If One wants to write a more universal template which should work with
> any set of fields, this won't work.
>
> What I propose is a universal filter which should provide human-readable
> name for a field of any type.
>
> For example, like this:
>
> 
> {% for item in query %}
> 
> {% for field in fields %}
> {{item|human_readable:field}}
> {% endfor %}
> 
> {% endfor %}
> 
>
> This will be a simple yet powerful way to provide nice human-readable
> info from Django models and forms.

New description:

 {{ SomeModel.get_field_display }} is nice, but it is handy only for a
 specified field.

 If One wants to write a more universal template which should work with any
 set of fields, this won't work.

 What I propose is a universal filter which should provide human-readable
 name for a field of any type.

 For example, like this:

 
 {% for item in query %}
 
 {% for field in fields %}
 {{item|human_readable:field}}
 {% endfor %}
 
 {% endfor %}
 

 This will be a simple yet powerful way to provide nice human-readable info
 from Django models and forms.

--

Comment:

 The idea and the API should be discussed on the mailing list before this
 ticket can be 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15880: manage.py: difficult to run in background (and crashes when input isn't a terminal)

[Django]

#15880: manage.py: difficult to run in background (and crashes when input isn't 
a
terminal)
-+-
   Reporter: |  Owner:  nobody
  dstndstn@… | Status:  closed
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Release blocker
 Resolution:  needsinfo  |   Keywords:  regression
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by lukeplant):

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


Comment:

 Changing state to indicate that we cannot progress with this unless we get
 the feedback Karen asked for.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15990: Broken sentence in modelforms topic doc

[Django]

#15990: Broken sentence in modelforms topic doc
-+-
   Reporter:  jblaine|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 I don't think the sentance that aaugustin proposed has the same meaning as
 the original. it should be:

 "As of Django 1.2, the model validation is triggered ''in addition'' to
 the default behavior of older versions (triggering the form validation) by
 calling is_valid() or accessing the errors attribute of the ModelForm."

 or

 "As of Django 1.2 calling is_valid() or accessing the errors attribute of
 the ModelForm will trigger model validation in addition to form
 validation."

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10843: django.contrib.markup.tests.Templates test_textile fails with python textile 2.1.3 and Django 1.0.2 final

[Django]

#10843: django.contrib.markup.tests.Templates test_textile fails with python
textile 2.1.3 and Django 1.0.2 final
+---
   Reporter:  ntoll |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Testing framework
Version:|   Severity:  Normal
 Resolution:  fixed |   Keywords:  Textile
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
+---
Changes (by lukeplant):

 * status:  reopened => closed
 * resolution:   => fixed
 * severity:  Release blocker => Normal


Comment:

 1.2.1 was released *before* the fix for this, and in 1.2.2 and on 1.3.X
 and trunk, the test passes (with textile==2.1.4). I have no idea why the
 bug has been reopened.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15064: DJANGO_SETTINGS_MODULE doesn't work with runserver

[Django]

#15064: DJANGO_SETTINGS_MODULE doesn't work with runserver
-+-
   Reporter:  olau   |  Owner:  ShawnMilo
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Management
Version:  1.3|  commands)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-

Comment (by ShawnMilo):

 Replying to [comment:17 lsaffre]:
 > It took me a few days to understand that my problems came from this
 change. This change has also the effect that DJANGO_SETTINGS_MODULE will
 take precedence over any existing settings.py in the current directory.
 Until now I almost never set DJANGO_SETTINGS_MODULE when developing, I
 just go to "my" directory and called  manage.py. Now I must take care of
 not having accidentally DJANGO_SETTINGS_MODULE set to some other project.
 Maybe a warning would be useful.


 Where do you propose the warning should be? I think the docs are pretty
 clear that DJANGO_SETTINGS_MODULE should be authoritative. Also, when you
 run manage.py runserver the settings file being used is displayed.

 https://docs.djangoproject.com/en/1.3/topics/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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16063: Problem with searching in m2m fields in inherited model

[Django]

#16063: Problem with searching in m2m fields in inherited model
-+-
   Reporter:  esizikov   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * type:  Bug => Cleanup/optimization


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16063: Problem with searching in m2m fields in inherited model

[Django]

#16063: Problem with searching in m2m fields in inherited model
+---
   Reporter:  esizikov  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
+---
Changes (by aaugustin):

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


Comment:

 Looking at the code, the part that is modified by the patch is not
 modified in current trunk. The problematic pattern is still there:
 {{{
 for bit in self.query.split():
 ...
 qs = qs.filter(...)
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16092: QuerySet F() fields should be able to reference .extra() select keys

[Django]

#16092: QuerySet F() fields should be able to reference .extra() select keys
-+-
   Reporter:  Joshua |  Owner:  nobody
  "jag" Ginsberg  | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 Here is a formal test case based on the example is the original 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16100: {{{date_hierarchy}}} in admin wiredly broken

[Django]

#16100: {{{date_hierarchy}}} in admin wiredly broken
+---
   Reporter:  geber@…   |  Owner:  aaugustin
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * status:  reopened => new
 * stage:  Unreviewed => Accepted


Comment:

 Even though I haven't confirmed that this is a bug in Django, I'm going to
 accept the ticket and assign it to myself, because no one is going to pick
 it from the Unreviewed queue now.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16100: date_hierarchy in admin weirdly broken (was: {{{date_hierarchy}}} in admin wiredly broken)

[Django]

#16100: date_hierarchy in admin weirdly broken
+---
   Reporter:  geber@…   |  Owner:  aaugustin
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16100: {{{date_hierarchy}}} in admin wiredly broken

[Django]

#16100: {{{date_hierarchy}}} in admin wiredly broken
--+---
   Reporter:  geber@… |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.admin
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---

Comment (by aaugustin):

 I set up MySQL, copied your code in a new app, syncdb, runserver, created
 a few objects, and as one might expect, everything works. It's really hard
 to debug this remotely.

 Could you re-enable `date_hierarchy` so we're in a situation where the bug
 occurs again? Then I have three questions:

 - does the bug only occur under `fcgi`, or did you also see it under
 `manage.py runserver`? I'm not sure what "I got that Error locally" means.
 - once the bug occurs, is it systematic (it occurs again if you refresh
 the page, until you restart the server)? or is it still random?
 - in addition to the traceback, could you post the values of the local
 variables in the last four frames? (Click the little arrow to show them.)

 From my experiments, three aggregates are computed to create the
 changelist for your !LogEntry objects. Here's the result of a
 `pdb.set_trace()` at the beginning of the innermost function of the
 traceback:

 {{{
 > /Users/myk/Desktop/django-
 trunk/django/db/models/sql/query.py(314)resolve_aggregate()
 -> if value is None:
 (Pdb) aggregate, value
 (, 2L)
 (Pdb) c
 > /Users/myk/Desktop/django-
 trunk/django/db/models/sql/query.py(314)resolve_aggregate()
 -> if value is None:
 (Pdb) aggregate, value
 (,
 datetime.datetime(2011, 5, 31, 21, 5, 16))
 (Pdb) c
 > /Users/myk/Desktop/django-
 trunk/django/db/models/sql/query.py(314)resolve_aggregate()
 -> if value is None:
 (Pdb) aggregate, value
 (,
 datetime.datetime(2011, 5, 31, 21, 4, 53))
 (Pdb) c
 }}}

 Based on the traceback in your initial report:

 - `aggregate.is_numeric` must be `True`, so it must be the first aggregate
 that crashes,
 - but `value` must be a datetime object there, so it must be the second or
 third one.

 I need the values of the local variables to continue this analysis.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15584: Forgotten password link for djangoproject.com no where to be found!!

[Django]

#15584: Forgotten password link for djangoproject.com no where to be found!!
-+-
   Reporter: |  Owner:  nobody
  foxwhisper | Status:  new
   Type:  Bug|  Component:  Djangoproject.com
  Milestone: |  Web site
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:  forgot password,
   Triage Stage:  Accepted   |  djangoproject, djangoproject.com,
Needs documentation:  0  |  link, forgot, password, forgotten
Patch needs improvement:  0  |  password
 |  Has patch:  0
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * easy:   => 0


Comment:

 There are some comment on this issue in #16041.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16041: djangoproject.com uses non-existent From address, and no way to resend confirmation email

[Django]

#16041: djangoproject.com uses non-existent From address, and no way to resend
confirmation email
-+-
   Reporter:  dracos2|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Djangoproject.com
Version:  1.3|  Web site
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by aaugustin):

 Actually issue B was already reported in #15584. Let this ticket be only
 about issue A.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16133: cannot access documentation django.contrib.admin

[Django]

#16133: cannot access documentation django.contrib.admin
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Djangoproject.com
Version:  1.3|  Web site
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Djangoproject.com Web site


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16133: cannot access documentation django.contrib.admin

[Django]

#16133: cannot access documentation django.contrib.admin
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Milestone: |  Component:  Uncategorized
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+---
Changes (by aaugustin):

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


Comment:

 Indeed, there's a bug in `django_website/docs/views.py`:

 {{{
 def redirect_index(request, *args, **kwargs):
 return redirect(request.path.rstrip('index/'))
 }}}

 This will strip all 'i', 'n', 'd', 'e', 'x' and '/' characters from the
 end of the URL. In this case, it will strip `in/index`. This is obviously
 wrong.

 This function could be written like this:

 {{{
 def redirect_index(request, *args, **kwargs):
 assert request.path.endswith('index/')
 return redirect(request.path[:-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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16110: GeometryField does not allow setting blank=True and null=False

[Django]

#16110: GeometryField does not allow setting blank=True and null=False
+
   Reporter:  slinkp|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  GIS
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
+

Comment (by slinkp):

 Yep, raising that on the dev list now... https://groups.google.com/group
 /django-developers/browse_thread/thread/9383c62827edc167

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15064: DJANGO_SETTINGS_MODULE doesn't work with runserver

[Django]

#15064: DJANGO_SETTINGS_MODULE doesn't work with runserver
-+-
   Reporter:  olau   |  Owner:  ShawnMilo
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Management
Version:  1.3|  commands)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by lsaffre):

 * cc: luc.saffre@… (added)


Comment:

 It took me a few days to understand that my problems came from this
 change. This change has also the effect that DJANGO_SETTINGS_MODULE will
 take precedence over any existing settings.py in the current directory.
 Until now I almost never set DJANGO_SETTINGS_MODULE when developing, I
 just go to "my" directory and called  manage.py. Now I must take care of
 not having accidentally DJANGO_SETTINGS_MODULE set to some other project.
 Maybe a warning would be useful.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14201: Add a "security overview" page to the docs

[Django]

#14201: Add a "security overview" page to the docs
---+---
   Reporter:  russellm |  Owner:  davidfischer
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Documentation
Version:  1.2  |   Severity:  Normal
 Resolution:   |   Keywords:  security
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---

Comment (by lukeplant):

 This patch is a great start. We should also include:

  * SQL injection (I know, Django makes you forget it even exists, isn't it
 wonderful?)
  * Clickjacking

 I think we should also have a dedicated section on SSL, and how to really
 get that hardened, which really requires setting both
 SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE to be `True`. That in turn
 might bring up the subject of how to securely redirect HTTP traffic to
 HTTPS. which is tricky due to reverse proxies. (See #14597 - warning: epic
 ticket!). I'm happy to write this bit, having some experience here.

 Regarding OWASP - I don't think their stuff on CSRF is up to much,
 especially their [https://www.owasp.org/index.php/Cross-
 Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet prevention cheat
 sheet], so perhaps we shouldn't link to that. I've corresponded with them
 by e-mail at length, and pointed out the flaws in their argument regarding
 using CSRF tokens in the query string, but they didn't seem interested in
 fixing that page. I'd fix it myself, except you need permissions, and my
 requests for an account have gone unheeded (though they said I was welcome
 to edit it), and eventually I got worn out trying to improve things.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16305 - in django/trunk/django: contrib/auth utils

[noreply]

Author: Alex
Date: 2011-05-31 08:43:19 -0700 (Tue, 31 May 2011)
New Revision: 16305

Modified:
   django/trunk/django/contrib/auth/context_processors.py
   django/trunk/django/contrib/auth/middleware.py
   django/trunk/django/utils/functional.py
Log:
Cleaned up how ``request.user`` is set, this is a follow up to [16297]. Thanks 
for the review Luke.

Modified: django/trunk/django/contrib/auth/context_processors.py
===
--- django/trunk/django/contrib/auth/context_processors.py  2011-05-31 
15:19:19 UTC (rev 16304)
+++ django/trunk/django/contrib/auth/context_processors.py  2011-05-31 
15:43:19 UTC (rev 16305)
@@ -1,5 +1,3 @@
-from django.utils.functional import lazy, memoize, SimpleLazyObject
-
 # PermWrapper and PermLookupDict proxy the permissions system into objects that
 # the template system can understand.
 
@@ -36,23 +34,13 @@
 If there is no 'user' attribute in the request, uses AnonymousUser (from
 django.contrib.auth).
 """
-# If we access request.user, request.session is accessed, which results in
-# 'Vary: Cookie' being sent in every request that uses this context
-# processor, which can easily be every request on a site if
-# TEMPLATE_CONTEXT_PROCESSORS has this context processor added.  This kills
-# the ability to cache.  So, we carefully ensure these attributes are lazy.
-# We don't use django.utils.functional.lazy() for User, because that
-# requires knowing the class of the object we want to proxy, which could
-# break with custom auth backends.  LazyObject is a less complete but more
-# flexible solution that is a good enough wrapper for 'User'.
-def get_user():
-if hasattr(request, 'user'):
-return request.user
-else:
-from django.contrib.auth.models import AnonymousUser
-return AnonymousUser()
+if hasattr(request, 'user'):
+user = request.user
+else:
+from django.contrib.auth.models import AnonymousUser
+user = AnonymousUser()
 
 return {
-'user': SimpleLazyObject(get_user),
-'perms':  lazy(lambda: PermWrapper(get_user()), PermWrapper)(),
+'user': user,
+'perms': PermWrapper(user),
 }

Modified: django/trunk/django/contrib/auth/middleware.py
===
--- django/trunk/django/contrib/auth/middleware.py  2011-05-31 15:19:19 UTC 
(rev 16304)
+++ django/trunk/django/contrib/auth/middleware.py  2011-05-31 15:43:19 UTC 
(rev 16305)
@@ -1,28 +1,23 @@
 from django.contrib import auth
 from django.core.exceptions import ImproperlyConfigured
+from django.utils.functional import SimpleLazyObject
 
 
-class LazyUser(object):
-def __get__(self, request, obj_type=None):
-if not hasattr(request, '_cached_user'):
-from django.contrib.auth import get_user
-request._cached_user = get_user(request)
-return request._cached_user
+def get_user(request):
+from django.contrib.auth import get_user
 
+if not hasattr(request, '_cached_user'):
+request._cached_user = get_user(request)
+return request._cached_user
 
+
 class AuthenticationMiddleware(object):
 def process_request(self, request):
 assert hasattr(request, 'session'), "The Django authentication 
middleware requires session middleware to be installed. Edit your 
MIDDLEWARE_CLASSES setting to insert 
'django.contrib.sessions.middleware.SessionMiddleware'."
 
-# We dynamically subclass request.__class__ rather than monkey patch 
the
-# original class.
-class RequestWithUser(request.__class__):
-user = LazyUser()
+request.user = SimpleLazyObject(lambda: get_user(request))
 
-request.__class__ = RequestWithUser
-return None
 
-
 class RemoteUserMiddleware(object):
 """
 Middleware for utilizing Web-server-provided authentication.

Modified: django/trunk/django/utils/functional.py
===
--- django/trunk/django/utils/functional.py 2011-05-31 15:19:19 UTC (rev 
16304)
+++ django/trunk/django/utils/functional.py 2011-05-31 15:43:19 UTC (rev 
16305)
@@ -208,7 +208,7 @@
 def __dir__(self):
 if self._wrapped is None:
 self._setup()
-return  dir(self._wrapped)
+return dir(self._wrapped)
 
 class SimpleLazyObject(LazyObject):
 """
@@ -227,9 +227,7 @@
 value.
 """
 self.__dict__['_setupfunc'] = func
-# For some reason, we have to inline LazyObject.__init__ here to avoid
-# recursion
-self._wrapped = None
+super(SimpleLazyObject, self).__init__()
 
 def __str__(self):
 if self._wrapped is None: self._setup()

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send em

[Django] #16133: cannot access documentation django.contrib.admin

[Django]

#16133: cannot access documentation django.contrib.admin
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+---
 https://docs.djangoproject.com/en/1.3/ref/contrib/admin/index

 points to

 https://docs.djangoproject.com/en/1.3/ref/contrib/adm/

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16304 - in django/trunk: django/contrib/auth/tests django/contrib/auth/tests/templates django/contrib/auth/tests/templates/context_processors tests/regressiontests/context_processors/tem

[noreply]

Author: lukeplant
Date: 2011-05-31 08:19:19 -0700 (Tue, 31 May 2011)
New Revision: 16304

Added:
   django/trunk/django/contrib/auth/tests/templates/context_processors/
   
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_access.html
   
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_messages.html
   
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_no_access.html
   
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_perms.html
   
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_test_access.html
   
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_user.html
Removed:
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_access.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_messages.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_no_access.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_perms.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_test_access.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_user.html
Modified:
   django/trunk/django/contrib/auth/tests/__init__.py
   django/trunk/django/contrib/auth/tests/context_processors.py
   django/trunk/django/contrib/auth/tests/urls.py
Log:
Fixed auth context processor tests, which were not running at all previously.

It seems they were accidentally disabled following being moved from
regressiontests in [15990]

Modified: django/trunk/django/contrib/auth/tests/__init__.py
===
--- django/trunk/django/contrib/auth/tests/__init__.py  2011-05-31 14:02:22 UTC 
(rev 16303)
+++ django/trunk/django/contrib/auth/tests/__init__.py  2011-05-31 15:19:19 UTC 
(rev 16304)
@@ -2,6 +2,7 @@
 RowlevelBackendTest, AnonymousUserBackendTest, NoAnonymousUserBackendTest,
 NoBackendsTest, InActiveUserBackendTest, NoInActiveUserBackendTest)
 from django.contrib.auth.tests.basic import BasicTestCase
+from django.contrib.auth.tests.context_processors import 
AuthContextProcessorTests
 from django.contrib.auth.tests.decorators import LoginRequiredTestCase
 from django.contrib.auth.tests.forms import (UserCreationFormTest,
 AuthenticationFormTest, SetPasswordFormTest, PasswordChangeFormTest,

Modified: django/trunk/django/contrib/auth/tests/context_processors.py
===
--- django/trunk/django/contrib/auth/tests/context_processors.py
2011-05-31 14:02:22 UTC (rev 16303)
+++ django/trunk/django/contrib/auth/tests/context_processors.py
2011-05-31 15:19:19 UTC (rev 16304)
@@ -1,16 +1,27 @@
-# from django.conf import settings
+import os
+
+from django.conf import settings
 from django.contrib.auth import authenticate
 from django.db.models import Q
 from django.test import TestCase
-# from django.template import Template
 
+
 class AuthContextProcessorTests(TestCase):
 """
 Tests for the ``django.contrib.auth.context_processors.auth`` processor
 """
-urls = 'regressiontests.context_processors.urls'
+urls = 'django.contrib.auth.tests.urls'
 fixtures = ['context-processors-users.xml']
 
+def setUp(self):
+self.old_TEMPLATE_DIRS = settings.TEMPLATE_DIRS
+settings.TEMPLATE_DIRS = (
+os.path.join(os.path.dirname(__file__), 'templates'),
+)
+
+def tearDown(self):
+settings.TEMPLATE_DIRS = self.old_TEMPLATE_DIRS
+
 def test_session_not_accessed(self):
 """
 Tests that the session is not accessed simply by including
@@ -74,4 +85,4 @@
 # equality in a non-duck-typing way
 # See bug #12060
 self.assertEqual(response.context['user'], user)
-self.assertEqual(user, response.context['user'])
\ No newline at end of file
+self.assertEqual(user, response.context['user'])

Copied: 
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_access.html
 (from rev 16303, 
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_access.html)
===
--- 
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_access.html
  (rev 0)
+++ 
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_access.html
  2011-05-31 15:19:19 UTC (rev 16304)
@@ -0,0 +1 @@
+{{ user }}

Copied: 
django/trunk/django/contrib/auth/tests/templates/context_processors/auth_attrs_messages.html
 (from rev 16303, 
django/trunk/tests/regressiontests/context_processors/templates/context_p

Re: [Django] #16023: Range query on a datetime is NOT inclusive with dates

[Django]

#16023: Range query on a datetime is NOT inclusive with dates
+---
   Reporter:  jodym@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---

Comment (by Jody McIntyre ):

 Replying to [comment:1 aaugustin]:
 > In Python and many other languages, `i in range(n)` means `0 <= i < n`.
 If I want all transactions from April, I'd use:
 >
 > {{{
 > start_date = datetime.date(2011, 4, 1)
 > end_date = datetime.date(2011, 5, 1)
 > }}}

 That will give all transactions between 2011-04-01 00:00:00 and 2011-05-01
 00:00:00 inclusive, which isn't quite the same thing (it will include
 transactions dated exactly 2011-05-01 00:00:00.)

 What's worse is that if start_date and end_date are DateField(), you'll
 get all transactions on 2011-05-01, which is inconsistent with the
 behaviour if it's a DateTimeField().

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16132: Error message in django.contrib.localflavor.in_.forms.INZipCodeField is incorrect

[Django]

#16132: Error message in django.contrib.localflavor.in_.forms.INZipCodeField is
incorrect
-+-
   Reporter: |  Owner:  nobody
  david.winterbottom@…   | Status:  closed
   Type:  Bug|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  duplicate  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 This is actually addressed by the patch in #15813, hence closing as dupe.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15813: STATES_NORMALIZED dict for India does not include all states

[Django]

#15813: STATES_NORMALIZED dict for India does not include all states
-+-
   Reporter:  jsdalton   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.localflavor
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 Thank you, the patch looks great. Good catch with the allowed space inside
 the postal code -- I've just updated your patch to reflect that in the
 error message, and also fixed the related small issue reported in #16132.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16303 - in django/trunk/tests/regressiontests/forms: . localflavor tests

[noreply]

Author: lukeplant
Date: 2011-05-31 07:02:22 -0700 (Tue, 31 May 2011)
New Revision: 16303

Modified:
   django/trunk/tests/regressiontests/forms/localflavor/__init__.py
   django/trunk/tests/regressiontests/forms/localflavor/au.py
   django/trunk/tests/regressiontests/forms/localflavor/hr.py
   django/trunk/tests/regressiontests/forms/localflavor/pt.py
   django/trunk/tests/regressiontests/forms/localflavor/ro.py
   django/trunk/tests/regressiontests/forms/localflavor/utils.py
   django/trunk/tests/regressiontests/forms/localflavortests.py
   django/trunk/tests/regressiontests/forms/tests/__init__.py
Log:
Fixed #15805 - assertFieldOutput should not use assertRaisesRegexp

Thanks to julien for the report and patch.

Modified: django/trunk/tests/regressiontests/forms/localflavor/__init__.py
===
--- django/trunk/tests/regressiontests/forms/localflavor/__init__.py
2011-05-31 09:44:21 UTC (rev 16302)
+++ django/trunk/tests/regressiontests/forms/localflavor/__init__.py
2011-05-31 14:02:22 UTC (rev 16303)
@@ -0,0 +1,11 @@
+from django.forms import EmailField
+from utils import LocalFlavorTestCase
+
+class AssertFieldOutputTests(LocalFlavorTestCase):
+
+def test_assert_field_output(self):
+error_invalid = [u'Enter a valid e-mail address.']
+self.assertFieldOutput(EmailField, {'a...@a.com': 'a...@a.com'}, 
{'aaa': error_invalid})
+self.assertRaises(AssertionError, self.assertFieldOutput, EmailField, 
{'a...@a.com': 'a...@a.com'}, {'aaa': error_invalid + [u'Another error']})
+self.assertRaises(AssertionError, self.assertFieldOutput, EmailField, 
{'a...@a.com': 'Wrong output'}, {'aaa': error_invalid})
+self.assertRaises(AssertionError, self.assertFieldOutput, EmailField, 
{'a...@a.com': 'a...@a.com'}, {'aaa': [u'Come on, gimme some well formatted 
data, dude.']})

Modified: django/trunk/tests/regressiontests/forms/localflavor/au.py
===
--- django/trunk/tests/regressiontests/forms/localflavor/au.py  2011-05-31 
09:44:21 UTC (rev 16302)
+++ django/trunk/tests/regressiontests/forms/localflavor/au.py  2011-05-31 
14:02:22 UTC (rev 16303)
@@ -20,14 +20,14 @@
 self.assertEqual(f.render('state', 'NSW'), out)
 
 def test_AUPostCodeField(self):
-error_format = [u'Enter a 4 digit post code.']
+error_format = [u'Enter a 4 digit postcode.']
 valid = {
 '1234': '1234',
 '2000': '2000',
 }
 invalid = {
 'abcd': error_format,
-'20001': error_format,
+'20001': [u'Ensure this value has at most 4 characters (it has 
5).'] + error_format,
 }
 self.assertFieldOutput(AUPostCodeField, valid, invalid)
 

Modified: django/trunk/tests/regressiontests/forms/localflavor/hr.py
===
--- django/trunk/tests/regressiontests/forms/localflavor/hr.py  2011-05-31 
09:44:21 UTC (rev 16302)
+++ django/trunk/tests/regressiontests/forms/localflavor/hr.py  2011-05-31 
14:02:22 UTC (rev 16303)
@@ -158,7 +158,7 @@
 '12345678901': '12345678901',
 }
 invalid = {
-'1234567890': error_invalid,
+'1234567890': [u'Ensure this value has at least 11 characters (it 
has 10).'] + error_invalid,
 'ABCDEFGHIJK': error_invalid,
 }
 self.assertFieldOutput(HROIBField, valid, invalid)

Modified: django/trunk/tests/regressiontests/forms/localflavor/pt.py
===
--- django/trunk/tests/regressiontests/forms/localflavor/pt.py  2011-05-31 
09:44:21 UTC (rev 16302)
+++ django/trunk/tests/regressiontests/forms/localflavor/pt.py  2011-05-31 
14:02:22 UTC (rev 16303)
@@ -17,7 +17,7 @@
 self.assertFieldOutput(PTZipCodeField, valid, invalid)
 
 def test_PTPhoneNumberField(self):
-error_format = [u'Phone numbers must have 9 digits, or start by + or 
00']
+error_format = [u'Phone numbers must have 9 digits, or start by + or 
00.']
 valid = {
 '917845189': '917845189',
 '91 784 5189': '917845189',

Modified: django/trunk/tests/regressiontests/forms/localflavor/ro.py
===
--- django/trunk/tests/regressiontests/forms/localflavor/ro.py  2011-05-31 
09:44:21 UTC (rev 16302)
+++ django/trunk/tests/regressiontests/forms/localflavor/ro.py  2011-05-31 
14:02:22 UTC (rev 16303)
@@ -66,7 +66,7 @@
 invalid = {
 '21694680': error_invalid,
 '2169468': error_atmost,
-'0': error_atleast,
+'0': error_atleast + error_invalid,
 }
 self.assertFieldOutput(ROCIFField, valid, invalid)
 
@@ -81,7 +81,7 @@
 '1981211204487': error_invalid,
 '1981232204489': error_invalid,
 '99812112

Re: [Django] #15805: assertFieldOutput should not use assertRaisesRegexp

[Django]

#15805: assertFieldOutput should not use assertRaisesRegexp
-+-
   Reporter:  julien |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Testing framework
Version:  SVN|   Severity:  Release blocker
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

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


Comment:

 In [16303]:
 {{{
 #!CommitTicketReference repository="" revision="16303"
 Fixed #15805 - assertFieldOutput should not use assertRaisesRegexp

 Thanks to julien 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16132: Error message in django.contrib.localflavor.in_.forms.INZipCodeField is incorrect

[Django]

#16132: Error message in django.contrib.localflavor.in_.forms.INZipCodeField is
incorrect
-+-
   Reporter: |  Owner:  nobody
  david.winterbottom@…   | Status:  new
   Type:  Bug|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 Accepting. Tests are needed but can't be properly written until #15805
 gets fixed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16132: Error message in django.contrib.localflavor.in_.forms.INZipCodeField is incorrect

[Django]

#16132: Error message in django.contrib.localflavor.in_.forms.INZipCodeField is
incorrect
--+-
 Reporter:  david.winterbottom@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  contrib.localflavor
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  1
--+-
 Message indicates that 7 digits are required, whereas the correct value is
 6 (see http://en.wikipedia.org/wiki/Postal_Index_Number).

 Trivial patch 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16115: New hook to allow change objects after all inline formsets have been saved

[Django]

#16115: New hook to allow change objects after all inline formsets have been 
saved
---+---
   Reporter:  igors|  Owner:  igors
   Type:  New feature  | Status:  assigned
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---

Comment (by igors):

 Great julien, your changes make a lot of sense. I was really in doubt
 about that unit test since i havent's seen other like that. 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2331: Related Field has invalid lookup: icontains

[Django]

#2331: Related Field has invalid lookup: icontains
-+-
   Reporter:  ian@…  |  Owner:  adrian
   Type:  defect | Status:  closed
  Milestone: |  Component:  Database layer
Version: |  (models, ORM)
 Resolution:  invalid|   Severity:  normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by gmludo@…):

 * cc: gmludo@… (added)


Comment:

 If like me, you're looking for the solution of this error message, this is
 the documentation :
 
https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.search_fields

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16091: typo in model instance docs

[Django]

#16091: typo in model instance docs
-+-
   Reporter:  PaulM  |  Owner:  teraom
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by timo):

 In [16302]:
 {{{
 #!CommitTicketReference repository="" revision="16302"
 [1.3.X] Fixed #16090, #16091 - Typos in docs; thanks teraom.

 Backport of r16300 from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16302 - in django/branches/releases/1.3.X/docs/ref: . models

[noreply]

Author: timo
Date: 2011-05-31 02:44:21 -0700 (Tue, 31 May 2011)
New Revision: 16302

Modified:
   django/branches/releases/1.3.X/docs/ref/class-based-views.txt
   django/branches/releases/1.3.X/docs/ref/models/instances.txt
Log:
[1.3.X] Fixed #16090, #16091 - Typos in docs; thanks teraom.

Backport of r16300 from trunk.

Modified: django/branches/releases/1.3.X/docs/ref/class-based-views.txt
===
--- django/branches/releases/1.3.X/docs/ref/class-based-views.txt   
2011-05-31 09:44:18 UTC (rev 16301)
+++ django/branches/releases/1.3.X/docs/ref/class-based-views.txt   
2011-05-31 09:44:21 UTC (rev 16302)
@@ -431,7 +431,7 @@
 
 .. method:: get_form_kwargs()
 
-Build the keyword arguments requried to instanciate an the form.
+Build the keyword arguments required to instantiate the form.
 
 The ``initial`` argument is set to :meth:`.get_initial`. If the
 request is a ``POST`` or ``PUT``, the request data (``request.POST``

Modified: django/branches/releases/1.3.X/docs/ref/models/instances.txt
===
--- django/branches/releases/1.3.X/docs/ref/models/instances.txt
2011-05-31 09:44:18 UTC (rev 16301)
+++ django/branches/releases/1.3.X/docs/ref/models/instances.txt
2011-05-31 09:44:21 UTC (rev 16302)
@@ -38,7 +38,7 @@
 2. Validate the model as a whole
 3. Validate the field uniqueness
 
-All three steps are performed when you call by a model's
+All three steps are performed when you call a model's
 ``full_clean()`` method.
 
 When you use a ``ModelForm``, the call to ``is_valid()`` will perform

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16090: typo in cbv docs

[Django]

#16090: typo in cbv docs
-+-
   Reporter:  PaulM  |  Owner:  teraom
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-

Comment (by timo):

 In [16302]:
 {{{
 #!CommitTicketReference repository="" revision="16302"
 [1.3.X] Fixed #16090, #16091 - Typos in docs; thanks teraom.

 Backport of r16300 from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16301 - in django/branches/releases/1.3.X/docs: ref topics

[noreply]

Author: timo
Date: 2011-05-31 02:44:18 -0700 (Tue, 31 May 2011)
New Revision: 16301

Modified:
   django/branches/releases/1.3.X/docs/ref/settings.txt
   django/branches/releases/1.3.X/docs/topics/logging.txt
Log:
[1.3.X] Fixed #15801 - Incorrect external link for dictConfig; thanks David 
Niergarth for the report; jonash for the patch.

Backport of r16100 from trunk.

Modified: django/branches/releases/1.3.X/docs/ref/settings.txt
===
--- django/branches/releases/1.3.X/docs/ref/settings.txt2011-05-31 
09:42:19 UTC (rev 16300)
+++ django/branches/releases/1.3.X/docs/ref/settings.txt2011-05-31 
09:44:18 UTC (rev 16301)
@@ -1196,7 +1196,7 @@
 If you set :setting:`LOGGING_CONFIG` to ``None``, the logging
 configuration process will be skipped.
 
-.. _dictConfig: http://docs.python.org/library/logging.html#logging.dictConfig
+.. _dictConfig: 
http://docs.python.org/library/logging.config.html#configuration-dictionary-schema
 
 .. setting:: LOGIN_REDIRECT_URL
 

Modified: django/branches/releases/1.3.X/docs/topics/logging.txt
===
--- django/branches/releases/1.3.X/docs/topics/logging.txt  2011-05-31 
09:42:19 UTC (rev 16300)
+++ django/branches/releases/1.3.X/docs/topics/logging.txt  2011-05-31 
09:44:18 UTC (rev 16301)
@@ -225,7 +225,7 @@
 does, you can be certain that loggers are always ready for use in your
 project code.
 
-.. _dictConfig format: 
http://docs.python.org/library/logging.html#configuration-dictionary-schema
+.. _dictConfig format: 
http://docs.python.org/library/logging.config.html#configuration-dictionary-schema
 
 .. _a third-party library: http://bitbucket.org/vinay.sajip/dictconfig
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15801: Logging docs: Incorrect external link for dictConfig

[Django]

#15801: Logging docs: Incorrect external link for dictConfig
-+-
   Reporter:  David  |  Owner:  nobody
  Niergarth| Status:  closed
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by timo):

 In [16301]:
 {{{
 #!CommitTicketReference repository="" revision="16301"
 [1.3.X] Fixed #15801 - Incorrect external link for dictConfig; thanks
 David Niergarth for the report; jonash for the patch.

 Backport of r16100 from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16114: typo in contributing/writing-code/unit-tests documentation

[Django]

#16114: typo in contributing/writing-code/unit-tests documentation
-+-
   Reporter:  danger |  Owner:  teraom
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by timo):

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


Comment:

 In [16300]:
 {{{
 #!CommitTicketReference repository="" revision="16300"
 Fixed #16090, #16091, #16114 - Typos in docs; thanks teraom.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16090: typo in cbv docs

[Django]

#16090: typo in cbv docs
-+-
   Reporter:  PaulM  |  Owner:  teraom
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by timo):

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


Comment:

 In [16300]:
 {{{
 #!CommitTicketReference repository="" revision="16300"
 Fixed #16090, #16091, #16114 - Typos in docs; thanks teraom.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16091: typo in model instance docs

[Django]

#16091: typo in model instance docs
-+-
   Reporter:  PaulM  |  Owner:  teraom
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by timo):

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


Comment:

 In [16300]:
 {{{
 #!CommitTicketReference repository="" revision="16300"
 Fixed #16090, #16091, #16114 - Typos in docs; thanks teraom.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16300 - in django/trunk/docs: internals/contributing/writing-code ref ref/models

[noreply]

Author: timo
Date: 2011-05-31 02:42:19 -0700 (Tue, 31 May 2011)
New Revision: 16300

Modified:
   django/trunk/docs/internals/contributing/writing-code/unit-tests.txt
   django/trunk/docs/ref/class-based-views.txt
   django/trunk/docs/ref/models/instances.txt
Log:
Fixed #16090, #16091, #16114 - Typos in docs; thanks teraom.

Modified: django/trunk/docs/internals/contributing/writing-code/unit-tests.txt
===
--- django/trunk/docs/internals/contributing/writing-code/unit-tests.txt
2011-05-30 22:50:11 UTC (rev 16299)
+++ django/trunk/docs/internals/contributing/writing-code/unit-tests.txt
2011-05-31 09:42:19 UTC (rev 16300)
@@ -26,7 +26,7 @@
 ~~
 
 Running the tests requires a Django settings module that defines the
-databases to use. To make it easy to get started. Django provides a
+databases to use. To make it easy to get started, Django provides a
 sample settings module that uses the SQLite database. To run the tests
 with this sample ``settings`` module, ``cd`` into the Django
 ``tests/`` directory and run:

Modified: django/trunk/docs/ref/class-based-views.txt
===
--- django/trunk/docs/ref/class-based-views.txt 2011-05-30 22:50:11 UTC (rev 
16299)
+++ django/trunk/docs/ref/class-based-views.txt 2011-05-31 09:42:19 UTC (rev 
16300)
@@ -431,7 +431,7 @@
 
 .. method:: get_form_kwargs()
 
-Build the keyword arguments requried to instanciate an the form.
+Build the keyword arguments required to instantiate the form.
 
 The ``initial`` argument is set to :meth:`.get_initial`. If the
 request is a ``POST`` or ``PUT``, the request data (``request.POST``

Modified: django/trunk/docs/ref/models/instances.txt
===
--- django/trunk/docs/ref/models/instances.txt  2011-05-30 22:50:11 UTC (rev 
16299)
+++ django/trunk/docs/ref/models/instances.txt  2011-05-31 09:42:19 UTC (rev 
16300)
@@ -38,7 +38,7 @@
 2. Validate the model as a whole
 3. Validate the field uniqueness
 
-All three steps are performed when you call by a model's
+All three steps are performed when you call a model's
 ``full_clean()`` method.
 
 When you use a ``ModelForm``, the call to ``is_valid()`` will perform

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12890: extra() tables included twice do not generate aliases

[Django]

#12890: extra() tables included twice do not generate aliases
-+-
   Reporter:  semenov|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by russellm):

 * stage:  Unreviewed => Accepted


Comment:

 Reverting stage change. Ticket has already been accepted. The Unreviewed
 state refers to that triage status of the ticket, not the review status of
 an individual 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12890: extra() tables included twice do not generate aliases

[Django]

#12890: extra() tables included twice do not generate aliases
-+-
   Reporter:  semenov|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by daveycrockett):

 * cc: daveycrockett (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12890: extra() tables included twice do not generate aliases

[Django]

#12890: extra() tables included twice do not generate aliases
-+-
   Reporter:  semenov|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by daveycrockett):

 * has_patch:  0 => 1
 * version:  1.1 => 1.2
 * stage:  Accepted => Unreviewed


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.