[Django] #16838: First InlineModelAdmin not displaying "Add Another" link

[Django]

#16838: First InlineModelAdmin not displaying "Add Another" link
+---
 Reporter:  jamesp  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  contrib.admin
  Version:  SVN |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 The first InlineModelAdmin displayed in a ModelAdmin subclass does not
 show the "Add Another" link.

 The admin HTML code that gets generated for inlines appears to be
 inconsistent (for example, the generated HTML has {{{id="id_MAX_FORMS"}}}
 while the inlines jQuery is looking for {{{#id_-MAX_FORMS}}}).

-- 
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] #13956: Indefinite args for simpletags and inclusion tags

[Django]

#13956: Indefinite args for simpletags and inclusion tags
-+-
   Reporter:  melinath   |  Owner:  julien
   Type:  New| Status:  new
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  simple_tag,
 Resolution: |  simpletag
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by julien):

 * owner:  melinath => julien
 * stage:  Design decision needed => Accepted


Comment:

 I'm working on this.

-- 
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] #16829: sitemap for static views

[Django]

#16829: sitemap for static views
---+---
   Reporter:  madisv   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:  views sitemap
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by carljm):

 * needs_better_patch:   => 0
 * component:  contrib.sitemaps => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 I don't think this code needs to be in Django, but the sitemaps
 documentation could benefit from an example like this showing how to add
 static views to a sitemap.

-- 
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] #16803: Unicode representation of ContentType instances is not translated

[Django]

#16803: Unicode representation of ContentType instances is not translated
+--
   Reporter:  bronger   |  Owner:  isagalaev
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  contrib.contenttypes
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
  UI/UX:  0 |
+--
Changes (by isagalaev):

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


Comment:

 I was thinking along those lines too :-). I think I could make a 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] #14434: AdminSite should rely on self.has_permission for all permission checks (was: AdminSite should check self.has_permission in self.login)

[Django]

#14434: AdminSite should rely on self.has_permission for all permission checks
+---
   Reporter:  bkonkle   |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:  admin views
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by SmileyChris):

 * needs_better_patch:  0 => 1
 * type:  Uncategorized => Bug
 * needs_tests:  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] #16773: QuerySet.count does no caching until the result cache is filled

[Django]

#16773: QuerySet.count does no caching until the result cache is filled
-+-
   Reporter: |  Owner:  nobody
  eternicode | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution:  wontfix|   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

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


Comment:

 Yes, the comments here are correct. Just caching counts will result in
 incorrect numbers, and adding post_save and post_delete handlers to core
 just to address this is swatting a gnat with a sledgehammer (and won't
 entirely fix the problem, either - bulk deletes and updates don't send
 those signals).

 If you're really calling .count() so many times on the same unevaluated
 queryset that this is an issue, it's easy to cache the count in your own
 code. Or you can create your own queryset subclass that caches counts, and
 deal with the problems this causes.

-- 
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] #14434: AdminSite should check self.has_permission in self.login

[Django]

#14434: AdminSite should check self.has_permission in self.login
-+---
   Reporter:  bkonkle|  Owner:  nobody
   Type:  Uncategorized  | Status:  reopened
  Milestone: |  Component:  contrib.admin
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:  admin views
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by danny.adair@…):

 * status:  closed => reopened
 * severity:   => Normal
 * type:   => Uncategorized
 * easy:   => 0
 * ui_ux:   => 0
 * resolution:  fixed =>


Comment:

 I don't believe this has been fully resolved.
 Even when AdminSite.has_permission() is overridden, it won't lead to the
 expected effect:

 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/forms.py#L40
 and
 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/templates/admin/base.html#L26

 still do explicit "is_staff" checks.

 See also
 http://stackoverflow.com/questions/4022551/how-to-make-django-admin-site-
 accessed-by-non-staff-user/5573686#5573686

-- 
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] #16803: Unicode representation of ContentType instances is not translated

[Django]

#16803: Unicode representation of ContentType instances is not translated
+--
   Reporter:  bronger   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.contenttypes
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
  UI/UX:  0 |
+--
Changes (by carljm):

 * stage:  Design decision needed => Accepted


Comment:

 I don't see any good reason why `ContentType` should have a denormalized
 name field stored in the database, rather than looking up the appropriate
 model `verbose_name` at runtime - its not as if the latter is an expensive
 operation, and translation is a real problem with the current approach.

 I think we can make this fix in a backwards-compatible way. The
 `__unicode__` method can check if the name field is equal to the model's
 `verbose_name_raw` (i.e. hasn't been manually changed), and if so look up
 the real `verbose_name` (possibly translated) and return that. If the name
 field has been changed, return it. This still leaves open the possibility
 that in the future (once we have a schema-alteration framework in core) we
 could deprecate and then remove the name field entirely.

 In the meantime, there's also a workaround that I think can help
 multilingual sites: on `ModelForm`s for models with an FK to
 `ContentType`, you can replace the form field for that FK with a subclass
 of `ModelChoiceField` that overrides the `label_for_instance` method to do
 the translated `verbose_name` lookup. This
 
[https://docs.djangoproject.com/en/dev/ref/forms/fields/#django.forms.ModelChoiceField
 is documented]; it's fairly verbose (which is why I'm not simply pointing
 to it and closing this wontfix), but it should do the trick for the time
 being.

-- 
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] #15619: Logout link should be protected

[Django]

#15619: Logout link should be protected
+
   Reporter:  void  |  Owner:  ashchristopher
   Type:  Bug   | Status:  assigned
  Milestone:  1.4   |  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
  UI/UX:  0 |
+
Changes (by ashchristopher):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16803: Unicode representation of ContentType instances is not translated

[Django]

#16803: Unicode representation of ContentType instances is not translated
-+-
   Reporter:  bronger|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:
Version:  1.3|  contrib.contenttypes
 Resolution: |   Severity:  Normal
   Triage Stage:  Design |   Keywords:
  decision needed|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by isagalaev):

 * stage:  Unreviewed => Design decision needed


