Re: [Django] #12064: Impossible to conditionally include potentially non-existant templates

[Django]

#12064: Impossible to conditionally include potentially non-existant templates
-+-
   Reporter: |  Owner:  nobody
  mkruisselbrink | Status:  new
   Type:  New|  Component:  Template system
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.1|  Has patch:  1
 Resolution: |Needs tests:  1
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by mrmachine):

 * easy:   => 0


Comment:

 See also #16147

 I believe that the behaviour of `{% include %}` as it stands is both
 inconsistent between development (`TEMPLATE_DEBUG = True`) and production
 environments, but also within the tag itself depending on the type of
 argument passed to it. These inconsistencies have shown themselves in a
 few different buggy (or at least unexpected) ways that are not always easy
 to trace.

 If including a non-existent template is worth raising TemplateDoesNotExist
 in a development environment, it should not fail silently in a production
 environment. The exception should also be raised there and redirected to
 admins via Django's logging.

 If including a non-existent template should fail silently when the
 template does not exist, it should do so both for includes that have a
 literal string argument or a variable, and it should do so both in
 development and production environments.

 I don't really have a firm opinion on whether or not including missing
 templates should always fail silently or loudly, although I believe the
 most common and expected behaviour currently is to fail silently so there
 may be backwards incompatible issues in changing that. But I do believe
 that the `{% include %}` tag should work it's magic at render time for
 both literal and variable arguments. I consider the currently
 (undocumented) difference in behaviour to be buggy or at the very least,
 surprising.

-- 
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] #416: Automate site introspection for url pattern modules, view methods, template directories, and applications

[Django]

#416: Automate site introspection for url pattern modules, view methods, 
template
directories, and applications
--+---
   Reporter:  garthk@…|  Owner:  adrian
   Type:  defect  | Status:  closed
  Milestone:  |  Component:  contrib.admin
Version:  0.91|   Severity:  normal
 Resolution:  wontfix |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  1   |  Easy pickings:  0
--+---
Changes (by ed hardy):

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


Comment:

 ll of duty (and not just in the workshop), and http://www.topedhardycloting.com/collection/new-arrivals.html";>New
 Arrivals of course be immensely precise and durable. Wrist watches
 do http://www.topedhardycloting.com";>ed hardy ll of
 duty (and not just in the workshop), and http://www.wholesaletiffanyoutlets.com";>wholesale necklaces
 of course be immensely precise and durable. Wrist watches do http://www.wholesaletiffanyoutlets.com";>tiffany jewelry ll
 of duty (and not just in the workshop), and http://www.designersbrianatwood.com";>replica herve leger
 dresses of course be immensely precise and durable. Wrist watches
 do http://www.designersbrianatwood.com";>brian atwood
 sale ll of duty (and not just in the workshop), and http://www.louboutinhelsuksale.com";>tory burch of course be
 immensely precise and durable. Wrist watches do http://www.louboutinhelsuksale.com";>tory burch flats

-- 
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] #16148: get_object_or_404 hook feature

[Django]

#16148: get_object_or_404 hook feature
-+---
 Reporter:  havelove@…   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Uncategorized
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+---
 how about add a hook to get_object_or_404 to render a template with  the
 same name of model when object does not exist ?

 For example:
 user = get_object_or_404(User, pk=pk)

 if the user does not exist, get_object_or_404 will try to render
 "404/user.html" to show the error page other than a single 404 page for
 all queries.

-- 
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] #16147: {% include %} tag raises TemplateDoesNotExist at compile time of parent template if TEMPLATE_DEBUG is True

[Django]

#16147: {% include %} tag raises TemplateDoesNotExist at compile time of parent
template if TEMPLATE_DEBUG is True
-+-
 Reporter:  mrmachine|  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:  1.4  |  Component:
  Version:  1.3  |  Template system
 Keywords:  include template |   Severity:  Normal
  TemplateDoesNotExist TEMPLATE_DEBUG|   Triage Stage:
Has patch:  0|  Unreviewed
 |  Easy pickings:  0
-+-
 I think this is a bug. Or at the very least, it can make for unexpected
 behaviour that is difficult to trace. When developing locally, `DEBUG` and
 `TEMPLATE_DEBUG` are often `True`. When `TEMPLATE_DEBUG` is `True`,
 compiling a template that contains an `{% include %}` to a template that
 doesn't exist will raise `TemplateDoesNotExist` at compile time of the
 parent template.

 {{{
 >>> from django.template import Template
 >>> t = Template('{% include "missing.html" %}')
 Traceback (most recent call last):
 ...
 TemplateDoesNotExist: missing.html
 }}}

 The problem is that when you try to conditionally load a template, and
 perform a different action if it does not exist. For example, you might
 have a view that uses `select_template` to load one of several templates
 (if one exists) and send an email. If no email was sent (because no
 template exists), render a different template/context to the response or
 take some other action. If the email template contains a typo in the name
 of an included template, the email template will not be loaded and no
 email will be sent because `TemplateDoesNotExist` was raised.

 In the local dev environment, this will not display a pretty debug page
 showing the error inside the email template, it will simply behave
 unexpectedly (by not sending an email when the email template DOES exist).
 On the production server (or when `TEMPLATE_DEBUG` is `False`), it will
 behave as expected. The email template will be found and it will be
 rendered.

 This problem doesn't exist when using a variable as the template name.

 {{{
 >>> t = Template('{% include somevar %}')
 >>>
 }}}

 Why does Django try to execute the `{% include %}` when it contains a hard
 coded string at compile time at all? I think this is a case of premature
 optimisation. If it execution of the `{% include %}` was delayed until
 render time, `select_template` would correctly return the email template
 when `TEMPLATE_DEBUG` is `True`, and the proper error would be displayed
 in the rendered email template (making it an easy fix to correct the
 typo).

-- 
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] #16146: Calling functions with arguments inside a template

[Django]

#16146: Calling functions with arguments inside a template
-+-
   Reporter:  pmandel@…  |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  template, function
 Resolution:  wontfix|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 Django actually prevents this by design. The idea is to keep most of the
 logic in views and keep the template language as simple as possible (so
 that it can easily be used by non tech-savvy designers, for example).
 Quoting from the doc:

 "Because Django intentionally limits the amount of logic processing
 available in the template language, it is not possible to pass arguments
 to method calls accessed from within templates. Data should be calculated
 in views, then passed to templates for display."
 (https://docs.djangoproject.com/en/1.3/topics/templates/#accessing-method-
 calls)

 So you'll have to do that in the view. Writing a custom template tag or
 filter might also be of good help. This is a common problem, so don't
 hesitate to ask on the django-users mailing list for more advice.

-- 
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] #13756: File upload not working under Tomcat

[Django]

#13756: File upload not working under Tomcat
-+---
   Reporter:  SvenKlemm  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.2|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+---

