[Django] #16158: Change FALLBACK_DYLD_LIBRARY_PATH to DYLD_FALLBACK_LIBRARY_PATH in GIS documentation

[Django]

#16158: Change FALLBACK_DYLD_LIBRARY_PATH to DYLD_FALLBACK_LIBRARY_PATH in GIS
documentation
+---
 Reporter:  adam@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Documentation
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  1
+---
 https://docs.djangoproject.com/en/1.3/ref/contrib/gis/install/

 The environment variable FALLBACK_DYLD_LIBRARY_PATH should be
 DYLD_FALLBACK_LIBRARY_PATH.  The former does not work, the latter does.

 A citation from 2005 for the use of the latter variable:
 http://hublog.hubmed.org/archives/001192.html

 And 2006: http://lists.apple.com/archives/darwin-
 dev/2006/Mar/msg00124.html

 And "man dyld" on any Mac:

 {{{
DYLD_FALLBACK_LIBRARY_PATH
   This is a colon separated list of directories that contain
 libraries.   It  is  used  as  the
   default  location  for  libraries  not  found in their
 install path.  By default, it is set to
   $(HOME)/lib:/usr/local/lib:/lib:/usr/lib.
 }}}

-- 
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] #14832: Impossible to create inline objects if form validates but is unchanged

[Django]

#14832: Impossible to create inline objects if form validates but is unchanged
+---
   Reporter:  julien|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:  sprintdec2010
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---
Changes (by julien):

 * easy:   => 0


Comment:

 #11807 reported the same issue, contains a detailed analysis by kmtracey
 and has a test case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #11807: Admin inlines onetoone related object not saved

[Django]

#11807: Admin inlines onetoone related object not saved
-+-
   Reporter:  nemesys@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.admin
Version:  1.1|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:  admin inline
   Triage Stage:  Design |  onetoone save
  decision needed|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by julien):

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


Comment:

 I'm going to close this one as a dupe of #14832 on the basis that it's
 been accepted and that it has a slightly clearer description.

-- 
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] #16089: Adding/Removing admin Inlines on the fly

[Django]

#16089: Adding/Removing admin Inlines on the fly
-+-
   Reporter:  sheep2 |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  1
  decision needed|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
-+-

Comment (by julien):

 See also related tickets #11715 and #12679.

-- 
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] #12679: In admin, inlines should be allowed to be properties

[Django]

#12679: In admin, inlines should be allowed to be properties
-+-
   Reporter:  mariarchi  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  admin inlines duck
   Triage Stage:  Accepted   |  typing
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by julien):

 * easy:   => 0


Comment:

 Currently a lot of `ModelAdmin`'s attributes (`list_display`,
 `readonly_fields`, `list_filter`, etc.) are expected to be lists or
 tuples. `ModelAdmin.inlines` shouldn't be treated as a special case. If we
 allow it to be merely an iterable, then the same should be done for all
 those other attributes. (Hint: check out
 `django.contrib.admin.validation.check_isseq()`)

 See also #16089 which is looking at adding flexibility with inlines
 registration.

-- 
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] #16157: Make sure that fields that are presented as single-line are validated as such

[Django]

#16157: Make sure that fields that are presented as single-line are validated as
such
-+-
 Reporter:  tkolar   |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Database layer
  Version:  SVN  |  (models, ORM)
 Keywords:  CharField multiline  |   Severity:  Normal
  validator  |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+-
 This applies to fields like `CharField` that are presented as `` by default.

 As a developer, it is easy to overlook the fact that it is nonetheless
 possible to submit multiline data to such a field, for instance by
 creating a custom form, or by manipulating the original form. If the
 assumption that entries for this field will always be single-line is
 erroneously made, this is a hard-to-find bug at best, and a vulnerability
 at worst.

 My proposal is to add a validator (for instance `single_line`) that checks
 that an input value doesn't contain a newline, and to add it to all the
 fields that are presented as ``, and (optionally) to
 add a field option (for instance, `allow_multiline`) to override this
 behavior.

 I'm proposing that this become part of django for the following reasons:
  * If the user uses the default form field produced by such a field, they
 cannot enter a multiline value anyway, so my proposal fixes the problem
 that validation on the server is "weaker" than on the client.
  * Although it's a corner case, this could, in fact, create actual
 vulnerabilities (Use case: a simple protocol that has DSV with the field
 as the last entry per line).
  * People who want multiline will use `TextField` anyway. If someone out
 there has customized `CharField` to act like `TextField`, they need not
 complain if they have to fix that. For the other field types, "no
 multiline" is implicit on their respective validation (haven't checked,
 but if that isn't the case, that's arguable a bug in itself). Therefore,
 compatibility is not a problem.

 I volunteer to write a patch that implements this if this ticket is
 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] #16156: Django overrides user-defined "User" model with its own