Comment:

 First, I was wrong that the field {{{name}}} is technical. Quite the
 opposite, it's intended to be a human-readable representation. So the
 simplest solution to your use-case is changing the {{{name}}} to whatever
 you want. However this won't work in a multilingual environment since the
 field's content cannot be translated (at the moment).

 I've conducted a little research. {{{ContentType.name}}} is initialized
 with model's untranslated verbose name — {{{verbose_name_raw}}}, a
 property which was introduced in [5225] specifically for the purpose of
 using for content types. I don't know why it was done this way. It might
 be a good idea to change this to using a usual translated verbose names of
 a model but it's technically backwards incompatible.

 I'm marking this as DDN to get an opinion of a core developer. To
 summarize:

 * {{{ContentType}}} uses a dedicated field for its human-readable
 representation. The idea is to use real verbose names of models.
 * Good: {{{ContentType}}}s will become translatable
 * Good: code around {{{verbose_name_raw}}} will go away
 * Bad: it's technically backwards incompatible: users might be changing
 and relying on {{{ContentType.name}}}

 My own take would be to go for a change since I doubt
 {{{ContentType.name}} is widely used **and** is different from
 {{{verbose_name}}} of a model. Most probably we will even save maintenance
 for people who routinely change names of content type according to model's
 verbose names.

-- 
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] #16773: QuerySet.count does no caching until the result cache is filled

[Django]

#16773: QuerySet.count does no caching until the result cache is filled
-+-
   Reporter: |  Owner:  nobody
  eternicode | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by eternicode):

 * stage:  Unreviewed => Design decision needed


-- 
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] #16773: QuerySet.count does no caching until the result cache is filled

[Django]

#16773: QuerySet.count does no caching until the result cache is filled
-+-
   Reporter: |  Owner:  nobody
  eternicode | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by eternicode):

 * stage:  Design decision needed => Unreviewed


Comment:

 tarequeh, good points.  I knew there were cases like these that I just
 wasn't thinking of.

 Seems the create/delete could be solved with post_save and post_delete
 signal handlers, respectively, that clear the count cache.  That's
 probably overkill, though, and maybe even approaching the realm of custom
 code for a specific purpose.

-- 
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] #16837: when logging in into the admin

[Django]

#16837: when logging in into the admin
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  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:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 I think this is in principle a good compromise. The suggested patch feels
 a bit dry though, and could be improved. We don't want to lose the "Note
 that both fields are case-sensitive." tip either. Please also add some
 tests.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16837: when logging in into the admin

[Django]

#16837: when logging in into the admin
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by Wim Feijen ):

 * needs_better_patch:  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] #16837: when logging in into the admin

[Django]

#16837: when logging in into the admin
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by Wim Feijen ):

 Tests fail - need update

-- 
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] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
---+---
   Reporter:  lrekucki |  Owner:  lrekucki
   Type:  New feature  | Status:  reopened
  Milestone:  1.4  |  Component:  Generic views
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  class-based-views
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by ptone):

 * needs_better_patch:  0 => 1


Comment:

 your latest patch only has the tests - it is not a complete patch, I'm
 pretty sure patches should not be compound patches here.

-- 
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] #16837: when logging in into the admin

[Django]

#16837: when logging in into the admin
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Wim Feijen ):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * 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.

[Django] #16837: when logging in into the admin

[Django]

#16837: when logging in into the admin
+---
 Reporter:  Wim Feijen   |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  contrib.admin
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  1
UI/UX:  0   |
+---
 When a user tries to login on the admin, with correct username &
 password, but is_staff is set to False, the error message is
 misleadingly wrong:
 "Please enter a correct username and password. Note that both fields
 are case-sensitive."

 After discussion on django-developers:
 http://groups.google.com/group/django-
 developers/browse_thread/thread/c070dcd878a75a2b

 a solution was proposed to have a general message in all cases, so
 potential attackers cannot distinguish between the case where
 username are right and is_staff = False versus the case where
 username don't fit.

 The message is:

 "Username and password incorrect or access to this page is restricted".

 as proposed by Adam Jenkins, with an added "is".

 Although the global variable ERROR_MESSAGE does not seem to be used
 anywhere else in django, I'll keep it as it is for now.

 Gentlemen and ladies, now we need translations.

 Wim

-- 
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] #7557: ValueError does not catch all cases when trying to determine type of variable in template.Variable class

[Django]

#7557: ValueError does not catch all cases when trying to determine type of
variable in template.Variable class
---+-
   Reporter:  tobias   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Template system
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
  UI/UX:  0|
---+-
Changes (by Alex):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 Marking as accepted, but this patch is wrong, Variable's constructor takes
 a basestring, and nothing else, we should just typecheck the input IMO.

-- 
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] r16826 - django/trunk/django/contrib/gis/db/backends/postgis

[noreply]

Author: jbronn
Date: 2011-09-13 13:43:33 -0700 (Tue, 13 Sep 2011)
New Revision: 16826

Modified:
   django/trunk/django/contrib/gis/db/backends/postgis/adapter.py
Log:
Fixed #16778 -- Improved escaping of geometries on PostgreSQL, allowing 
GeoDjango to work on 9.1.  Thanks, piro for ticket and patch.

Modified: django/trunk/django/contrib/gis/db/backends/postgis/adapter.py
===
--- django/trunk/django/contrib/gis/db/backends/postgis/adapter.py  
2011-09-13 20:30:24 UTC (rev 16825)
+++ django/trunk/django/contrib/gis/db/backends/postgis/adapter.py  
2011-09-13 20:43:33 UTC (rev 16826)
@@ -12,6 +12,7 @@
 # the adaptor) and the SRID from the geometry.
 self.ewkb = str(geom.ewkb)
 self.srid = geom.srid
+self._adapter = Binary(self.ewkb)
 
 def __conform__(self, proto):
 # Does the given protocol conform to what Psycopg2 expects?
@@ -28,10 +29,17 @@
 def __str__(self):
 return self.getquoted()
 