Comment (by Jeff250):

 I've opened a bug with the Jython folks for their input:
 http://bugs.jython.org/issue1754

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by julien):

 Wow, this is awesome! The popup looks great to me. I've found two issues
 though:

 * The popup doesn't show up when clicking on the cog in IE7 -- however
 this might be due to my crappy IE7 emulator on the Mac. It'd be worth
 testing on proper IE 6&7 setups.
 * I'm not sure if it's directly related to this patch, but the headers
 break when using a custom `ModelAdmin` method with the `admin_order_field`
 attribute. See the attached screenshot. Here's the code I've used:

 {{{#!python
 from django.db import models

 class Person(models.Model):
 name = models.CharField(max_length=100)
 age = models.PositiveIntegerField()
 is_employee = models.NullBooleanField()
 }}}
 {{{#!python
 from django.contrib import admin

 from models import Person

 class PersonAdmin(admin.ModelAdmin):
 list_display = ('name', 'age', 'is_employee', 'colored_name')

 def colored_name(self, obj):
 return '%s' % ('ff00ff',
 obj.name)
 colored_name.allow_tags = True
 colored_name.admin_order_field = 'name'

 admin.site.register(Person, PersonAdmin)

 }}}

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 I don't want to keep messing around with this, so I'll try to get feedback
 on this latest patch and then hopefully be done with it.

 On top of the committed changes, this patch:

 1. Implements the ESC handling and Cancel button suggested by Julien
 2. Adds 'toggle' and 'remove' buttons for each field in the sorting list,
 thereby allowing to sort on just the desired columns (or no sorting,
 3. Switches to a table layout for the popup. This has the consequence of
 simplifying the i18n issues
 4. Adds styling consistent with the date picker popup (actually, got this
 almost for free with the table markup).

-- 
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] #16146: Calling functions with arguments inside a template

[Django]

#16146: Calling functions with arguments inside a template
+-
 Reporter:  pmandel@…   |  Owner:  nobody
 Type:  New feature | Status:  new
Milestone:  |  Component:  Template system
  Version:  1.3 |   Severity:  Normal
 Keywords:  template, function  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
+-
 It would be incredibly useful to be able to call functions with arguments
 inside a Django template.

 Imagine we are looping through a set of articles:
 {{{
 
 {% for a in articles %}
 {{ a.title }}
 {% endfor %}
 
 }}}
 And we want to change the color of articles the current user has already
 read (at some point prior to the current browser session, presumably).
 Under the current framework, there's no straightforward way to do this.
 Ideally, we'd create a function inside the poll class that would perform
 the check for us:
 {{{
 def has_been_read_by(self, user)
 }}}
 So in the template, we'd get:
 {{{
 
 {% for a in articles %}
 {{
 a.title }}
 {% endfor %}
 
 }}}
 However, since we can't pass an argument to the function in the template,
 this is currently impossible.  The best way I've figured out to do this is
 to perform all these checks view-side and zip up the information along
 with the object into a list of dictionaries that the template can unpack.
 Ugly.

 I propose that we consider allowing some form of arguments through
 functions in the template, be it with the '|arg', the ':arg' or the good
 old '(arg)' notation.

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

[Django]

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

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


Comment:

 Regular patch added.

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

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

[Django]

#16057: uWSGI documentation
---+---
   Reporter:  jpic |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:  uwsgi
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---

Comment (by aaugustin):

 I've taken the proposal, improved the markup, and added appropriate links
 from other documentation pages.

 I think the text is clear, concise and complete, so I didn't touch its
 contents at all.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 Using http://lukeplant.me.uk/uploads/cog_icon2.gif since [16318]

-- 
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] r16318 - django/trunk/django/contrib/admin/media/img/admin

[noreply]

Author: lukeplant
Date: 2011-06-02 12:50:48 -0700 (Thu, 02 Jun 2011)
New Revision: 16318

Modified:
   django/trunk/django/contrib/admin/media/img/admin/icon_cog.gif
Log:
Improved cog icon for sorting interface in admin

Modified: django/trunk/django/contrib/admin/media/img/admin/icon_cog.gif
===
(Binary files differ)

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 As I mentioned to Florian on IRC, there isn't really a **need** to sort on
 one column, as long as you can sort by your primary column. But I agree it
 could be a distraction/annoyance.

 A 'clear sorting' option would be tricky in terms of how it would work,
 and easy to confuse with 'reset sorting'. An alternative is that in the
 popup there is an option to explicitly remove a field from the sorting. We
 could also add an option to explicitly toggle any of the existing fields.
 I'm not sure if these are refinements we can live without for now. With
 the current code, however, it isn't that hard to add them, now that I've
 got this in my head.

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by julien):

 Replying to [comment:28 apollo13]:
 > Is it just me or can I no longer filter by __just__ the second column in
 the display, reset always resets to the first one, clicking on the second
 column then gives me a sorting by two columns…

 I presume that "Reset sorting" will reset the default sorting, which means
 it's no longer possible to sort by a single column other than the default
 one. Perhaps there should also be an option "Clear sorting" that would
 clear all sorting options including the default one.

 Now that I've used it a bit more, I think one more way to improve the user
 experience is to also add a "Close" link/button in the popup, and also to
 make the popup close when pressing the "Esc" key.

 I like the two small icons that you've suggested, Luke. I've got a slight
 preference for "cog_icon2.gif" as it's a bit more subtle.

-- 
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] #9198: templatetag include adds new line

[Django]

#9198: templatetag include adds new line
---+-
   Reporter:  versae   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Template system
Version:  1.0  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+-

Comment (by versae):

 Replying to [comment:4 anonymous]:
 > versae's workaround doesnt seem to fix anything. The new lines seem to
 survive the trimming (!?).

 You have to use the filter together to
 [http://djangosnippets.org/snippets/835/ withtag templatetag]. By example:
 {{{
 {% withtag include temaplate1.html as my_template %}
 {% my_template|trim %}
 {% endwithtab %}
 }}}

 But the code of {{{withtag}}} templatetag is old, I don't know if it's
 working yet.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by apollo13):

 Is it just me or can I no longer filter by __just__ the second column in
 the display, reset always resets to the first one, clicking on the second
 column then gives me a sorting by two columns…

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

[Django]

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

 * owner:  nobody => leereilly
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16145: Typo in docs/topics/db/managers.txt

[Django]

#16145: Typo in docs/topics/db/managers.txt
--+---
 Reporter:  lee@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Documentation
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  1
--+---
 Hi,

 I submitted a pull request @ https://github.com/django/django/pull/24, but
 was asked to create a ticket here.
  I removed 'object' (shown below in bold) from the following documentation
 snippet:

 The use_for_related_fields attribute must be set on the manager class,
 '''object''' not on an instance of the class. The earlier example shows
 the correct way to set it, whereas the following will not work::

 Do I need to follow the instruction @
 https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /submitting-patches, or can the pull request above simply be merged...
 assuming it is approved of course?

 Cheers,
   Lee

-- 
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] #9198: templatetag include adds new line

[Django]

#9198: templatetag include adds new line
---+-
   Reporter:  versae   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Template system
Version:  1.0  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+-
Changes (by anonymous):

 * easy:   => 0


Comment:

 versae's workaround doesnt seem to fix anything. The new lines seem to
 survive the trimming (!?).

-- 
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] #16136: Error was: cannot import name utils

[Django]