[Django]

#16156: Django overrides user-defined "User" model with its own
-+--
   Reporter:  dloewenherz@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.auth
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+--

Comment (by anonymous):

 I actually just figured it out (I think). Without thinking, I put this all
 in an app called `auth`. I think that threw off the namespacing with the
 built-in Django auth, which I have in `INSTALLED_APPS` and I am using for
 the admin.

-- 
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] #16156: Django overrides user-defined "User" model with its own

[Django]

#16156: Django overrides user-defined "User" model with its own
-+--
   Reporter:  dloewenherz@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.auth
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+--
Changes (by kmtracey):

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


Comment:

 I'd guess you are importing Django's User somewhere before you specify the
 model `User` in the meta class for your !RegistrationForm. I do not see
 what you are describing, using your model, and avoiding any import of User
 from `django.contrib.auth.models':

 {{{
 >>> from ttt.models import User
 >>> import datetime
 >>> User.objects.create(email="x...@xyz.com", password="uhoh",
 birthday=datetime.date.today(), gender=True)
 
 >>> u = User.objects.all()[0]
 >>> u
 
 >>> u.email
 u'x...@xyz.com'
 >>> from django import forms
 >>> class RegistrationForm(forms.ModelForm):
 ... class Meta():
 ...   model = User
 ...   fields = ['email', 'password']
 ...   widgets = {
 ...   'email': forms.TextInput(attrs={'autocomplete': 'off'}),
 ...   'password': forms.PasswordInput(attrs={'autocomplete':
 'off'})}
 ...
 >>> rf = RegistrationForm(instance=u)
 >>> rf.as_p()
 u'Email: \nPassword: '
 >>>
 }}}

-- 
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] #16156: Django overrides user-defined "User" model with its own

[Django]

#16156: Django overrides user-defined "User" model with its own
---+--
 Reporter:  dloewenherz@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  contrib.auth
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+--
 I'm getting some very weird results when I name my model "User".

 Here's the definition.


 {{{
 from django.db import models

 class User(models.Model):
 email = models.EmailField()
 password = models.CharField(max_length=51)
 birthday = models.DateField()
 gender = models.BooleanField() # True => Male
 }}}

 Here's the ModelForm:


 {{{
 from django import forms

 class RegistrationForm(forms.ModelForm):
 class Meta():
 model = User
 fields = ['email', 'password']
 widgets = {
 'email': forms.TextInput(attrs={'autocomplete': 'off'}),
 'password': forms.PasswordInput(attrs={'autocomplete':
 'off'}) }
 }}}

 When I render this form in my template with "{{ form.as_p }}" I see the
 following help text for the password input: "Use
 '[algo]$[salt]$[hexdigest]' or use the change password form.".

 Seems as though there is some weird override of the Django-defined User
 model and mine.

-- 
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] #16154: r16051 broke editing a filtered changelist

[Django]

#16154: r16051 broke editing a filtered changelist
+-
   Reporter:  kmtracey  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Release blocker
 Resolution:|   Keywords:  regression dataloss
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+-

Comment (by kmtracey):

 (And yes, there is another bug here, I think the closest match is
 described by #11313. Admin is too trusting that posted data "lines up" the
 same when POSTED as it did when the page was originally retrieved via GET.
 If we had a fix for that issue this change likely would have produced some
 error message rather than unexpected data changes.)

-- 
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] #16154: r16051 broke editing a filtered changelist

[Django]

#16154: r16051 broke editing a filtered changelist
+-
   Reporter:  kmtracey  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Release blocker
 Resolution:|   Keywords:  regression dataloss
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+-

Comment (by kmtracey):

 The validator may be right, per:
 http://dev.w3.org/html5/spec/Overview.html#attr-fs-action which says if
 action is specified it must be non-empty. I guess maybe with HTML5 it's
 not supposed to be specified at all if it's empty. Of course it used to be
 "required"...so it seems leaving it entirely unspecified might be
 troublesome for older browsers, though in a quick test with FF 3.6.17,
 Chromium 12, and IE8 leaving action out entirely looks to behave the same
 as `action=""`. Oh, fun with evolving "standards".

-- 
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] #16155: Drop support for Python 2.4

[Django]

#16155: Drop support for Python 2.4
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone:  1.4|   Severity:  Release blocker
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

 * 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 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] r16330 - in django/trunk/django/contrib: admin/templates/admin admin/templates/registration formtools/templates/formtools

[noreply]

Author: lukeplant
Date: 2011-06-04 14:51:13 -0700 (Sat, 04 Jun 2011)
New Revision: 16330

Modified:
   django/trunk/django/contrib/admin/templates/admin/delete_confirmation.html
   
django/trunk/django/contrib/admin/templates/admin/delete_selected_confirmation.html
   django/trunk/django/contrib/admin/templates/admin/search_form.html
   
django/trunk/django/contrib/admin/templates/registration/password_change_form.html
   
django/trunk/django/contrib/admin/templates/registration/password_reset_confirm.html
   
django/trunk/django/contrib/admin/templates/registration/password_reset_form.html
   django/trunk/django/contrib/formtools/templates/formtools/form.html
   django/trunk/django/contrib/formtools/templates/formtools/preview.html
Log:
Reverted most of [16051], because it was thoroughly incorrect (whatever some 
validator says)

Refs #16154

Modified: 
django/trunk/django/contrib/admin/templates/admin/delete_confirmation.html
===
--- django/trunk/django/contrib/admin/templates/admin/delete_confirmation.html  
2011-06-04 21:42:53 UTC (rev 16329)
+++ django/trunk/django/contrib/admin/templates/admin/delete_confirmation.html  
2011-06-04 21:51:13 UTC (rev 16330)
@@ -32,7 +32,7 @@
 {% else %}
 {% blocktrans with object as escaped_object %}Are you sure you want to 
delete the {{ object_name }} "{{ escaped_object }}"? All of the following 
related items will be deleted:{% endblocktrans %}
 {{ deleted_objects|unordered_list }}
-{% csrf_token %}
+{% csrf_token %}
 
 
 

Modified: 
django/trunk/django/contrib/admin/templates/admin/delete_selected_confirmation.html
===
--- 
django/trunk/django/contrib/admin/templates/admin/delete_selected_confirmation.html
 2011-06-04 21:42:53 UTC (rev 16329)
+++ 
django/trunk/django/contrib/admin/templates/admin/delete_selected_confirmation.html
 2011-06-04 21:51:13 UTC (rev 16330)
@@ -33,7 +33,7 @@
 {% for deletable_object in deletable_objects %}
 {{ deletable_object|unordered_list }}
 {% endfor %}
-{% csrf_token %}
+{% csrf_token %}
 
 {% for obj in queryset %}
 

Modified: django/trunk/django/contrib/admin/templates/admin/search_form.html
===
--- django/trunk/django/contrib/admin/templates/admin/search_form.html  
2011-06-04 21:42:53 UTC (rev 16329)
+++ django/trunk/django/contrib/admin/templates/admin/search_form.html  
2011-06-04 21:51:13 UTC (rev 16330)
@@ -1,7 +1,7 @@
 {% load adminmedia %}
 {% load i18n %}
 {% if cl.search_fields %}
-
+
 
 
 

Modified: 
django/trunk/django/contrib/admin/templates/registration/password_change_form.html
===
--- 
django/trunk/django/contrib/admin/templates/registration/password_change_form.html
  2011-06-04 21:42:53 UTC (rev 16329)
+++ 
django/trunk/django/contrib/admin/templates/registration/password_change_form.html
  2011-06-04 21:51:13 UTC (rev 16330)
@@ -9,7 +9,7 @@
 
 {% block content %}
 
-{% csrf_token %}
+{% csrf_token %}
 
 {% if form.errors %}
 

Modified: 
django/trunk/django/contrib/admin/templates/registration/password_reset_confirm.html
===
--- 
django/trunk/django/contrib/admin/templates/registration/password_reset_confirm.html
2011-06-04 21:42:53 UTC (rev 16329)
+++ 
django/trunk/django/contrib/admin/templates/registration/password_reset_confirm.html
2011-06-04 21:51:13 UTC (rev 16330)
@@ -13,7 +13,7 @@
 
 {% trans "Please enter your new password twice so we can verify you typed 
it in correctly." %}
 
-{% csrf_token %}
+{% csrf_token %}
 {{ form.new_password1.errors }}
 {% trans 'New password:' 
%}{{ form.new_password1 }}
 {{ form.new_password2.errors }}

Modified: 
django/trunk/django/contrib/admin/templates/registration/password_reset_form.html
===
--- 
django/trunk/django/contrib/admin/templates/registration/password_reset_form.html
   2011-06-04 21:42:53 UTC (rev 16329)
+++ 
django/trunk/django/contrib/admin/templates/registration/password_reset_form.html
   2011-06-04 21:51:13 UTC (rev 16330)
@@ -11,7 +11,7 @@
 
 {% trans "Forgotten your password? Enter your e-mail address below, and 
we'll e-mail instructions for setting a new one." %}
 
-{% csrf_token %}
+{% csrf_token %}
 {{ form.email.errors }}
 {% trans 'E-mail address:' %} {{ form.email 
}} 
 

Modified: django/trunk/django/contrib/formtools/templates/formtools/form.html
===
--- django/trunk/django/contrib/formtools/templates/formtools/form.html 
2011-06-04 21:42:53 UTC (rev 16329)
+++ django/trunk/django/contrib/formtools/templates/formtools/form.html 
2011-06-04 21:51:13 UTC (rev 16330)
@@ -4,7 +4,7 @@
 
 {% if form.errors %}Please 

Re: [Django] #16154: r16051 broke editing a filtered changelist

[Django]

#16154: r16051 broke editing a filtered changelist
+-
   Reporter:  kmtracey  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Release blocker
 Resolution:|   Keywords:  regression dataloss
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+-

Comment (by lukeplant):

 In [16330]:
 {{{
 #!CommitTicketReference repository="" revision="16330"
 Reverted most of [16051], because it was thoroughly incorrect (whatever
 some validator says)

 Refs #16154
 }}}

-- 
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] r16329 - django/trunk/docs/topics/forms

[noreply]

Author: timo
Date: 2011-06-04 14:42:53 -0700 (Sat, 04 Jun 2011)
New Revision: 16329

Modified:
   django/trunk/docs/topics/forms/modelforms.txt
Log:
Fixed #15990 - Simplified a sentence regarding form validation for ModelForms; 
thanks jblaine for the suggestion.

Modified: django/trunk/docs/topics/forms/modelforms.txt
===
--- django/trunk/docs/topics/forms/modelforms.txt   2011-06-04 17:05:38 UTC 
(rev 16328)
+++ django/trunk/docs/topics/forms/modelforms.txt   2011-06-04 21:42:53 UTC 
(rev 16329)
@@ -195,14 +195,11 @@
 The ``is_valid()`` method and ``errors``
 
 
-.. versionchanged:: 1.2
-
 The first time you call ``is_valid()`` or access the ``errors`` attribute of a
-``ModelForm`` has always triggered form validation, but as of Django 1.2, it
-will also trigger :ref:`model validation `. This has the
-side-effect of cleaning the model you pass to the ``ModelForm`` constructor.
-For instance, calling ``is_valid()`` on your form will convert any date fields
-on your model to actual date objects.
+``ModelForm`` triggers form validation as well as :ref:`model validation
+`. This has the side-effect of cleaning the model you pass
+to the ``ModelForm`` constructor. For instance, calling ``is_valid()`` on your
+form will convert any date fields on your model to actual date objects.
 
 
 The ``save()`` method
@@ -359,7 +356,7 @@
 -
 
 .. versionadded:: 1.2
-   The ``widgets`` attribute is new in Django 1.2.
+The ``widgets`` attribute is new in Django 1.2.
 
 The default field types, as described in the `Field types`_ table above, are
 sensible defaults. If you have a ``DateField`` in your model, chances are you'd

-- 
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:  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:  new => closed
 * resolution:   => fixed


Comment:

 In [16329]:
 {{{
 #!CommitTicketReference repository="" revision="16329"
 Fixed #15990 - Simplified a sentence regarding form validation for
 ModelForms; thanks jblaine for the suggestion.
 }}}

-- 
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 timo):

 Since we should technically be removing the versionadded/changed tags that
 reference 1.2 in the 1.4 docs, I'm going to remove the reference to Django
 1.2 here which will simplify 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.

Re: [Django] #16154: r16051 broke editing a filtered changelist

[Django]

#16154: r16051 broke editing a filtered changelist
+-
   Reporter:  kmtracey  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Release blocker
 Resolution:|   Keywords:  regression dataloss
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+-

Comment (by lukeplant):

 Gulp, my bad, sorry. I had no idea that action="" and action="." meant
 different things, but I ought to have. Looking at
 [http://www.ietf.org/rfc/rfc1808.txt RFC 1808] (see sections 5.1 and 5.2,
 and 4.2.a), they are indeed different, and the browser is doing what it is
 supposed to do. It is possible the validator was just incorrect, and it
 should be ignored anyway, given that an empty action is the only way to
 post back to exactly the same URL.

 So we should be reverting much more of [16051] - almost all apart from the
 obsolete 'cellspacing' attribute.

 There is, of course, another bug here - it shouldn't be possible for the
 edit to affect rows that were not specifically selected, even if the
 queryset returns more objects than it did before, which is entirely
 possible is someone else has changed the data in the database in the mean
 time. I'm sure there is a separate ticket about this, but I can't find it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #3624: Syndication could be friendlier to non Django templating languages

[Django]

#3624: Syndication could be friendlier to non Django templating languages
-+-
   Reporter:  andy@… |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  contrib.syndication
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Someday/Maybe  |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by melinath):

 * status:  new => closed
 * version:  1.0 => SVN
 * resolution:   => fixed
 * easy:   => 0


Comment:

 The methods described above were added with changeset r12338, which moved
 syndication to class-based views. This means that anyone who wants to use
 an alternate template language can just override the method and do
 whatever they want.

-- 
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] #15279: Inheritance of rel fields from a single abstract base class through multiple abstract classes causes errors.

[Django]

#15279: Inheritance of rel fields from a single abstract base class through
multiple abstract classes causes errors.
-+-
   Reporter:  melinath   |  Owner:  melinath
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (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 melinath):

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


Comment:

 This version of the patch works a lot better. The tests actually test
 things, and the behavior is more consistent. However, I'm starting to
 wonder if this is really the way to go about this. I feel like I'm
 constantly struggling against the way that Options keeps track of fields.
 For example, I had to add code to the _fill_x_cache methods on Options to
 eliminate duplication there, because options.add_field isn't called for
 inherited fields. This makes sense, generally, since in the past, fields
 have not known what models they were attached to. However, since this
 patch introduces field-based tracking of both the model the field was
 first declared on and the first concrete model the field was present on,
 it would be possible to take that farther. Options could add every field
 on the model to a cache, then dish out local fields or inherited fields
 based on whether the options' model is the same as the first concrete
 model for the field.

 However, a change like that would be fairly invasive and far beyond the
 scope of this patch, nor am I convinced that it is the best course of
 action in terms of efficiency.

-- 
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] #16154: r16051 broke editing a filtered changelist

[Django]

#16154: r16051 broke editing a filtered changelist
+-
   Reporter:  kmtracey  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Release blocker
 Resolution:|   Keywords:  regression dataloss
   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


-- 
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] #16154: r16051 broke editing a filtered changelist

[Django]

#16154: r16051 broke editing a filtered changelist
-+-
   Reporter:  kmtracey   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:  regression dataloss
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by kmtracey):

 For now I have undone part of r16051 -- the change list form -- in order
 to get a fix in for the dataloss problem. I'm not sure what the right fix
 is long-term and I don't know if any of the other forms changed are
 subject to the same problem, but while we investigate that I'd like to
 make sure that continued data corruption of the type I've observed is
 prevented.

-- 
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] #16155: Drop support for Python 2.4

[Django]

#16155: Drop support for Python 2.4
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |Component:
Milestone:  1.4  |  Documentation
  Version:  1.3  | Severity:  Release
 Keywords:   |  blocker
Has patch:  1| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
-+-
 Support for Python 2.4 will be dropped in Django 1.4.

 Attached patch updates the documentations wherever necessary and removes
 some dead code (ie. code that is unreachable in Python > 2.4).

 Notes:

 - I haven't touched backwards compatibility in code in
 `django/test/_doctest.py` and `django/util/unittest/loader.py` because I
 prefer staying as close as possible to the standard library's version.
 - I haven't removed `django/utils/copycompat.py` and
 `django/utils/hashcompat.py` because some third-party apps may be using
 these models.
 - `django/db/models/base.py` mentions a "__deepcopy__ problem in Python
 2.4"; the code could probably be simplified now, but if it ain't broken,
 don't fix it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16154: r16051 broke editing a filtered changelist

[Django]

#16154: r16051 broke editing a filtered changelist
-+-
   Reporter:  kmtracey   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:  regression dataloss
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by kmtracey):

 In [16328]:
 {{{
 #!CommitTicketReference repository="" revision="16328"
 Undo part of r16051 to avoid dataloss bug. Refs #16154.
 }}}

-- 
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] r16328 - django/trunk/django/contrib/admin/templates/admin

[noreply]

Author: kmtracey
Date: 2011-06-04 10:05:38 -0700 (Sat, 04 Jun 2011)
New Revision: 16328

Modified:
   django/trunk/django/contrib/admin/templates/admin/change_list.html
Log:
Undo part of r16051 to avoid dataloss bug. Refs #16154.


Modified: django/trunk/django/contrib/admin/templates/admin/change_list.html
===
--- django/trunk/django/contrib/admin/templates/admin/change_list.html  
2011-06-04 15:31:41 UTC (rev 16327)
+++ django/trunk/django/contrib/admin/templates/admin/change_list.html  
2011-06-04 17:05:38 UTC (rev 16328)
@@ -87,7 +87,7 @@
 {% endif %}
   {% endblock %}
 
-  {% 
csrf_token %}
+  {% 
csrf_token %}
   {% if cl.formset %}
 {{ cl.formset.management_form }}
   {% endif %}

-- 
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] #16154: r16051 broke editing a filtered changelist

[Django]

#16154: r16051 broke editing a filtered changelist
-+-
 Reporter:  kmtracey |Owner:  nobody
 Type:  Bug  |   Status:  new
Milestone:   |Component:
  Version:  1.3  |  contrib.admin
 Keywords:  regression dataloss  | Severity:  Release
Has patch:  0|  blocker
  Needs tests:  0| Triage Stage:
Easy pickings:  0|  Unreviewed
 |  Needs documentation:  0
 |  Patch needs improvement:  0
-+-
 r16051 changed a bunch of form actions in the admin from `action=""` to
 `action="."`. I have noticed a side-effect of this change is that editing
 a filtered changelist is now broken: the edit can affect rows other then
 the ones intended. Looking at the dev server logging for the change list
 edit POST, with r16050 I see:

 {{{
 [04/Jun/2011 12:24:25] "POST /admin/ctrac/cat/?avail__exact=1 HTTP/1.1"
 302 0
 }}}

 whereas with r16051 I see:

 {{{
 [04/Jun/2011 12:20:50] "POST /admin/ctrac/cat/ HTTP/1.1" 302 0
 }}}

 The change list filtering information is no longer being sent with the
 POST, and as a result the queryset used to process the POSTed edit doesn't
 match the original queryset that was used to construct the filtered change
 list for display. The effect that I have seen, without completely tracking
 down how it is happening, is that rows other than the filtered ones are
 being changed by the change list edit. For affected objects that should
 not have been affected I see messages in their history like:

 {{{
 Changed avail and id.
 }}}

 Although id was not actually changed -- I think that's an indication that
 the hidden id field for the object didn't match up with the value in the
 queryset used by POST...but the admin went ahead and changed the other
 data (avail) anyway.

-- 
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] #16150: Syndication Feed docs incorrectly describe tag.

[Django]

#16150: Syndication Feed docs incorrectly describe  tag.
+---
   Reporter:  melinath  |  Owner:  melinath
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  rss
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
+---
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * 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 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] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  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:  1|  Easy pickings:  0
---+---

Comment (by jezdez):

 Understood, but this is definitely a separate feature, so please open a
 new ticket and remove it from this 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.

[Changeset] r16327 - django/branches/releases/1.3.X/django/utils

[noreply]

Author: kmtracey
Date: 2011-06-04 08:31:41 -0700 (Sat, 04 Jun 2011)
New Revision: 16327

Modified:
   django/branches/releases/1.3.X/django/utils/autoreload.py
Log:
[1.3.X] Fix #15880: Prevent "stalling" when running dev server in background by 
ignoring SIGTTOU for the duration of tcsetattr.

Backport of [16326] from trunk.

Modified: django/branches/releases/1.3.X/django/utils/autoreload.py
===
--- django/branches/releases/1.3.X/django/utils/autoreload.py   2011-06-04 
15:29:11 UTC (rev 16326)
+++ django/branches/releases/1.3.X/django/utils/autoreload.py   2011-06-04 
15:31:41 UTC (rev 16327)
@@ -28,7 +28,7 @@
 # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
-import os, sys, time
+import os, sys, time, signal
 
 try:
 import thread
@@ -78,7 +78,13 @@
 attr_list = termios.tcgetattr(fd)
 if not attr_list[3] & termios.ECHO:
 attr_list[3] |= termios.ECHO
+if hasattr(signal, 'SIGTTOU'):
+old_handler = signal.signal(signal.SIGTTOU, signal.SIG_IGN)
+else:
+old_handler = None
 termios.tcsetattr(fd, termios.TCSANOW, attr_list)
+if old_handler is not None:
+signal.signal(signal.SIGTTOU, old_handler)
 
 def reloader_thread():
 ensure_echo_on()

-- 
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:  fixed  |   Keywords:  regression
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by kmtracey):

 In [16327]:
 {{{
 #!CommitTicketReference repository="" revision="16327"
 [1.3.X] Fix #15880: Prevent "stalling" when running dev server in
 background by ignoring SIGTTOU for the duration of tcsetattr.

 Backport of [16326] 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] #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:  fixed  |   Keywords:  regression
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by kmtracey):

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


Comment:

 In [16326]:
 {{{
 #!CommitTicketReference repository="" revision="16326"
 Fix #15880: Prevent "stalling" when running dev server in background by
 ignoring SIGTTOU for the duration of tcsetattr.
 }}}

-- 
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] r16326 - django/trunk/django/utils

[noreply]

Author: kmtracey
Date: 2011-06-04 08:29:11 -0700 (Sat, 04 Jun 2011)
New Revision: 16326

Modified:
   django/trunk/django/utils/autoreload.py
Log:
Fix #15880: Prevent "stalling" when running dev server in background by 
ignoring SIGTTOU for the duration of tcsetattr.

Modified: django/trunk/django/utils/autoreload.py
===
--- django/trunk/django/utils/autoreload.py 2011-06-04 14:39:16 UTC (rev 
16325)
+++ django/trunk/django/utils/autoreload.py 2011-06-04 15:29:11 UTC (rev 
16326)
@@ -28,7 +28,7 @@
 # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
-import os, sys, time
+import os, sys, time, signal
 
 try:
 import thread
@@ -78,7 +78,13 @@
 attr_list = termios.tcgetattr(fd)
 if not attr_list[3] & termios.ECHO:
 attr_list[3] |= termios.ECHO
+if hasattr(signal, 'SIGTTOU'):
+old_handler = signal.signal(signal.SIGTTOU, signal.SIG_IGN)
+else:
+old_handler = None
 termios.tcsetattr(fd, termios.TCSANOW, attr_list)
+if old_handler is not None:
+signal.signal(signal.SIGTTOU, old_handler)
 
 def reloader_thread():
 ensure_echo_on()

-- 
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:  reopened
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:  regression
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by kmtracey):

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


Comment:

 Re-opening to fix the stalling issue. Since no one has commented with any
 ideas for a better approach, I'll use the previously-posted 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.

[Changeset] r16325 - django/branches/releases/1.3.X/docs/topics/db

[noreply]

Author: timo
Date: 2011-06-04 07:39:16 -0700 (Sat, 04 Jun 2011)
New Revision: 16325

Modified:
   django/branches/releases/1.3.X/docs/topics/db/managers.txt
Log:
[1.3.X] Fixed #16145 - typo in manager docs; thanks leereilly.

Backport of r16324 from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/db/managers.txt
===
--- django/branches/releases/1.3.X/docs/topics/db/managers.txt  2011-06-04 
14:38:45 UTC (rev 16324)
+++ django/branches/releases/1.3.X/docs/topics/db/managers.txt  2011-06-04 
14:39:16 UTC (rev 16325)
@@ -371,9 +371,9 @@
 Set ``use_for_related_fields`` when you define the class
 
 
-The ``use_for_related_fields`` attribute must be set on the manager *class*,
-object not on an *instance* of the class. The earlier example shows the
-correct way to set it, whereas the following will not work::
+The ``use_for_related_fields`` attribute must be set on the manager *class*, 
not
+on an *instance* of the class. The earlier example shows the correct way to set
+it, whereas the following will not work::
 
 # BAD: Incorrect code
 class MyManager(models.Manager):

-- 
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] #16145: Typo in docs/topics/db/managers.txt

[Django]

#16145: Typo in docs/topics/db/managers.txt
-+-
   Reporter:  lee@…  |  Owner:  leereilly
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by timo):

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


Comment:

 In [16324]:
 {{{
 #!CommitTicketReference repository="" revision="16324"
 Fixed #16145 - typo in manager docs; thanks leereilly.
 }}}

-- 
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] r16324 - django/trunk/docs/topics/db

[noreply]

Author: timo
Date: 2011-06-04 07:38:45 -0700 (Sat, 04 Jun 2011)
New Revision: 16324

Modified:
   django/trunk/docs/topics/db/managers.txt
Log:
Fixed #16145 - typo in manager docs; thanks leereilly.

Modified: django/trunk/docs/topics/db/managers.txt
===
--- django/trunk/docs/topics/db/managers.txt2011-06-04 14:32:55 UTC (rev 
16323)
+++ django/trunk/docs/topics/db/managers.txt2011-06-04 14:38:45 UTC (rev 
16324)
@@ -371,9 +371,9 @@
 Set ``use_for_related_fields`` when you define the class
 
 
-The ``use_for_related_fields`` attribute must be set on the manager *class*,
-object not on an *instance* of the class. The earlier example shows the
-correct way to set it, whereas the following will not work::
+The ``use_for_related_fields`` attribute must be set on the manager *class*, 
not
+on an *instance* of the class. The earlier example shows the correct way to set
+it, whereas the following will not work::
 
 # BAD: Incorrect code
 class MyManager(models.Manager):

-- 
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] r16323 - django/trunk/tests/regressiontests/templates

[noreply]

Author: lukeplant
Date: 2011-06-04 07:32:55 -0700 (Sat, 04 Jun 2011)
New Revision: 16323

Modified:
   django/trunk/tests/regressiontests/templates/loaders.py
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Fixed import error that was causing EggLoader tests not to be run

Also improved ImportError handling that was causing this fact to be missed.

Modified: django/trunk/tests/regressiontests/templates/loaders.py
===
--- django/trunk/tests/regressiontests/templates/loaders.py 2011-06-03 
13:43:23 UTC (rev 16322)
+++ django/trunk/tests/regressiontests/templates/loaders.py 2011-06-04 
14:32:55 UTC (rev 16323)
@@ -17,7 +17,6 @@
 import warnings
 
 from django.template import TemplateDoesNotExist, Context
-from django.template.loaders.eggs import load_template_source as lts_egg
 from django.template.loaders.eggs import Loader as EggLoader
 from django.template import loader
 from django.test.utils import get_warnings_state, restore_warnings_state

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2011-06-03 
13:43:23 UTC (rev 16322)
+++ django/trunk/tests/regressiontests/templates/tests.py   2011-06-04 
14:32:55 UTC (rev 16323)
@@ -37,8 +37,11 @@
 
 try:
 from loaders import *
-except ImportError:
-pass # If setuptools isn't installed, that's fine. Just move on.
+except ImportError, e:
+if "pkg_resources" in e.message:
+pass # If setuptools isn't installed, that's fine. Just move on.
+else:
+raise
 
 import filters
 

-- 
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] #7704: JS comments put after statements break make-messages.py output

[Django]

#7704: JS comments put after statements break make-messages.py output
-+-
   Reporter:  robbyd |  Owner:  nedbatchelder
   Type:  Bug| Status:  assigned
  Milestone: |  Component:
Version:  1.0|  Internationalization
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  djangojs, make-
Needs documentation:  0  |  messages
Patch needs improvement:  1  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by anonymous):

 * easy:  0 => 1


-- 
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] #7704: JS comments put after statements break make-messages.py output

[Django]

#7704: JS comments put after statements break make-messages.py output
-+-
   Reporter:  robbyd |  Owner:  nedbatchelder
   Type:  Bug| Status:  assigned
  Milestone: |  Component:
Version:  1.0|  Internationalization
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  djangojs, make-
Needs documentation:  0  |  messages
Patch needs improvement:  1  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by ionel.mc@…):

 * cc: ionel.mc@… (added)
 * easy:   => 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] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  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:  1|  Easy pickings:  0
---+---

Comment (by burzak):

 jedez, apollo13: The idea of the crumbs block is to avoid many url
 repetition. Inside of many template there are many urls defines on
 breadcrumbs block. When you extend these templates to add some link in
 breadcrumb block, you have to include the urls defines in the template you
 are extending of. With crumbs block you only add the link you want and
 that's it.

 PS: Sorry for my English.

-- 
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] #14370: Adding support for Autocomplete in contrib.admin

[Django]

#14370: Adding support for Autocomplete in contrib.admin
-+-
   Reporter:  tyrion |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  autocomplete,
 Resolution: |  jquery, javascript, widgets, admin
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by haras):

 * cc: djangoproject.com@… (added)
 * easy:   => 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] #4592: Make CheckboxSelectMultiple more like RadioSelect

[Django]

#4592: Make CheckboxSelectMultiple more like RadioSelect
+-
   Reporter:  Scott Sinclair|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Milestone:|  Component:  Forms
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  feature
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
+-
Changes (by lupino):

 * easy:   => 0


Comment:

 Furthermore, I'd like to add that the current hard-coded output is not
 consistent with the output of someform.as_ul, which renders checkboxes
 like

 {{{
 Blubb: 
 }}}
 whereas the format of the list elements in CheckboxSelectMultiple is
 {{{
  Blubb 
 }}}

-- 
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] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  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:  1|  Easy pickings:  0
---+---

Comment (by apollo13):

 I agree, wasn't in my inital patch either. Ramiro: any objections against
 removing that again? I there is a compelling reason we could do {% block
 breadcrumbs %}{% block crumbs %} in the base template I guess…

-- 
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] #1028: High-level feed framework should make more feed elements available

[Django]

#1028: High-level feed framework should make more feed elements available
-+-
   Reporter: |  Owner:  taojian
  ubernostrum| Status:  new
   Type:  New|  Component:  contrib.syndication
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.2-alpha  |  Has patch:  1
 Resolution: |Needs tests:  1
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
-+-
Changes (by herve leger replica):

 * needs_tests:  0 => 1
 * easy:   => 0


Comment:

 point, and it is water-resistant at 50 meters. This Seiko http://www.topedhardycloting.com/collection/ed-hardy-
 mens.html">Mens timepiece sports a real mother of pearl dial
 that's also http://www.topedhardycloting.com;>ed hardy knock
 offs point, and it is water-resistant at 50 meters. This Seiko
 http://www.wholesaletiffanyoutlets.com;>tiffany
 replica timepiece sports a real mother of pearl dial that's also
 http://www.wholesaletiffanyoutlets.com;>wholesale only
 jewelry point, and it is water-resistant at 50 meters. This Seiko
 http://www.designersbrianatwood.com;>christian louboutin
 claudia replica timepiece sports a real mother of pearl dial
 that's also http://www.designersbrianatwood.com;>wholesale
 louboutin point, and it is water-resistant at 50 meters. This
 Seiko http://www.louboutinhelsuksale.com;>high heel
 timepiece sports a real mother of pearl dial that's also http://www.louboutinhelsuksale.com;>tory burch reva

-- 
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.