+def prepare(self, conn):
+"""
+This method allows escaping the binary in the style required by the
+server's `standard_conforming_string` setting.
+"""
+self._adapter.prepare(conn)
+
 def getquoted(self):
 "Returns a properly quoted string for use in PostgreSQL/PostGIS."
-# Want to use WKB, so wrap with psycopg2 Binary() to quote properly.
-return 'ST_GeomFromEWKB(E%s)' % Binary(self.ewkb)
+# psycopg will figure out whether to use E'\\000' or '\000'
+return 'ST_GeomFromEWKB(%s)' % self._adapter.getquoted()
 
 def prepare_database_save(self, unused):
 return self

-- 
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] #16778: Bad geometry escape in postgis

[Django]

#16778: Bad geometry escape in postgis
-+
   Reporter:  piro   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  GIS
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for checkin  |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
Changes (by jbronn):

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


Comment:

 In [16826]:
 {{{
 #!CommitTicketReference repository="" revision="16826"
 Fixed #16778 -- Improved escaping of geometries on PostgreSQL, allowing
 GeoDjango to work on 9.1.  Thanks, piro for ticket 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.

[Changeset] r16825 - django/trunk/docs/ref/contrib/gis

[noreply]

Author: jbronn
Date: 2011-09-13 13:30:24 -0700 (Tue, 13 Sep 2011)
New Revision: 16825

Modified:
   django/trunk/docs/ref/contrib/gis/install.txt
Log:
Updated versions and added `libproj-dev` to the GeoDjango installation docs.

Modified: django/trunk/docs/ref/contrib/gis/install.txt
===
--- django/trunk/docs/ref/contrib/gis/install.txt   2011-09-13 15:10:49 UTC 
(rev 16824)
+++ django/trunk/docs/ref/contrib/gis/install.txt   2011-09-13 20:30:24 UTC 
(rev 16825)
@@ -75,7 +75,7 @@
     
  ==
 Program   Description   Required   
   Supported Versions
     
  ==
-:ref:`GEOS `Geometry Engine Open Source   Yes
   3.2, 3.1, 3.0
+:ref:`GEOS `Geometry Engine Open Source   Yes
   3.3, 3.2, 3.1, 3.0
 `PROJ.4`_ Cartographic Projections library  Yes 
(PostgreSQL and SQLite only)  4.7, 4.6, 4.5, 4.4
 :ref:`GDAL `Geospatial Data Abstraction Library   No (but, 
required for SQLite) 1.8, 1.7, 1.6, 1.5, 1.4
 :ref:`GeoIP `  IP-based geolocation library  No 
   1.4
@@ -139,13 +139,13 @@
 First, download GEOS 3.2 from the refractions Web site and untar the source
 archive::
 
-$ wget http://download.osgeo.org/geos/geos-3.2.2.tar.bz2
-$ tar xjf geos-3.2.2.tar.bz2
+$ wget http://download.osgeo.org/geos/geos-3.3.0.tar.bz2
+$ tar xjf geos-3.3.0.tar.bz2
 
 Next, change into the directory where GEOS was unpacked, run the configure
 script, compile, and install::
 
-$ cd geos-3.2.2
+$ cd geos-3.3.0
 $ ./configure
 $ make
 $ sudo make install
@@ -262,9 +262,9 @@
 
 First download the latest GDAL release version and untar the archive::
 
-$ wget http://download.osgeo.org/gdal/gdal-1.8.0.tar.gz
-$ tar xzf gdal-1.8.0.tar.gz
-$ cd gdal-1.8.0
+$ wget http://download.osgeo.org/gdal/gdal-1.8.1.tar.gz
+$ tar xzf gdal-1.8.1.tar.gz
+$ cd gdal-1.8.1
 
 Configure, make and install::
 
@@ -925,7 +925,7 @@
 Ubuntu 10.04 uses PostGIS 1.4, while Ubuntu 10.10 uses PostGIS 1.5 (with
 geography support).  The installation commands are::
 
-$ sudo apt-get install binutils gdal-bin postgresql-8.4-postgis \
+$ sudo apt-get install binutils gdal-bin libproj-dev 
postgresql-8.4-postgis \
  postgresql-server-dev-8.4 python-psycopg2 python-setuptools
 $ sudo easy_install Django
 

-- 
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] #10827: django.auth create_permissions must clear the content type cache before creating permissions

[Django]

#10827: django.auth create_permissions must clear the content type cache before
creating permissions
+--
   Reporter:  seanl |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.auth
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
Changes (by orb@…):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I'm having this problem too.  We worked around it by extending
 TransactionTestCase so that _pre_setup() invokes
 ContentType.objects.clear_cache().  I'd really love to see a solution to
 this.

-- 
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] #16836: can't create super-user w/ domain of localhost

[Django]

#16836: can't create super-user w/ domain of localhost
---+--
   Reporter:  sfriedman@…  |  Owner:  nobody
   Type:  Bug  | Status:  closed
  Milestone:   |  Component:  contrib.auth
Version:  1.3  |   Severity:  Normal
 Resolution:  duplicate|   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by ptone):

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


Comment:

 duplicate of #4833

-- 
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] #16788: remove import * from urls.py

[Django]

#16788: remove import * from urls.py
-+-
   Reporter:  wim@…  |  Owner:  draix
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  duplicate  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by draix):

 Oka, cool. No problem. Good news is it's fixed!

 Thanks everyone.

 Regards,
 Martin

-- 
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] #16836: can't create super-user w/ domain of localhost

[Django]

#16836: can't create super-user w/ domain of localhost
-+--
 Reporter:  sfriedman@…  |  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
UI/UX:  0|
-+--
 contrib.auth.management.commands.createsuperuser.py is_valid_email (using
 EMAIL_RE) does not allow root@localhost or root@localhost.localdomain

 The local address should be a valid address.

-- 
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] #16834: wrong error message when entering admin and not is_staff or is_active

[Django]