#16136: Error was: cannot import name utils
-+-
   Reporter: |  Owner:  nobody
  kurvenschubser@…   | Status:  reopened
   Type: |  Component:  Uncategorized
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by kurvenschubser@…):

 Hi aaugustin,
 re. 1:
 Yes I can. No problem whatsoever.
 re. 2:
 Here is the settings.py. I have triple checked to make sure all values
 from my *info files (used in function "getinfo") are correct:
 {{{
 import os
 import logging
 from logging import config


 def getinfo(filename):
 return tuple(s.strip() for s in open(filename).next().strip(
 ).split("\t"))

 #absolute path to this project
 PROJECT_ROOT = os.path.abspath(os.path.dirname(__file__))
 LOGGING_CONFIG_FILE = os.path.join(PROJECT_ROOT, "logging.cfg")

 try:
 config.fileConfig(LOGGING_CONFIG_FILE)
 except:
 #rewrite logging config file
 LOGGING_FILE = open(LOGGING_CONFIG_FILE, "w")
 LOGGING_TARGET = os.path.join(PROJECT_ROOT, "django.log")
 LOGGING_CONFIG = """
 [loggers]
 keys=root

 [handlers]
 keys=hand01,hand02

 [formatters]
 keys=form01

 [logger_root]
 level=DEBUG
 handlers=hand02

 [handler_hand01]
 class=StreamHandler
 level=DEBUG
 formatter=form01
 args=(sys.stdout,)

 [handler_hand02]
 class=FileHandler
 level=DEBUG
 formatter=form01
 args=("%(logging_target)s", "a")

 [formatter_form01]
 format= %%(levelname)s %%(pathname)s %%(lineno)d %%(asctime)s %%(message)s
 datefmt=
 class=logging.Formatter
 """ % {"logging_target": LOGGING_TARGET}

 LOGGING_FILE.write(LOGGING_CONFIG)
 LOGGING_FILE.close()
 try:
 config.fileConfig(LOGGING_CONFIG_FILE)
 except:
 Exception("Something's wrong with the config file: '%s'" %
 LOGGING_CONFIG_FILE)
 logging.debug("start logging")


 DEBUG = True
 TEMPLATE_DEBUG = DEBUG

 ADMINS = (getinfo(os.path.join(PROJECT_ROOT, "admininfo")),
 # ('Your Name', 'your_em...@domain.com'),
 )

 MANAGERS = ADMINS
 DATABASES = {
 "default": dict(zip(("ENGINE", "NAME", "USER", "PASSWORD", "HOST",
 "PORT"),
 getinfo(os.path.join(PROJECT_ROOT,
 "dbinfo"
 }


 # Local time zone for this installation. Choices can be found here:
 # http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
 # although not all choices may be available on all operating systems.
 # If running in a Windows environment this must be set to the same as your
 # system time zone.
 TIME_ZONE = 'Europe/Berlin'

 # Language code for this installation. All choices can be found here:
 # http://www.i18nguy.com/unicode/language-identifiers.html
 LANGUAGE_CODE = 'de-de'

 SITE_ID = 2

 # The directory name under which the project is saved
 PROJECT_NAME = "kurvenschubser"
 SERVER_ROOT = "/var/www/mars98"

 # No trailing slashes, please.
 PROJECT_URL = "http://www.%s.de"; % (PROJECT_NAME,)

 # If you set this to False, Django will make some optimizations so as not
 # to load the internationalization machinery.
 USE_I18N = True

 # Absolute path to the directory that holds media.
 # Example: "/home/media/media.lawrence.com/"
 MEDIA_ROOT = "%s/html/%s/static/" % (SERVER_ROOT, PROJECT_NAME)

 # URL that handles the media served from MEDIA_ROOT. Make sure to use a
 # trailing slash if there is a path component (optional in other cases).
 # Examples: "http://media.lawrence.com";, "http://example.com/media/";
 MEDIA_URL = "http://static.%s.de/"; % (PROJECT_NAME,)


 # URL prefix for admin media -- CSS, JavaScript and images. Make sure to
 use a
 # trailing slash.
 # Examples: "http://foo.com/media/";, "/media/".
 ADMIN_MEDIA_PREFIX = '/django_admin_media/'

 # Make this unique, and don't share it with anybody.
 SECRET_KEY = getinfo(os.path.join(PROJECT_ROOT, "secretkey"))[0]

 # Users section
 LOGIN_URL = '/accounts/login/'
 LOGIN_REDIRECT_URL = '/accounts/login/confirm/'

 # Registration section
 ACCOUNT_ACTIVATION_DAYS, DEFAULT_FROM_EMAIL, EMAIL_HOST, EMAIL_HOST_USER,
 \
 EMAIL_HOST_PASSWORD, EMAIL_SUBJECT_PREFIX = getinfo(
 os.path.join(PROJECT_ROOT, "registrationinfo"))
 ACCOUNT_ACTIVATION_DAYS = int(ACCOUNT_ACTIVATION_DAYS)
 EMAIL_SUBJECT_PREFIX = EMAIL_SUBJECT_PREFIX % (PROJECT_NAME,)


 # Profile section
 AUTH_PROFILE_MODULE = "user_profile.UserProfile"

 # List of callables that know how to import te

Re: [Django] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
   Reporter:  Tuttle |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Management
  Milestone:  1.4|  commands)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  help color django-
   Triage Stage:  Accepted   |  admin manage.py
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by jezdez):

 * component:  Core (Other) => Core (Management commands)


-- 
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] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
   Reporter:  Tuttle |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  help color django-
 Resolution: |  admin manage.py
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by jezdez):

 * 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] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
   Reporter:  Tuttle |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  help color django-
 Resolution: |  admin manage.py
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by jezdez):

 FWIW, I agree with bartTC's points, except that `'manage.py help
 --commands'` seems more fitting.

-- 
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] #16088: Multi-database tests fail in ContentType

[Django]

#16088: Multi-database tests fail in ContentType
-+-
   Reporter:  def@…  |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  ContentType
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by anonymous):

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


-- 
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] #11745: Categories by origin for command listings in "manage.py help"

[Django]

#11745: Categories by origin for command listings in "manage.py help"
-+-
   Reporter:  Tuttle |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  help color django-
 Resolution: |  admin manage.py
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by bartTC):

 This works fine however I see two problems with it:

 1. Its backwards incompatible, I am not sure if its a huge deal but
 someone could parse this list, having an option 'manage.py help --list' to
 get the old behavior would be fine.
 2. It's irritating, if an app overwrites a 'core' app, this command is
 under that app. See the South help list:

 {{{
 [south]
   convert_to_south
   datamigration
   graphmigrations
   migrate
   schemamigration
   startmigration
   syncdb
   test
   testserver
 }}}

 South overwrites 'test' and 'testserver' which I would expect under
 [django].

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 Hmm, in the testing I thought it left the table header the same size.

 Finding a nice icon is tricky - you can't just resize them at this small
 size, and it also has to be gif, for transparency support on IE6.

 Here are a couple of alternatives I found/made:

 http://lukeplant.me.uk/uploads/cog_icon.gif

 http://lukeplant.me.uk/uploads/cog_icon2.gif

 They are a bit smaller and hard to hit with the mouse, but look a bit
 nicer. I made them a bit wider than need to be, to increase the chance of
 hitting them.

-- 
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] r16317 - django/trunk/django/contrib/admin/media/css

[noreply]

Author: lukeplant
Date: 2011-06-02 09:42:19 -0700 (Thu, 02 Jun 2011)
New Revision: 16317

Modified:
   django/trunk/django/contrib/admin/media/css/base.css
Log:
Fixed position of new cog icon in admin changelist relative to text

Modified: django/trunk/django/contrib/admin/media/css/base.css
===
--- django/trunk/django/contrib/admin/media/css/base.css2011-06-02 
16:18:47 UTC (rev 16316)
+++ django/trunk/django/contrib/admin/media/css/base.css2011-06-02 
16:42:19 UTC (rev 16317)
@@ -338,7 +338,7 @@
 }
 
 table thead th.sorted a img {
-   vertical-align: bottom;
+   vertical-align: top;
 }
 
 table thead th.sorted a span.clear {

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by jezdez):

 Ough, that icon is rather aweful! It really blows up the table header
 vertically, didn't you find a better image?

-- 
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] #7309: NFA: Don't override order_by if no default ordering is specified

[Django]