#16834: wrong error message when entering admin and not is_staff or is_active
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  closed
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by Wim Feijen ):

 Julien, thanks for the pointers and also for your very correct response. I
 started a discussion on the mailing list as the general consensus seems to
 be in favour of this patch.

 I'm sorry that I never seem to succeed in finding whether a ticket has
 already been posted: thanks for your response and contribution.

-- 
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] #16834: wrong error message when entering admin and not is_staff or is_active

[Django]

#16834: wrong error message when entering admin and not is_staff or is_active
-+-
   Reporter:  Wim|  Owner:  nobody
  Feijen  | Status:  closed
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 Thank you for the suggestion, but note that this has already been reported
 in #15567 and wontfixed for security reasons. It has then been discussed
 on django-dev `[1]` with diverging opinions, including from core devs. So
 I suggest you continue discussing this topic on the mailing list until a
 final resolution is reached. Closing as wontfix again for now.

 http://groups.google.com/group/django-
 developers/browse_thread/thread/df19241a0b1a04ef

-- 
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] #16832: add staticfiles lines to urls.py ,

[Django]

#16832: add staticfiles lines to urls.py ,
-+-
   Reporter:  wim@…  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by Wim Feijen ):

 Totally agree!

 I'm sorry, I misread the docs.

 Great default by the way, thanks Jannis.

-- 
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] #16830: Radioselect input loose id after invalid submission

[Django]

#16830: Radioselect input loose id after invalid submission
-+-
   Reporter:  social@…   |  Owner:  Nelson Monteiro
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:  html, radioselect,
   Triage Stage: |  forms
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 OK, thanks — I just wanted to make sure you were both the original
 reporter and the anonymous :)

-- 
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] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
   Reporter:  Manfred|  Owner:  jgelens
  Wassmann | Status:  assigned
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  dceu2011
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jonash):

 * cc: jonas-django@… (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] #5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for different fields

[Django]

#5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for
different fields
-+-
   Reporter:  ciantic@…  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  SplitDateTimeWidget
 Resolution: |  MultiWidget
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by julien):

 #10343 was also closed 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] #10343: Need a way to access widgets individually contained within a MultiWidget

[Django]

#10343: Need a way to access widgets individually contained within a MultiWidget
-+-
   Reporter: |  Owner:  nobody
  chewinggumking | Status:  closed
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:  widgets
Version:  1.0|  SplitDateTimeF
 Resolution:  duplicate  |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 This was already requested in #5851.

-- 
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] #5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for different fields

[Django]

#5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for
different fields
-+-
   Reporter:  ciantic@…  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  SplitDateTimeWidget
 Resolution: |  MultiWidget
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by julien):

 #14718 was closed as duplicate. See also #16754 for a related issue.

-- 
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] #14718: Different attributes for DateInput and TimeInput in SplitDateTimeWidget

[Django]

#14718: Different attributes for DateInput and TimeInput in SplitDateTimeWidget
-+-
   Reporter:  slink  |  Owner:  nobody
    | Status:  closed
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:  widget date time
Version:  SVN|  Has patch:  1
 Resolution:  duplicate  |Needs tests:  1
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  1  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 This is in fact a duplicate of #5851. Note that the latest suggested
 approach is to add this functionality in a more general way inside
 `MultiWidget`.

-- 
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] #16835: filter users by group

[Django]

#16835: filter users by group
+--
 Reporter:  Wim Feijen   |  Owner:  nobody
 Type:  New feature | Status:  new
Milestone:  |  Component:  contrib.auth
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  1
UI/UX:  0   |
+--
 When using groups, it is very handy to be able to filter users by group,
 in the user list in het 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] #16833: Remove obscure mixin parameter from Storage.open() method

[Django]

#16833: Remove obscure mixin parameter from Storage.open() method
-+-
   Reporter:  jezdez |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  File
  Milestone: |  uploads/storage
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16824]:
 {{{
 #!CommitTicketReference repository="" revision="16824"
 Fixed #16833 -- Removed undocumented `mixin` parameter from the
 `Storage.open()` method as this was an undocumented and obscure feature.
 Thanks to Marty and Russell for sanity-checking.
 }}}

-- 
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] r16824 - in django/trunk: django/core/files docs/releases tests/regressiontests/file_storage

[noreply]

Author: jezdez
Date: 2011-09-13 08:10:49 -0700 (Tue, 13 Sep 2011)
New Revision: 16824

Modified:
   django/trunk/django/core/files/storage.py
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/regressiontests/file_storage/tests.py
Log:
Fixed #16833 -- Removed undocumented `mixin` parameter from the 
`Storage.open()` method as this was an undocumented and obscure feature. Thanks 
to Marty and Russell for sanity-checking.

Modified: django/trunk/django/core/files/storage.py
===
--- django/trunk/django/core/files/storage.py   2011-09-13 08:22:53 UTC (rev 
16823)
+++ django/trunk/django/core/files/storage.py   2011-09-13 15:10:49 UTC (rev 
16824)
@@ -25,16 +25,11 @@
 # The following methods represent a public interface to private methods.
 # These shouldn't be overridden by subclasses unless absolutely necessary.
 
-def open(self, name, mode='rb', mixin=None):
+def open(self, name, mode='rb'):
 """
-Retrieves the specified file from storage, using the optional mixin
-class to customize what features are available on the File returned.
+Retrieves the specified file from storage.
 """
-file = self._open(name, mode)
-if mixin:
-# Add the mixin as a parent class of the File returned from 
storage.
-file.__class__ = type(mixin.__name__, (mixin, file.__class__), {})
-return file
+return self._open(name, mode)
 
 def save(self, name, content):
 """

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-09-13 08:22:53 UTC (rev 16823)
+++ django/trunk/docs/releases/1.4.txt  2011-09-13 15:10:49 UTC (rev 16824)
@@ -527,7 +527,31 @@
 security issues. Any existing usage of ``verify_exists`` should be
 removed.
 
+``django.core.files.storage.Storage.open``
+~~
 
+The ``open`` method of the base Storage class took an obscure parameter
+``mixin`` which allowed to dynamically change the base classes of the
+returned file object. In the rare case you relied on the `mixin` parameter,
+you can easily achieve the same by overriding the `open` method, e.g.::
+
+from django.core.files import File
+from django.core.files.storage import FileSystemStorage
+
+class Spam(File):
+"""
+Spam, spam, spam, spam and spam.
+"""
+def ham(self):
+return 'eggs'
+
+class SpamStorage(FileSystemStorage):
+"""
+A custom file storage backend.
+"""
+def open(self, name, mode='rb'):
+return Spam(open(self.path(name), mode))
+
 .. _deprecated-features-1.4:
 
 Features deprecated in 1.4

Modified: django/trunk/tests/regressiontests/file_storage/tests.py
===
--- django/trunk/tests/regressiontests/file_storage/tests.py2011-09-13 
08:22:53 UTC (rev 16823)
+++ django/trunk/tests/regressiontests/file_storage/tests.py2011-09-13 
15:10:49 UTC (rev 16824)
@@ -231,26 +231,6 @@
 self.storage.base_url = None
 self.assertRaises(ValueError, self.storage.url, 'test.file')
 
-def test_file_with_mixin(self):
-"""
-File storage can get a mixin to extend the functionality of the
-returned file.
-"""
-self.assertFalse(self.storage.exists('test.file'))
-
-class TestFileMixin(object):
-mixed_in = True
-
-f = ContentFile('custom contents')
-f_name = self.storage.save('test.file', f)
-
-self.assertTrue(isinstance(
-self.storage.open('test.file', mixin=TestFileMixin),
-TestFileMixin
-))
-
-self.storage.delete('test.file')
-
 def test_listdir(self):
 """
 File storage returns a tuple containing directories and files.

-- 
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] #16830: Radioselect input loose id after invalid submission

[Django]

#16830: Radioselect input loose id after invalid submission
-+-
   Reporter:  social@…   |  Owner:  Nelson Monteiro
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:  html, radioselect,
   Triage Stage: |  forms
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by nelson.reis.monteiro@…):

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


Comment:

 Was my mistake, there is no bug... So I closed. Sorry!

-- 
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] #16832: add staticfiles lines to urls.py ,

[Django]

#16832: add staticfiles lines to urls.py ,
-+-
   Reporter:  wim@…  |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


-- 
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] #16834: wrong error message when entering admin and not is_staff or is_active

[Django]

#16834: wrong error message when entering admin and not is_staff or is_active
+---
 Reporter:  Wim Feijen   |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  contrib.admin
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  1   |  Easy pickings:  1
UI/UX:  0   |
+---
 On the admin login, when a user tries to login, but is_staff is set to
 False, the error message is misleadingly wrong:

 "Please enter a correct username and password. Note that both fields are
 case-sensitive."

 The actual message should be something like:

 "You are not allowed to enter the administration area of this website."

 How do we deal with translations of this message?

-- 
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] #16830: Radioselect input loose id after invalid submission

[Django]

#16830: Radioselect input loose id after invalid submission
-+-
   Reporter:  social@…   |  Owner:  Nelson Monteiro
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  html, radioselect,
   Triage Stage: |  forms
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Not sure why this was closed — reopening so that either the original
 reporter or the anonymous can clarify...

-- 
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] #16832: add staticfiles lines to urls.py ,

[Django]

#16832: add staticfiles lines to urls.py ,
-+-
   Reporter:  wim@…  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 Err, this is a wontfix :)

-- 
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] #16832: add staticfiles lines to urls.py ,

[Django]

#16832: add staticfiles lines to urls.py ,
-+-
   Reporter:  wim@…  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  duplicate  |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 No no, adding `staticfiles_urlpatterns` is **not** necessary when using
 the development server (via `runserver`), but only if you use an
 alternative server, like the 3rd party app gunicorn. I'm not convinced
 that use case is justifies the addition to the default URL.

-- 
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] #16832: add staticfiles lines to urls.py ,

[Django]

#16832: add staticfiles lines to urls.py ,
-+-
   Reporter:  wim@…  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 To the best of my knowledge, it isn't necessary to add anything to the
 URLconf to serve static files during development. The docs says:
 > This view is automatically enabled by runserver (with a DEBUG setting
 set to True).

 
(https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#django.contrib.staticfiles.templatetags.staticfiles.django.contrib.staticfiles.views.serve)

 What's the use case for adding these lines to the default urls.py?

-- 
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] #16830: Radioselect input loose id after invalid submission

[Django]

#16830: Radioselect input loose id after invalid submission
-+-
   Reporter:  social@…   |  Owner:  Nelson Monteiro
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:  html, radioselect,
   Triage Stage: |  forms
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by anonymous):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16833: Remove obscure mixin parameter from `Storage.open()` method

[Django]

#16833: Remove obscure mixin parameter from `Storage.open()` method
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |Component:  File
Milestone:   |  uploads/storage
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
 As discussed with Jacob, Russell and Marty this ought to be removed since
 it's an undocumented and rather obscure feature which can easily be
 implemented with standard subclassing/overriding.

-- 
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] #16833: Remove obscure mixin parameter from Storage.open() method (was: Remove obscure mixin parameter from `Storage.open()` method)

[Django]

#16833: Remove obscure mixin parameter from Storage.open() method
-+-
   Reporter:  jezdez |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  File
  Milestone: |  uploads/storage
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  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.

[Django] #16832: add staticfiles lines to urls.py ,

[Django]

#16832: add staticfiles lines to urls.py ,
--+--
 Reporter:  wim@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Core (Other)
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+--
 During development, static files can be served using:

 from django.contrib.staticfiles.urls import staticfiles_urlpatterns
 urlpatterns += staticfiles_urlpatterns()

 My proposal is to add these lines, commented, to urls.py so people can
 enable them quickly.

-- 
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] #16832: add staticfiles lines to urls.py ,

[Django]

#16832: add staticfiles lines to urls.py ,
-+-
   Reporter:  wim@…  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by wim@…):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * easy:  0 => 1
 * 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] #7222: FormPreview should pass the form to done()