#7309: NFA: Don't override order_by if no default ordering is specified
-+-
   Reporter:  lukas@…|Owner:  nobody
   Type:  Bug|   Status:  closed
  Milestone: |Component:  contrib.admin
Version:  SVN| Severity:  Normal
 Resolution:  fixed  | Keywords:  order_by nfa-someday
   Triage Stage:  Design |Has patch:  0
  decision needed|  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

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


Comment:

 In [16316]:
 {{{
 #!CommitTicketReference repository="" revision="16316"
 Fixed #11868 - Multiple sort in admin changelist.

 Many thanks to bendavis78 for the initial patch, and for input from
 others.

 Also fixed #7309. If people were relying on the undocumented default
 ordering
 applied by the admin before, they will need to add 'ordering = ["-pk"]' to
 their ModelAdmin.
 }}}

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

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


Comment:

 In [16316]:
 {{{
 #!CommitTicketReference repository="" revision="16316"
 Fixed #11868 - Multiple sort in admin changelist.

 Many thanks to bendavis78 for the initial patch, and for input from
 others.

 Also fixed #7309. If people were relying on the undocumented default
 ordering
 applied by the admin before, they will need to add 'ordering = ["-pk"]' to
 their ModelAdmin.
 }}}

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  assigned
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 OK, thanks for input from everyone. I believe I've got a patch that
 addresses all concerns raised:

 * I've gone with Jannis' suggestion regarding 'ascending/descending',
 because I don't think using icons in that popup is really helpful.
 * I've fixed it in RTL mode
 * I've added a basic test for multiple sorting. It doesn't test the URLs
 generated for each column header, for the reasons of parsing HTML that I
 described earlier.
 * Added tests for `ModelAdmin` and Meta being respected, in the right
 order.
 * #7309 - my patch now addresses that too, also adding tests for it -
 thanks for pointing out Julien.
 * I found a suitable cog image, good suggestion. The one I've used is
 perhaps a tad big, but I couldn't find one smaller, and it does give a
 better target for hitting than the dot I had before, and makes the feature
 more obvious.

 BTW, I used a '.' instead of ',' in the query string, because the former
 is not escaped, and so looks much nicer in the address bar.

 I'll commit shortly. Any other tweaks to UI styling can then be done more
 easily.

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

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

Re: [Django] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
---+---
Changes (by jezdez):

 * needs_better_patch:  0 => 1


Comment:

 What's the purpose of the crumbs block? Isn't that a bit OT for this
 ticket and would make upgrading harder?

-- 
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] #8034: Gzip Middleware And Images

[Django]

#8034: Gzip Middleware And Images
-+-
   Reporter:  magneto|  Owner:  nobody
   Type:  New| Status:  reopened
  feature|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  gzip middleware
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by aaugustin):

 Oops, the triage guidelines say that only core devs are allowed to close
 tickets. 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] #8034: Gzip Middleware And Images

[Django]

#8034: Gzip Middleware And Images
-+-
   Reporter:  magneto|  Owner:  nobody
   Type:  New| Status:  reopened
  feature|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  gzip middleware
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * status:  closed => reopened
 * resolution:  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] #8034: Gzip Middleware And Images

[Django]

#8034: Gzip Middleware And Images
-+-
   Reporter:  magneto|  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  gzip middleware
 Resolution:  wontfix|  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Old description:

> In the random cases where Images (Gifs, JPEGS, PNG, etc) are passed
> through the Gzip middleware (usually through the static sender),
> sometimes they get 'truncated' (i think it may be a partial browser bug
> too)
>
> but there is no reason to Gzip image content-types and waste the
> time/ram/etc in doing them

New description:

 In the random cases where Images (Gifs, JPEGS, PNG, etc) are passed
 through the Gzip middleware (usually through the static sender), sometimes
 they get 'truncated' (i think it may be a partial browser bug too)

 but there is no reason to Gzip image content-types and waste the
 time/ram/etc in doing them

--

Comment:

 MIME types are defined here : http://www.iana.org/assignments/media-
 types/index.html and valid types include `application/*`, `audio/*`,
 `example/*`, `image/*`, `message/*`, `model/*`, `multipart/*`, `text/*`,
 `video/*`.

 If we hardcode that `image/*` and `video/*` must not be compressed, we
 should also add `audio/*` to the list. But this technique is crude: for
 instance, `application/xml` should be compressed; `application/mp4` and
 `application/octet-stream` shouldn't. We're going to have debates about
 the proper whitelist / blacklist. And adding yet another setting is not
 the solution. In short, the patch doesn't smell good.

 

 Let's look at the problem differently. It's an Horribly Bad Idea to serve
 "a 100 Mb Tiff or 2 Gb Mpeg2" through Django. Actually, serving anything
 that is not programmatically generated by Django through Django is grossly
 inefficient.

 If someone is at that level of non-optimization, clearly, not compressing
 the HTML is not going to make a difference. Just disable !GzipMiddleware
 and be done with it.

 

 Given all this, plus the fact that the ticket has been rotting for two
 years, I will close it.

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

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

Re: [Django] #10762: Gzip Middleware Should Compress 201 (Created) Responses

[Django]

#10762: Gzip Middleware Should Compress 201 (Created) Responses
-+-
   Reporter:  rwagner@…  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  middleware gzip
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * easy:   => 0


Comment:

 Regarding Rick's comment above: the content will only be gzipped if the
 user agent sent an `Accept-Encoding: gzip` header. It seems reasonable to
 assume it will be able to decode gzip, even if the server returns an error
 page.

-- 
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] #15995: Problems in ModelForm._post_clean

[Django]

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

Comment (by anonymous):

 Hmm, my suggested solution won't work out. It works in my case, but if
 someone supplies real data it won't get set :( On the other way I fail to
 find an easy way around it *gg*

-- 
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] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
-+-
   Reporter:  paltman|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2-beta   |   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
-+-

Comment (by Fredde):

 Replying to [comment:4 Alex]:
 > How are most of them wrong?  It's pretty trivial (there's actually an
 implementation in the tests).

 The JSONField included in the in the django tests
 ([source:django/trunk/tests/modeltests/field_subclassing/fields.py#L56])
 is actually not working properly eather. For example, when trying to store
 a empty list [] or dict {} the ''JSONField.to_python'' will convert it to
 None:

 {{{
 #python
 >>> class A(models.Model):
 json_field = JSONField()

 >>> a = A()
 >>> a.json_field = []
 >>> print a.json_fied
 None
 }}}

 I don't know how to fix this. From the documentation the following values
 should be handled by the ''to_python'' method:
  * An instance of the correct type (e.g., Hand in our ongoing example).
  * A string (e.g., from a deserializer).
  * Whatever the database returns for the column type you're using.

 Hovever, there is no way to know if the value is a "correct type" a
 serialized representation or the value from the database. For example
 value = '[1, 2, 3]'. It could eather come from an attribute assignment, or
 from the database, but it should only be deserialized if it's from the
 database.

-- 
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] #13756: File upload not working under Tomcat

[Django]

#13756: File upload not working under Tomcat
-+---
   Reporter:  SvenKlemm  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.2|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+---
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => invalid
 * needs_tests:  0 => 1
 * easy:   => 0


Comment:

 I'm following up on Jeff250's comment.

 PEP  says that `wsgi.input` is:
 > An input stream (file-like object) from which the HTTP request body
 bytes can be read. (The server or gateway may perform reads on-demand as
 requested by the application, or it may pre- read the client's request
 body and buffer it in-memory or on disk, or use any other technique for
 providing such an input stream, according to its preference.)

 It adds that:
 > The semantics of each method are as documented in the Python Library
 Reference

 

 In the Python Library Reference, the semantic of [file-like object].read()
 is:
 > Read at most size bytes from the file (less if the read hits EOF before
 obtaining size bytes).

 

 This means that:
 - WSGI does require a `wsgi.input` file object that blocks on reads until
 a buffer of ''exactly'' the requested length is returned, or EOF /
 Content-Length is reached,
 - the bug is in `modjy`, which does not provide an appropriate file-like
 object right now.

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

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

Re: [Django] #15852: Exception when http.parse_cookie recieves bad cookie

[Django]

#15852: Exception when http.parse_cookie recieves bad cookie
-+-
   Reporter:  Fredrik|  Owner:  nobody
  Stålnacke  | Status:  new
   Type:  Bug|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  parse_cookie
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => 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] #16035: GZipMiddleware doesn't change an ETag