[Django]

#7222: FormPreview should pass the form to done()
-+-
   Reporter:  Samuel |  Owner:  nobody
  Cormier-Iijima | Status:  closed
   Type:  New|  Component:  contrib.formtools
  feature|   Severity:  Normal
  Milestone: |   Keywords:  formpreview done
Version:  SVN|  cleaned_data form
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jacob):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 Yeah, we clearly missed getting this in before 1.0!

 Adding it now would indeed introduce a backwards-incompatible change, and
 I can't see a good way around that. Thus, marking wontfix: the slight
 improvement in usability doesn't warrant breaking everyone's existing
 code.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #6527: A bug in HttpResponse with iterators

[Django]

#6527: A bug in HttpResponse  with iterators
-+-
   Reporter:  daonb  |  Owner:  ccahoon
    | Status:  new
   Type:  Bug|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  http iterators
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jacob):

 * stage:  Design decision needed => Accepted


Comment:

 This shouldn't be DDN -- it's still a bug -- but it's far from clear how
 to solve this problem. We've got to figure out a consistant way of
 handling lazy vs. non-lazy responses, and we haven't yet. That's a bigger
 discussion and probably needs a "master ticket" or an extended discussion
 on django-dev.

-- 
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] #5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for different fields

[Django]

#5851: SplitDateTimeWidget (or MultiWidget) doesn't allow different attrs for
different fields
-+-
   Reporter:  ciantic@…  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  SplitDateTimeWidget
 Resolution: |  MultiWidget
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by jacob):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 The first solution (making the fix to `MultiWidget`) is the right way to
 go.

-- 
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] #16827: validate CSRF token (Check length)

[Django]

#16827: validate CSRF token (Check length)
+--
   Reporter:  jedie |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.csrf
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+--
Changes (by tinodb):

 * component:  Uncategorized => contrib.csrf
 * needs_tests:  0 => 1
 * 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] #16831: Radioselect input loose id after invalid submission

[Django]

#16831: Radioselect input loose id after invalid submission
-+-
   Reporter:  social@…   |  Owner:  Nelson Monteiro
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:  html, radioselect,
   Triage Stage: |  forms
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Double submission of #16830.

-- 
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] #16831: Radioselect input loose id after invalid submission

[Django]

#16831: Radioselect input loose id after invalid submission
--+-
 Reporter:  social@…  |  Owner:  Nelson Monteiro
 Type:  Bug   | Status:  new
Milestone:|  Component:  HTTP handling
  Version:  1.3   |   Severity:  Normal
 Keywords:  html, radioselect, forms  |   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+-
 The radioselected input loose id after invalid submission

 Before form submission the radioselect output is '' and after invalid submission the
 output is ''

 I detected this with a PositiveSmallIntegerField with choices.

-- 
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] #16830: Radioselect input loose id after invalid submission

[Django]

#16830: Radioselect input loose id after invalid submission
--+-
 Reporter:  social@…  |  Owner:  Nelson Monteiro
 Type:  Bug   | Status:  new
Milestone:|  Component:  HTTP handling
  Version:  1.3   |   Severity:  Normal
 Keywords:  html, radioselect, forms  |   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+-
 The radioselected input loose id after invalid submission

 Before form submission the radioselect output is '' and after invalid submission the
 output is ''

 I detected this with a PositiveSmallIntegerField with choices.

-- 
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] #14063: Validating form file fields is hard

[Django]

#14063: Validating form file fields is hard
-+-
   Reporter:  olau   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  File
  Milestone: |  uploads/storage
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by andrewgodwin):

 Yeah, that's essentially your workaround.

 I think what might be the best thing here is to have temporary_file_path,
 or some nicer equivalent, on all file objects, and have it work on in-
 memory types too, using tempfile. Alternatively, have some way of marking
 that a certain FileField never wants in-memory files (i.e. avoiding the
 global setting), which is nice because it requires less code.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #14063: Validating form file fields is hard

[Django]

#14063: Validating form file fields is hard
-+-
   Reporter:  olau   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  File
  Milestone: |  uploads/storage
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by olau):

 By the way, temporary_file_path() is just what I need, if memory file
 things had that too, I would be a happy camper. I realize that requires
 turning them into temporary files or cleaning up somehow, though.

-- 
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] #14063: Validating form file fields is hard

[Django]

#14063: Validating form file fields is hard
-+-
   Reporter:  olau   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  File
  Milestone: |  uploads/storage
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by olau):

 I think that's basically what the work-around snippet I posted does in a
 different way through temporary_file_path? Or do you have something else
 in mind?

 I'd rather not want to mess with a global setting like
 FILE_UPLOAD_MAX_MEMORY_SIZE.

-- 
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] #11485: sitemap.xml doesn't support https urls

[Django]

#11485: sitemap.xml doesn't support https urls
-+-
   Reporter:  sportsboy  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  HTTP handling
Version:  1.0|   Severity:  Normal
 Resolution: |   Keywords:  sitemap, https, ssl
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by jezdez):

 Please stop +1'ing the ticket, Trac isn't Google Plus. The ticket has been
 accepted and a +1 won't help fixing it quicker.

-- 
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] #11485: sitemap.xml doesn't support https urls

[Django]

#11485: sitemap.xml doesn't support https urls
-+-
   Reporter:  sportsboy  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  HTTP handling
Version:  1.0|   Severity:  Normal
 Resolution: |   Keywords:  sitemap, https, ssl
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by madisv):

 * needs_docs:  0 => 1
 * ui_ux:   => 0


Comment:

 +1

 This is really a problem for SSL secured sites who want to use the
 framework.
 As this problem with secure and unsecure URLS has had an impact on my
 projects also before - I would really want a setting for this to be added.

 Another option is to modify the Sites framework to figure this out from
 the requests.

 Another note is that the docs are wrong - sitemap framework does not need
 sites framework anymore. I made a pull request for this.

-- 
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] #15367: Improved Auth Password Hashing

[Django]

#15367: Improved Auth Password Hashing
-+-
   Reporter:  poswald|  Owner:  jart
   Type:  New| Status:  new
  feature|  Component:  contrib.auth
  Milestone:  1.4|   Severity:  Normal
Version: |   Keywords:  password, hash,
 Resolution: |  hashing, bcrypt, scrypt, pbkdf2,
   Triage Stage:  Accepted   |  sha2, sha1
Needs documentation:  1  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by jezdez):

 Yeah, that seems like a smart way to put it.

 - the hashing functions ought to be part of the `django.utils` package
 since they fit the goal of `django.utils` of providing low-level
 implementations
 - the specific implementation (the "hashers") ought to live in the auth
 app and use the low-level pieces by importing from `django.utils` and
 provide a high-level API for users to implement their own hasher

-- 
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] #16353: With multi-databases, if django.contrib.sites.models.Site is not synchronized on all databases, Django's tests fail

[Django]

#16353: With multi-databases, if django.contrib.sites.models.Site is not
synchronized on all databases, Django's tests fail
-+---
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Testing framework
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by aaugustin):

 * severity:  Normal => Release blocker


-- 
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] #16353: With multi-databases, if django.contrib.sites.models.Site is not synchronized on all databases, Django's tests fail

[Django]

#16353: With multi-databases, if django.contrib.sites.models.Site is not
synchronized on all databases, Django's tests fail
-+---
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Testing framework
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---

Comment (by aaugustin):

 #16828 was a duplicate.

-- 
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] #16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases

[Django]

#16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases
--+---
   Reporter:  aaugustin   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Release blocker
 Resolution:  duplicate   |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by aaugustin):

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


Comment:

 Yeah, I think I just managed to report the same bug twice... and write
 exactly the same patch... *goes grab a coffee*.

 For the record, this problem was introduced in r16027 (trunk) and r16028
 (1.3.X).

-- 
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] #16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases

[Django]

#16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases
--+---
   Reporter:  aaugustin   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Release blocker
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---

Comment (by julien):

 Or maybe is it a bug in trunk that has also been introduced in the 1.3.1
 release?

-- 
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] #16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases

[Django]

#16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases
--+---
   Reporter:  aaugustin   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Release blocker
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---

Comment (by julien):

 Isn't this a duplicate of #16353?

-- 
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] #16815: Broken example code -- hidden fields won't show if there aren't visible fields.

[Django]

#16815: Broken example code -- hidden fields won't show if there aren't visible
fields.
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.1|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  0
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 In [16823]:
 {{{
 #!CommitTicketReference repository="" revision="16823"
 Fixed #16815 -- Rectified the code example for hidden_fields and
 visible_fields in the forms documentation. Thanks, joonas.
 }}}

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

[noreply]

Author: julien
Date: 2011-09-13 01:22:53 -0700 (Tue, 13 Sep 2011)
New Revision: 16823

Modified:
   django/trunk/docs/topics/forms/index.txt
Log:
Fixed #16815 -- Rectified the code example for hidden_fields and visible_fields 
in the forms documentation. Thanks, joonas.

Modified: django/trunk/docs/topics/forms/index.txt
===
--- django/trunk/docs/topics/forms/index.txt2011-09-13 03:10:07 UTC (rev 
16822)
+++ django/trunk/docs/topics/forms/index.txt2011-09-13 08:22:53 UTC (rev 
16823)
@@ -333,16 +333,13 @@
 these two methods::
 
 
+{# Include the hidden fields #}
+{% for hidden in form.hidden_fields %}
+{{ hidden }}
+{% endfor %}
+{# Include the visible fields #}
 {% for field in form.visible_fields %}
 
-
-{# Include the hidden fields in the form #}
-{% if forloop.first %}
-{% for hidden in form.hidden_fields %}
-{{ hidden }}
-{% endfor %}
-{% endif %}
-
 {{ field.errors }}
 {{ field.label_tag }}: {{ field }}
 

-- 
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] #16815: Broken example code -- hidden fields won't show if there aren't visible fields.

[Django]

#16815: Broken example code -- hidden fields won't show if there aren't visible
fields.
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.1|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  0
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases

[Django]

#16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases
--+---
   Reporter:  aaugustin   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Release blocker
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---

Comment (by aaugustin):

 This bug also exists on 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] #16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases

[Django]

#16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases
--+---
   Reporter:  aaugustin   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Release blocker
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by aaugustin):

 * has_patch:  0 => 1
 * needs_tests:  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.

[Django] #16829: sitemap for static views

[Django]

#16829: sitemap for static views
---+--
 Reporter:  madisv |  Owner:  nobody
 Type:  New feature| Status:  new
Milestone:  1.4|  Component:  contrib.sitemaps
  Version:  1.3|   Severity:  Normal
 Keywords:  views sitemap  |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+--
 People also use static views which are not FlatPages. So it's a problem
 creating a sitemap for such urls.
 This is not hard to do if you know how so should this code maybe also be
 in django or might we just document this so people would know how to do
 this.

 Problem explained also:
 http://stackoverflow.com/questions/4836188/django-sitemaps-and-normal-
 views

 Solution by Matt Austin:
 from django.core.urlresolvers import reverse
 from django.contrib.sitemaps import Sitemap



 {{{
 class ViewSitemap(Sitemap):
 """Reverse static views for XML sitemap."""
 def items(self):
 # Return list of url names for views to include in sitemap
 return ['homepage', 'news_article_list', 'contact_page']

 def location(self, item):
 return reverse(item)


 sitemaps = {'views': ViewSitemap, 'news_articles': ArticleSitemap}
 }}}

-- 
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] #2550: [patch] Allow a Backend to Globally Fail Authentication

[Django]

#2550: [patch] Allow a Backend to Globally Fail Authentication
-+-
   Reporter:  umbrae@…   |  Owner:  aashu_dwivedi
   Type:  New| Status:  reopened
  feature|  Component:  contrib.auth
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  authentication
 Resolution: |  backends easy-pickings
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Revert apparent spam.