[Django]

#16035: GZipMiddleware doesn't change an ETag
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  HTTP handling
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+---
Changes (by aaugustin):

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


Comment:

 Your patch should use the new way to alter settings during tests:
 https://docs.djangoproject.com/en/dev/topics/testing/#overriding-settings

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

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

[Changeset] r16315 - django/branches/releases/1.3.X/django/contrib/admin/media/css

[noreply]

Author: lukeplant
Date: 2011-06-02 05:20:11 -0700 (Thu, 02 Jun 2011)
New Revision: 16315

Modified:
   django/branches/releases/1.3.X/django/contrib/admin/media/css/rtl.css
Log:
[1.3.X] Fixed #16144 - layout of admin changelist broken for RTL languages.

Backport of [16314] from trunk.

Modified: django/branches/releases/1.3.X/django/contrib/admin/media/css/rtl.css
===
--- django/branches/releases/1.3.X/django/contrib/admin/media/css/rtl.css   
2011-06-02 12:19:32 UTC (rev 16314)
+++ django/branches/releases/1.3.X/django/contrib/admin/media/css/rtl.css   
2011-06-02 12:20:11 UTC (rev 16315)
@@ -46,6 +46,11 @@
 float: left;
 }
 
+thead th:first-child,
+tfoot td:first-child {
+border-left: 1px solid #ddd !important;
+}
+
 /* LAYOUT */
 
 #user-tools {
@@ -73,6 +78,19 @@
 margin-right: 10px !important;
 }
 
+/* SORTABLE TABLES */
+
+
+table thead th.sorted a {
+padding-left: 13px;
+padding-right: 0px;
+}
+
+table thead th.ascending a,
+table thead th.descending a {
+background-position: left;
+}
+
 /* dashboard styles */
 
 .dashboard .module table td a {
@@ -102,7 +120,7 @@
 border-right: 1px solid #ddd;
 }
 
-.change-list .filtered table, .change-list .filtered .paginator, .filtered 
#toolbar, .filtered div.xfull {
+.change-list .filtered .results, .change-list .filtered .paginator, .filtered 
#toolbar, .filtered div.xfull {
 margin-right: 0px !important;
 margin-left: 160px !important;
 }
@@ -123,6 +141,11 @@
 margin-right:0 !important;
 }
 
+#changelist table tbody td:first-child, #changelist table tbody th:first-child 
{
+border-right: 0;
+border-left: 1px solid #ddd;
+}
+
 /* FORMS */
 
 .aligned label {

-- 
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] #16144: Admin changelist quite broken for RTL

[Django]

#16144: Admin changelist quite broken for RTL
-+-
   Reporter:  lukeplant  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Release blocker
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by lukeplant):

 In [16315]:
 {{{
 #!CommitTicketReference repository="" revision="16315"
 [1.3.X] Fixed #16144 - layout of admin changelist broken for RTL
 languages.

 Backport of [16314] from trunk.
 }}}

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

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

[Changeset] r16314 - django/trunk/django/contrib/admin/media/css

[noreply]

Author: lukeplant
Date: 2011-06-02 05:19:32 -0700 (Thu, 02 Jun 2011)
New Revision: 16314

Modified:
   django/trunk/django/contrib/admin/media/css/rtl.css
Log:
Fixed #16144 - layout of admin changelist broken for RTL languages.

Modified: django/trunk/django/contrib/admin/media/css/rtl.css
===
--- django/trunk/django/contrib/admin/media/css/rtl.css 2011-06-02 00:24:37 UTC 
(rev 16313)
+++ django/trunk/django/contrib/admin/media/css/rtl.css 2011-06-02 12:19:32 UTC 
(rev 16314)
@@ -46,6 +46,11 @@
 float: left;
 }
 
+thead th:first-child,
+tfoot td:first-child {
+border-left: 1px solid #ddd !important;
+}
+
 /* LAYOUT */
 
 #user-tools {
@@ -73,6 +78,19 @@
 margin-right: 10px !important;
 }
 
+/* SORTABLE TABLES */
+
+
+table thead th.sorted a {
+padding-left: 13px;
+padding-right: 0px;
+}
+
+table thead th.ascending a,
+table thead th.descending a {
+background-position: left;
+}
+
 /* dashboard styles */
 
 .dashboard .module table td a {
@@ -102,7 +120,7 @@
 border-right: 1px solid #ddd;
 }
 
-.change-list .filtered table, .change-list .filtered .paginator, .filtered 
#toolbar, .filtered div.xfull {
+.change-list .filtered .results, .change-list .filtered .paginator, .filtered 
#toolbar, .filtered div.xfull {
 margin-right: 0px !important;
 margin-left: 160px !important;
 }
@@ -123,6 +141,11 @@
 margin-right:0 !important;
 }
 
+#changelist table tbody td:first-child, #changelist table tbody th:first-child 
{
+border-right: 0;
+border-left: 1px solid #ddd;
+}
+
 /* FORMS */
 
 .aligned label {

-- 
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] #16144: Admin changelist quite broken for RTL

[Django]

#16144: Admin changelist quite broken for RTL
-+-
   Reporter:  lukeplant  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Release blocker
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by lukeplant):

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


Comment:

 In [16314]:
 {{{
 #!CommitTicketReference repository="" revision="16314"
 Fixed #16144 - layout of admin changelist broken for RTL languages.
 }}}

-- 
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] #16144: Admin changelist quite broken for RTL

[Django]

#16144: Admin changelist quite broken for RTL
-+-
   Reporter:  lukeplant  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Confirmed, setting LANGUAGE_CODE to 'he' and USE_I18N to False triggers
 this problem.

-- 
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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  assigned
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 Regarding RTL, I discovered #16144, and need to fix that first. (Review
 appreciated on that, to ensure I haven't got a broken setup 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] #16136: Error was: cannot import name utils

[Django]

#16136: Error was: cannot import name utils
-+-
   Reporter: |  Owner:  nobody
  kurvenschubser@…   | Status:  reopened
   Type: |  Component:  Uncategorized
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by aaugustin):

 kurvenschubser, I just had a discussion with ramiro on IRC. To understand
 better your problem, here is what we need.

 1) Can you run the same project locally:
   - with runserver
   - with Apache + mod_wsgi
 and with MySQL. If this works, it means that the problem is triggered your
 hosting provider's setup.

 2) Could you post your settings file? If there is a circular import loop,
 it's probably triggered by your settings.

 Thanks.

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

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

[Django] #16144: Admin changelist quite broken for RTL

[Django]

#16144: Admin changelist quite broken for RTL
---+---
 Reporter:  lukeplant  |Owner:  nobody
 Type:  Bug|   Status:  new
Milestone: |Component:  contrib.admin
  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  |
---+---
 Various things are wrong with RTL changelist in Django 1.3, most
 noticeably the filters obscure the last column, and there is a big gap
 before the first column.

 Screenshot will be attached (names are fictitious, don't worry).

 Review appreciated to ensure that it isn't just me doing something stupid.

 The fix needs to be backported to 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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  assigned
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by julien):

 This is looking good. Could we get away by displaying the up/down arrow
 icons in the popup as well, instead of "(ascending) / (descending)" text?
 If not then the first approach mentioned by Jannis would be best.

 For the icon, a cog might possibly do (it's commonly used for displaying
 extra options in a popup menu). You can find a sample in
 http://www.famfamfam.com/lab/icons/silk/

 As for the tests, I think we should still add some to verify that
 `Model.Meta.ordering` and `ModelAdmin.ordering` are fully honoured.

 Also, I haven't tested this thoroughly yet, but how would this all fit
 with custom querysets (see #7309)?

-- 
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] #16136: Error was: cannot import name utils

[Django]

#16136: Error was: cannot import name utils
-+-
   Reporter: |  Owner:  nobody
  kurvenschubser@…   | Status:  reopened
   Type: |  Component:  Uncategorized
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 Replying to [comment:6 gloriajw]:
 > I found that this error occurred for me when I migrated files from
 another server, but forgot to change template path. I fixed the path, and
 the error stopped. I think a munged path in the settings file causes this.


 I take this back. This circular import happens all of the time, except
 when using sqlite.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #16022: Cyclic reference in FieldFile causes memory usage to grow considerably

[Django]

#16022: Cyclic reference in FieldFile causes memory usage to grow considerably
-+-
   Reporter:  Gustavo|  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution:  needsinfo  |   Severity:  Normal
   Triage Stage: |   Keywords:  memory leak
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by aaugustin):

 PS : closing the ticket as "needsinfo" is part of the standard triaging
 procedure when we can't reproduce a problem. It doesn't mean the problem
 doesn't exist.

-- 
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] #16022: Cyclic reference in FieldFile causes memory usage to grow considerably

[Django]

#16022: Cyclic reference in FieldFile causes memory usage to grow considerably
-+-
   Reporter:  Gustavo|  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution:  needsinfo  |   Severity:  Normal
   Triage Stage: |   Keywords:  memory leak
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 I read your email to django-users which had more info and I updated my
 test code above as follows.

 `receiver/models.py`:

 {{{
 from django import forms
 from django.db import models

 class UploadModel(models.Model):
 upload = models.FileField(upload_to='receiver')

 class UploadForm(forms.ModelForm):
 class Meta:
 model = UploadModel
 }}}

 `receiver/views.py`:
 {{{
 from django.http import HttpResponse
 from django.views.decorators.csrf import csrf_exempt

 from .models import UploadForm, UploadModel

 @csrf_exempt
 def upload(request, commit=False):
 form = UploadForm(request.POST, request.FILES)
 try:
 model = form.save(commit=commit)
 action = "Saved" if commit else "Received"
 return HttpResponse("%s %i bytes.\n" % (action,
 model.upload.size),
 status=201, content_type='text/plain')
 except ValueError:
 return HttpResponse(repr(form.errors) + "\n",
 status=400, content_type='text/plain')

 def names(request):
 upload_names = [model.upload.name for model in
 UploadModel.objects.all()]
 return HttpResponse("%i objects \n" % len(upload_names),
 status=200, content_type='text/plain')
 }}}

 `urls.py`:
 {{{
 from django.conf.urls.defaults import patterns, url

 urlpatterns = patterns('',
 url(r'^fake/$', 'receiver.views.upload', {'commit': False}),
 url(r'^save/$', 'receiver.views.upload', {'commit': True}),
 url(r'^read/$', 'receiver.views.names'),
 )
 }}}

 I added a database, etc. to the settings and ran `syncdb`.

 I uploaded 100 1kb files:

 {{{
 myk@mYk madupload % dd if=/dev/random of=1kb.bin bs=1024 count=1
 1+0 records in
 1+0 records out
 1024 bytes transferred in 0.000232 secs (4414149 bytes/sec)
 myk@mYk madupload % for i in {1..100}; do curl -F "upload=@1kb.bin"
 http://localhost:8000/save/; done
 Saved 1024 bytes.
 Saved 1024 bytes.
 Saved 1024 bytes.
 ...
 }}}

 And then I read them over and over:

 {{{
 myk@mYk madupload % while true; do curl http://localhost:8000/read/; done
 100 objects
 100 objects
 100 objects
 ...
 }}}

 I've been heating the planet like this for a few minutes and the memory
 curve climbed a little bit at the beginning, then stabilized.

 Initially, I was using Python 2.6; I switched to Python 2.5 but the result
 was the same.

 So, unfortunately, we still don't have a proof that the bug is in Django
 itself.

 At this point, I am afraid you didn't provide sufficient information for
 me to reproduce the bug. You could:

 - try to play with `gc.garbage` to see what happens in your app, see
 http://docs.python.org/library/gc.html
 - modify my example until it exhibits the memory leak
 - come up with your own reproducible example, and provide complete
 instructions of how to run it

 Thanks!

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

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

Re: [Django] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---
Changes (by ramiro):

 * has_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] #16025: distinct does not apply to aggregated querysets

[Django]

#16025: distinct does not apply to aggregated querysets
+-
   Reporter:  micolous  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  ORM aggregation
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
+-
Description changed by ramiro:

Old description:

> When applying .distinct() to a QuerySet, performing an aggregation using
> .aggregate() on that will only ensure that the aggregation result is
> distinct.  As a result, this prevents you from doing a query where you
> want the input to the aggregation to have distinct rows.
>
> Take the example models:
>
> {{{
> class Category(Model):
>   label = CharField(max_length=128)
>
> class Food(Model):
>   name = CharField(max_length=128)
>   categories = ManyToManyField(Category)
>   kilojoules_per_kg = PositiveIntegerField()
> }}}
>
> If you then did a query on which you selected a couple of Categories as
> foreign keys (eg: "Pizza Toppings" and "Fruits"), you'd end up with a
> list of Foods that would contain duplicates where a food item fits in
> multiple categories (eg: "Apple", "Orange", "Pineapple", "Pineapple",
> "Bacon" and "Cheese" ...).
>
> If you then wanted to then find the average number of kilojoules per
> kilogram for items in those groups and eliminate duplicates (Pineapple),
> the documentation would lead you to do this:
>
> {{{
> qs.distinct().aggregate(Average('kilojoules_per_kg'))
> }}}
>
> However instead of counting Pineapple once, Pineapple would be counted
> twice, as the distinct() call would only apply to the result of the
> aggregation, not to the input of it.
>
> {{{
> >>> qs.distinct().aggregate(Average('kilojoules_per_kg')) ==
> qs.aggregate(Average('kilojoules_per_kg'))
> True
> }}}
>
> Instead, .distinct() before .aggregate() should instead cause a subquery
> to be executed to filter the results before passing it to the aggregation
> functions.  There doesn't seem a way to presently execute a query like
> this using the Django ORM.
>
> .distinct() after an aggregation should cause the results of the
> aggregation to be filtered so only distinct records are returned (which
> is the current behavior).
>
> I've managed to confirm this behavior in Django 1.2.3 and 1.3.