-- 
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] #16819: list_editable breaks multipage changelists

[Django]

#16819: list_editable breaks multipage changelists
-+-
   Reporter:  anossov@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  admin list_editable
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by julien):

 The issue occurs when no ordering is not explicitly set by
 `Model.Meta.ordering` or `ModelAdmin.ordering`. In that case the `FormSet`
 enforces default ordering by primary key
 (source:django/trunk/django/forms/models.py?rev=16659#L459) (see the
 reason in #10163), yet the queryset has already been paginated by the
 changelist
 (source:django/trunk/django/contrib/admin/views/main.py?rev=16659#L156).

 I'm wondering if the default ordering shouldn't be taken out of the
 `FormSet` and moved to `ChangeList.get_ordering()` as in the suggested
 patch in comment:3.

-- 
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] #16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases

[Django]

#16828: Upgrade from 1.3 to 1.3.1 breaks manage.py test with multiple databases
---+-
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Milestone: |Component:  Testing framework
  Version:  1.3| Severity:  Release blocker
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
 To reproduce this problem:

 * `django-admin.py startproject regrtest && cd regrtest`
 * create a file called `routers.py` with this content (this is a dummy
 router that puts everything in the "default" database):
 {{{
 class TestRouter(object):

 def db_for_read(self, model, **hints):
 return 'default'

 def db_for_write(self, model, **hints):
 return 'default'

 def allow_relation(self, obj1, obj2, **hints):
 return True

 def allow_syncdb(self, db, model):
 return db == 'default'
 }}}
 * in `settings.py`, replace the default value of `DATABASES` with this
 content:
 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': 'default.sqlite3',
 },
 'other': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': 'other.sqlite3',
 },
 }

 DATABASE_ROUTERS = ['routers.TestRouter']
 }}}
 * `python manage.py test auth` works under 1.3 but not under 1.3.1:
 {{{

 aaugustin@aaugustin regrtest % . ../dj13_venv/bin/activate
 (dj13_venv)aaugustin@aaugustin regrtest % python manage.py test auth
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 
..
 --
 Ran 98 tests in 1.745s

 OK
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 (dj13_venv)aaugustin@aaugustin regrtest % . ../dj131_venv/bin/activate
 (dj131_venv)aaugustin@aaugustin regrtest % python manage.py test auth
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 Traceback (most recent call last):
   File "manage.py", line 14, in 
 execute_manager(settings)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/core/management/__init__.py", line 438, in execute_manager
 utility.execute()
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/core/management/__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/core/management/base.py", line 191, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/core/management/base.py", line 220, in execute
 output = self.handle(*args, **options)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/core/management/commands/test.py", line 37, in handle
 failures = test_runner.run_tests(test_labels)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/test/simple.py", line 359, in run_tests
 old_config = self.setup_databases()
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/test/simple.py", line 296, in setup_databases
 test_db_name = connection.creation.create_test_db(self.verbosity,
 autoclobber=not self.interactive)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/db/backends/creation.py", line 384, in create_test_db
 if Site is not None and
 Site.objects.using(self.connection.alias).count() == 1:
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/db/models/query.py", line 334, in count
 return self.query.get_count(using=self.db)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/db/models/sql/query.py", line 401, in get_count
 number = obj.get_aggregation(using=using)[None]
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/db/models/sql/query.py", line 367, in get_aggregation
 result = query.get_compiler(using).execute_sql(SINGLE)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 packages/django/db/models/sql/compiler.py", line 735, in execute_sql
 cursor.execute(sql, params)
   File "/Users/aaugustin/Documents/dev/dj131_venv/lib/python2.6/site-
 

Re: [Django] #2550: [patch] Allow a Backend to Globally Fail Authentication

[Django]

#2550: [patch] Allow a Backend to Globally Fail Authentication
-+-
   Reporter:  umbrae@…   |  Owner:  aashu_dwivedi
   Type:  New| Status:  closed
  feature|  Component:  contrib.auth
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  authentication
 Resolution:  fixed  |  backends easy-pickings
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by anonymous):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16250: Error with new pyscopg2 2.4.2 release and tests

[Django]

#16250: Error with new pyscopg2 2.4.2 release and tests
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Testing framework
Version:  1.3|   Severity:  Release blocker
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by shai):

 * cc: shai@… (added)


Comment:

 Just for the record, the fix was not included in Django 1.3.1; we still
 need 2.4.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] #16827: validate CSRF token (Check length)

[Django]

#16827: validate CSRF token (Check length)
--+---
   Reporter:  jedie   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Uncategorized
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+---
Changes (by jedie):

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


Comment:

 Patch is here: https://github.com/django/django/pull/45

-- 
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] #16827: validate CSRF token (Check length)

[Django]

#16827: validate CSRF token (Check length)
---+---
 Reporter:  jedie  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  1
UI/UX:  0  |
---+---
 I wonder that the CSRF token send from the client didn't be validated.

 Don't know if a DOS attack is possible by sending many request with very
 long CSRF tokens?

 IMHO it's a good idea to check the length before do anything with it.

 See also: https://groups.google.com/group/django-
 developers/browse_thread/thread/9fc008d2a3735bc2

-- 
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] #16826: Overwriting max_decimal_places error message in forms.DecimalField raises Exception

[Django]

#16826: Overwriting max_decimal_places error message in forms.DecimalField 
raises
Exception
--+
   Reporter:  jyl@…   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Forms
Version:  1.3 |   Severity:  Normal
 Resolution:  duplicate   |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
Changes (by Jack Li ):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16826: Overwriting max_decimal_places error message in forms.DecimalField raises Exception

[Django]

#16826: Overwriting max_decimal_places error message in forms.DecimalField 
raises
Exception
---+
 Reporter:  jyl@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Forms
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
 If you set decimal_places in forms.DecimalField and overwrite the the
 max_decimal_places error message, you will raise an exception when you try
 to input something larger than the specified decimal_places instead of
 getting your error message. Removing the custom error message does not
 generate the exception.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.