New description:

 When applying .distinct() to a QuerySet, performing an aggregation using
 .aggregate() on that will only ensure that the aggregation result is
 distinct.  As a result, this prevents you from doing a query where you
 want the input to the aggregation to have distinct rows.

 Take the example models:

 {{{
 class Category(Model):
   label = CharField(max_length=128)

 class Food(Model):
   name = CharField(max_length=128)
   categories = ManyToManyField(Category)
   kilojoules_per_kg = PositiveIntegerField()
 }}}

 If you then did a query on which you selected a couple of Categories as
 foreign keys (eg: "Pizza Toppings" and "Fruits"), you'd end up with a list
 of Foods that would contain duplicates where a food item fits in multiple
 categories (eg: "Apple", "Orange", "Pineapple", "Pineapple", "Bacon" and
 "Cheese" ...).

 If you then wanted to then find the average number of kilojoules per
 kilogram for items in those groups and eliminate duplicates (Pineapple),
 the documentation would lead you to do this:

 {{{
 qs.distinct().aggregate(Avg('kilojoules_per_kg'))
 }}}

 However instead of counting Pineapple once, Pineapple would be counted
 twice, as the distinct() call would only apply to the result of the
 aggregation, not to the input of it.

 {{{
 >>> qs.distinct().aggregate(Avg('kilojoules_per_kg')) ==
 qs.aggregate(Avg('kilojoules_per_kg'))
 True
 }}}

 Instead, .distinct() before .aggregate() should instead cause a subquery
 to be executed to filter the results before passing it to the aggregation
 functions.  There doesn't seem a way to presently execute a query like
 this using the Django ORM.

 .distinct() after an aggregation should cause the results of the
 aggregation to be filtered so only distinct records are returned (which is
 the current behavior).

 I've managed to confirm this behavior in Django 1.2.3 and 1.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 thi

Re: [Django] #16022: Cyclic reference in FieldFile causes memory usage to grow considerably

[Django]

#16022: Cyclic reference in FieldFile causes memory usage to grow considerably
-+-
   Reporter:  Gustavo|  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  memory leak
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by Gustavo):

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


Comment:

 Hello, aaugustin.

 Thank you very much for looking into this!

 I forgot to add a useful piece of information here, which I mentioned on
 [http://groups.google.com/group/django-
 users/browse_thread/thread/804b4fd7a3d126fb Google Groups]: Memory
 increases considerably when you query a model that has a !FileField. I'm
 sorry about that.

 To reproduce this, you could create, say, 2000 records and iterate over
 them like this inside a Django view:

 {{{
 for record in MyModel.objects.all():
echo record.upload
 }}}

 As you refresh the page, you'll notice that memory increases.

 Cheers.

-- 
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] #16022: Cyclic reference in FieldFile causes memory usage to grow considerably

[Django]

#16022: Cyclic reference in FieldFile causes memory usage to grow considerably
-+-
   Reporter:  Gustavo|  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution: |   Severity:  Normal
  worksforme |   Keywords:  memory leak
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 OK, I tried to reproduce this seriously. I created a project called
 `madupload` and an app called `receiver` inside.
 {{{

 madupload
 ├── __init__.py
 ├── manage.py
 ├── receiver
 │   ├── __init__.py
 │   ├── models.py
 │   ├── views.py
 ├── settings.py
 └── urls.py
 }}}

 `receiver/models.py`:
 {{{
 from django import forms
 from django.db import models

 class UploadModel(models.Model):
 upload = models.FileField()

 class UploadForm(forms.ModelForm):
 class Meta:
 model = UploadModel
 }}}

 `receiver/views.py`:
 {{{
 from django.http import HttpResponse
 from django.views.decorators.csrf import csrf_exempt

 from .models import UploadForm

 @csrf_exempt
 def upload(request):
 form = UploadForm(request.POST, request.FILES)
 try:
 model = form.save(commit=False)
 return HttpResponse("Saved %i bytes.\n" % model.upload.size,
 status=201, content_type='text/plain')
 except ValueError:
 return HttpResponse(repr(form.errors) + "\n",
 status=400, content_type='text/plain')
 }}}

 `urls.py`:
 {{{
 from django.conf.urls.defaults import patterns, url

 urlpatterns = patterns('',
 url(r'^$', 'receiver.views.upload'),
 )
 }}}

 All other files are unchanged from Django's template.

 Then I launched `runserver` and started uploading:

 {{{
 myk@mYk madupload % dd if=/dev/random of=1mb.bin bs=1024 count=1024
 1024+0 records in
 1024+0 records out
 1048576 bytes transferred in 0.146655 secs (7149958 bytes/sec)
 myk@mYk madupload % while true; do curl -F "upload=@1mb.bin"
 http://localhost:8000; done
 Saved 1048576 bytes.
 Saved 1048576 bytes.
 Saved 1048576 bytes.
 ...
 }}}

 I've let it run more than one hundred of uploads, and the memory footprint
 of the Python process handling `runserver` is flat.

 At this point, I have proven that the cyclic reference in !FileField is
 not a problem in itself.

 I still don't know what's causing your bug. You may have a global variable
 referencing  your !FileField objects somewhere.

-- 
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] #16135: Model 'Child' is inherited from 'Parent', expecting to get only Child results with Parent.objects.filter(child__isnull=False), but does not work.

[Django]

#16135: Model 'Child' is inherited from 'Parent', expecting to get only Child
results with Parent.objects.filter(child__isnull=False), but does not work.
-+-
   Reporter:  robin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 I'm accepting the bug for two reasons:

 - `Parent.objects.filter(child__isnull=False)` and
 `Parent.objects.exclude(child__isnull=True)` should always give the same
 results.
 - Model inheritance and `OneToOneField` should give the same results — at
 least that's what the docs say:
 > The inheritance relationship introduces links between the child model
 and each of its parents (via an automatically-created OneToOneField).

 https://docs.djangoproject.com/en/dev/topics/db/models/#multi-table-
 inheritance

 It sounds like the wrong kind of join is used.

-- 
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] #16136: Error was: cannot import name utils

[Django]

#16136: Error was: cannot import name utils
-+-
   Reporter: |  Owner:  nobody
  kurvenschubser@…   | Status:  reopened
   Type: |  Component:  Uncategorized
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Old description:

> {{{
> Traceback (most recent call last):
>File "/usr/lib/python2.5/site-packages/django/core/handlers/wsgi.py",
> line 241, in __call__
>  response = self.get_response(request)
>File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py",
> line 141, in get_response
>  return self.handle_uncaught_exception(request, resolver,
> sys.exc_info())
>File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py",
> line 165, in handle_uncaught_exception
>  return debug.technical_500_response(request, *exc_info)
>File "/usr/lib/python2.5/site-packages/django/views/debug.py", line
> 58, in technical_500_response
>  html = reporter.get_traceback_html()
>File "/usr/lib/python2.5/site-packages/django/views/debug.py", line
> 137, in get_traceback_html
>  return t.render(c)
>File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
> line 173, in render
>  return self._render(context)
>File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
> line 167, in _render
>  return self.nodelist.render(context)
>File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
> line 796, in render
>  bits.append(self.render_node(node, context))
>File "/usr/lib/python2.5/site-packages/django/template/debug.py", line
> 72, in render_node
>  result = node.render(context)
>File "/usr/lib/python2.5/site-packages/django/template/debug.py", line
> 89, in render
>  output = self.filter_expression.resolve(context)
>File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
> line 579, in resolve
>  new_obj = func(obj, *arg_vals)
>File "/usr/lib/python2.5/site-
> packages/django/template/defaultfilters.py", line 697, in date
>  return format(value, arg)
>File "/usr/lib/python2.5/site-packages/django/utils/dateformat.py",
> line 281, in format
>  return df.format(format_string)
>File "/usr/lib/python2.5/site-packages/django/utils/dateformat.py",
> line 30, in format
>  pieces.append(force_unicode(getattr(self, piece)()))
>File "/usr/lib/python2.5/site-packages/django/utils/dateformat.py",
> line 187, in r
>  return self.format('D, j M Y H:i:s O')
>File "/usr/lib/python2.5/site-packages/django/utils/dateformat.py",
> line 30, in format
>  pieces.append(force_unicode(getattr(self, piece)()))
>File "/usr/lib/python2.5/site-packages/django/utils/encoding.py", line
> 66, in force_unicode
>  s = unicode(s)
>File "/usr/lib/python2.5/site-packages/django/utils/functional.py",
> line 206, in __unicode_cast
>  return self.__func(*self.__args, **self.__kw)
>File "/usr/lib/python2.5/site-
> packages/django/utils/translation/__init__.py", line 55, in ugettext
>  return real_ugettext(message)
>File "/usr/lib/python2.5/site-packages/django/utils/functional.py",
> line 55, in _curried
>  return _curried_func(*(args+moreargs), **dict(kwargs, **morekwargs))
>File "/usr/lib/python2.5/site-
> packages/django/utils/translation/__init__.py", line 36, in
> delayed_loader
>  return getattr(trans, real_name)(*args, **kwargs)
>File "/usr/lib/python2.5/site-
> packages/django/utils/translation/trans_real.py", line 276, in ugettext
>  return do_translate(message, 'ugettext')
>File "/usr/lib/python2.5/site-
> packages/django/utils/translation/trans_real.py", line 266, in
> do_translate
>  _default = translation(settings.LANGUAGE_CODE)
>File "/usr/lib/python2.5/site-
> packages/django/utils/translation/trans_real.py", line 176, in
> translation
>  default_translation = _fetch(settings.LANGUAGE_CODE)
>File "/usr/lib/python2.5/site-
> packages/django/utils/translation/trans_real.py", line 159, in _fetch
>  app = import_module(appname)
>File "/usr/lib/python2.5/site-packages/django/utils/importlib.py",
> line 35, in import_module
>  __import__(name)
>File "/usr/lib/python2.5/site-
> packages/django/contrib/admin/__init__.py", line 1, in 
>  from django.contrib.admin.helpers import ACTION_CHECKBOX_NAME
>File "/usr/lib/python2.5/site-
> packages/django/contrib/admin/helpers.py", line 1, in 
>  

Re: [Django] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |  Owner:  bendavis78
  bendavis78 | Status:  assigned
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  admin sort
Version:  SVN|  multisort ordering order
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by jezdez):

 Replying to [comment:20 lukeplant]:
 > Regarding showing 'ascending' or 'descending' on the popup, I don't know
 if I can come up with a method that is i18n friendly. I don't think we can
 assume that doing:
 > {{{
 >  * Field name (ascending)
 > }}}
 >
 > is going to look right in all languages (does Arabic use brackets like
 that, for instance?). So it's probably best to leave that for now.

 Something like this would work (pseudo code, assuming there would be a way
 to get the order in the templates):

 {{{
 {% if header.asc %}
 {% blocktrans with fieldname=header.fieldname %}{{ fieldname }}
 (ascending){% endblocktrans %}
 {% else %}
 {% blocktrans with fieldname=header.fieldname %}{{ fieldname }}
 (descending){% endblocktrans %}
 {% endif %}
 }}}

 or (but this is less preferable since 'ascending' and 'descending' might
 be translated differently depending on the context):

 {{{
 {% blocktrans with fieldname=header.fieldname order=header.order %}{{
 fieldname }} ({{ order }}){% endblocktrans %}
 }}}

 Either way the translators can manipulate the actual translation and RTL
 languages can handle it on their own.

 Which reminds me, you might want to extend `rtl.css` to cope with the
 right aligning.

-- 
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] #16140: Logging documentation should describe how to configure logging handlers.

[Django]

#16140: Logging documentation should describe how to configure logging handlers.
-+---
   Reporter:  ShawnMilo  |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  worksforme |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+---
Changes (by aaugustin):

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


Comment:

 Since nobody disagreed with my first comment after I asked on IRC, I am
 going to reject the ticket. Basically I don't see how we could improve the
 docs with regard to the points you raised.

-- 
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] #16143: Default settings.py file should fully qualify database name setting

[Django]

#16143: Default settings.py file should fully qualify database name setting
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Other)
Version:  1.3|   Severity:  Normal
 Resolution:  needsinfo  |   Keywords:  settings, database
   Triage Stage: |  name, sqlite3
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+-
Changes (by aaugustin):

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


Comment:

 In the default project template, the default value of NAME is empty :
 
https://code.djangoproject.com/browser/django/trunk/django/conf/project_template/settings.py

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.', # Add 'postgresql_psycopg2',
 'mysql', 'sqlite3' or 'oracle'.
 'NAME': '',  # Or path to database file if
 using sqlite3.
 'USER': '',  # Not used with sqlite3.
 'PASSWORD': '',  # Not used with sqlite3.
 'HOST': '',  # Set to empty string for
 localhost. Not used with sqlite3.
 'PORT': '',  # Set to empty string for
 default. Not used with sqlite3.
 }
 }
 }}}

 The tutorial docs are unambiguous :
 https://docs.djangoproject.com/en/1.3/intro/tutorial01/#database-setup

 > NAME -- The name of your database. If you're using SQLite, the database
 will be a file on your computer; in that case, **NAME should be the full
 absolute path, including filename, of that file**

 

 I don't understand how you obtained an "out of the box" solution with a
 relative name. Please tell us where you got that misleading information
 and re-open the ticket

 Note that if the problem is in Pinax, you should report it at
 http://code.pinaxproject.com/and not 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] #16063: Problem with searching in m2m fields in inherited model

[Django]

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

Comment (by esizikov):

 I have checked with Django 1.3 and can now confirm that the problem is
 still there. Django's ORM in 1.3 still generates SELECT with JOIN's for
 each {{{ qs = qs.filter(...) }}} call, which is going to be made per term
 in a search query.

-- 
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] #16143: Default settings.py file should fully qualify database name setting

[Django]

#16143: Default settings.py file should fully qualify database name setting
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  settings, database
   Triage Stage: |  name, sqlite3
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+-
Changes (by anonymous):

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


Comment:

 Edit:
 This might not be an ideal solution, though, because if you change the
 type of database to mySQL (or another), then the name shouldn't be so
 complicated.

-- 
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] #16143: Default settings.py file should fully qualify database name setting

[Django]

#16143: Default settings.py file should fully qualify database name setting
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Core
  Version:  1.3   |  (Other)
 Keywords:  settings, database name, sqlite3  |   Severity:  Normal
Has patch:  0 |   Triage Stage:  Unreviewed
  |  Easy pickings:  1
--+
 While struggling through trying to get a WSGI implementation of
 Django+Pinax up and running, I finally went back to the basics and just
 tried to get an "out of the box" Pinax basic project working.

 It worked fine using the development web server, but failed with the WSGI
 setup.

 I finally narrowed it down to the fact that Apache couldn't find the
 sqlite3 database.  And that was because the name wasn't fully qualified.

 My solution was to change the default definition of the database name in
 settings.py to
 "NAME": os.path.join(PROJECT_ROOT,"dev.db"),

 it was:
 "NAME": "dev.db",


 Not a major bug here, but I believe that the "out of the box" solution
 should work in multiple environments without jumping through a lot of
 hoops.  It just would have made my troubleshooting tonight a lot easier.

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