date:20110923

Re: [Django] #16878: Improve the "intword" filter

2011-09-23 Thread Django

#16878: Improve the "intword" filter
---+--
   Reporter:  crodjer  |  Owner:  crodjer
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  contrib.humanize
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by julien):

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


Comment:

 The `humanize` tests are failing, most likely because
 `intword_converters.items()` returns the items in the wrong order. The
 attached patch makes used of `SortedDict` to enforce a deterministic
 order.

-- 
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] #14597: request.is_secure() should support headers like: X-Forwarded-Protocol and X-Forwarded-Ssl

2011-09-23 Thread Django

#14597: request.is_secure() should support headers like: X-Forwarded-Protocol 
and X
-Forwarded-Ssl
-+---
   Reporter:  gnotaras   |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.2|   Severity:  Normal
 Resolution:  wontfix|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by PaulM):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 I raised this issue on the django-dev mailing list. Hopefully we can re-
 examine this issue.

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

-- 
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] r16898 - django/trunk/django/contrib/admindocs

2011-09-23 Thread noreply

Author: ramiro
Date: 2011-09-23 16:57:06 -0700 (Fri, 23 Sep 2011)
New Revision: 16898

Modified:
   django/trunk/django/contrib/admindocs/views.py
Log:
Removed unused code from admindocs app now that it supports reversing URLs.

As a consequence the undocumented `ADMIN_SITE_ROOT_URL` setting isn't used 
anymore.

Refs r8718 and r16857.

Modified: django/trunk/django/contrib/admindocs/views.py
===
--- django/trunk/django/contrib/admindocs/views.py  2011-09-23 16:45:40 UTC 
(rev 16897)
+++ django/trunk/django/contrib/admindocs/views.py  2011-09-23 23:57:06 UTC 
(rev 16898)
@@ -24,23 +24,17 @@
 domain = 'example.com'
 name = 'my site'
 
-def get_root_path():
-try:
-return urlresolvers.reverse('admin:index')
-except urlresolvers.NoReverseMatch:
-return getattr(settings, "ADMIN_SITE_ROOT_URL", "/admin/")
-
 @staff_member_required
 def doc_index(request):
 if not utils.docutils_is_available:
 return missing_docutils_page(request)
 return render_to_response('admin_doc/index.html', {
-'root_path': get_root_path(),
+'root_path': urlresolvers.reverse('admin:index'),
 }, context_instance=RequestContext(request))
 
 @staff_member_required
 def bookmarklets(request):
-admin_root = get_root_path()
+admin_root = urlresolvers.reverse('admin:index')
 return render_to_response('admin_doc/bookmarklets.html', {
 'root_path': admin_root,
 'admin_url': mark_safe("%s://%s%s" % (request.is_secure() and 'https' 
or 'http', request.get_host(), admin_root)),
@@ -77,7 +71,7 @@
 'library': tag_library,
 })
 return render_to_response('admin_doc/template_tag_index.html', {
-'root_path': get_root_path(),
+'root_path': urlresolvers.reverse('admin:index'),
 'tags': tags
 }, context_instance=RequestContext(request))
 
@@ -112,7 +106,7 @@
 'library': tag_library,
 })
 return render_to_response('admin_doc/template_filter_index.html', {
-'root_path': get_root_path(),
+'root_path': urlresolvers.reverse('admin:index'),
 'filters': filters
 }, context_instance=RequestContext(request))
 
@@ -142,7 +136,7 @@
 'url': simplify_regex(regex),
 })
 return render_to_response('admin_doc/view_index.html', {
-'root_path': get_root_path(),
+'root_path': urlresolvers.reverse('admin:index'),
 'views': views
 }, context_instance=RequestContext(request))
 
@@ -164,7 +158,7 @@
 for key in metadata:
 metadata[key] = utils.parse_rst(metadata[key], 'model', _('view:') + 
view)
 return render_to_response('admin_doc/view_detail.html', {
-'root_path': get_root_path(),
+'root_path': urlresolvers.reverse('admin:index'),
 'name': view,
 'summary': title,
 'body': body,
@@ -177,7 +171,7 @@
 return missing_docutils_page(request)
 m_list = [m._meta for m in models.get_models()]
 return render_to_response('admin_doc/model_index.html', {
-'root_path': get_root_path(),
+'root_path': urlresolvers.reverse('admin:index'),
 'models': m_list
 }, context_instance=RequestContext(request))
 
@@ -207,7 +201,7 @@
 # ForeignKey is a special case since the field will actually be a
 # descriptor that returns the other object
 if isinstance(field, models.ForeignKey):
-data_type = related_object_name = field.rel.to.__name__
+data_type = field.rel.to.__name__
 app_label = field.rel.to._meta.app_label
 verbose = utils.parse_rst((_("the related 
`%(app_label)s.%(data_type)s` object")  % {'app_label': app_label, 'data_type': 
data_type}), 'model', _('model:') + data_type)
 else:
@@ -222,7 +216,7 @@
 
 # Gather many-to-many fields.
 for field in opts.many_to_many:
-data_type = related_object_name = field.rel.to.__name__
+data_type = field.rel.to.__name__
 app_label = field.rel.to._meta.app_label
 verbose = _("related `%(app_label)s.%(object_name)s` objects") % 
{'app_label': app_label, 'object_name': data_type}
 fields.append({
@@ -269,7 +263,7 @@
 'verbose'   : utils.parse_rst(_("number of %s") % verbose , 
'model', _('model:') + opts.module_name),
 })
 return render_to_response('admin_doc/model_detail.html', {
-'root_path': get_root_path(),
+'root_path': urlresolvers.reverse('admin:index'),
 'name': '%s.%s' % (opts.app_label, opts.object_name),
 'summary': _("Fields on %s objects") % opts.object_name,
 'description': model.__doc__,
@@ -296,7 +290,7 @@
 'order': list(settings_mod.TEMPLATE_DIRS).index(dir),
 })
 return render_to_response('admin_doc/template_detail.html', {
-'root_path': get_root_path(),
+'root_path':

Re: [Django] #16918: BaseDateDetailView's get_object ignores queryset argument

2011-09-23 Thread Django

#16918: BaseDateDetailView's get_object ignores queryset argument
+---
   Reporter:  mitar |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Generic views
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:  1
  UI/UX:  0 |
+---
Changes (by mattmcc):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #14678: Users are able to add more than one page to the same url

2011-09-23 Thread Django

#14678: Users are able to add more than one page to the same url
-+-
   Reporter:  seler  |  Owner:  j4nu5
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  contrib.flatpages
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  flatpages, unique,
   Triage Stage:  Accepted   |  sites
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by j4nu5):

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


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

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

Re: [Django] #14574: Initial values support for inline model formsets

2011-09-23 Thread Django

#14574: Initial values support for inline model formsets
-+-
   Reporter:  simon29|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  inlineformset_factory
   Triage Stage:  Accepted   |  BaseInlineFormSet BaseModelFormSet
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by claudep):

 * needs_tests:  1 => 0


Comment:

 This second patch is more elaborate, as it includes tests and also adds
 support for inline model formsets (taken from initial patch).

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

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

Re: [Django] #14678: Users are able to add more than one page to the same url

2011-09-23 Thread Django

#14678: Users are able to add more than one page to the same url
-+-
   Reporter:  seler  |  Owner:  j4nu5
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  contrib.flatpages
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  flatpages, unique,
   Triage Stage:  Accepted   |  sites
Needs documentation:  1  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by carljm):

 After IRC discussion with Alex and James, the consensus is that the
 m2m_changed handler raising `IntegrityError` is overkill here, given the
 unlikelihood that anyone is actually doing anything with flatpages outside
 the admin, and the un-usefulness of raw `IntegrityError` that isn't
 handled by a validation step.

 So the approach we'd like to take is to add the validation in the form's
 clean() method, move the form out into forms.py, document its existence
 and note the validation that it performs in case users are writing their
 own flatpage-creation or editing views.

 This means the existing patch flatpages-ticket14678-2.diff attached by
 graham_king is close, it just needs the form moved out into forms.py and
 the documentation notes.

-- 
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] #16922: Add a template-based form rendering system

2011-09-23 Thread Django

#16922: Add a template-based form rendering system
---+
   Reporter:  carljm   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Forms
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  form-rendering
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+
Changes (by carljm):

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

[Django] #16922: Add a template-based form rendering system

2011-09-23 Thread Django

#16922: Add a template-based form rendering system
+
Reporter: carljm |Owner: nobody
Type: New feature | Status: new
Milestone: |Component: Forms
Version: SVN | Severity: Normal
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
+
This was accepted as a GSoC project for 2011, and the work was done by
Gregor Müllegger. There were [http://groups.google.com/group/django-

developers/browse_frm/thread/3791152616fd95ae/6bbb2bf4d2f6752c?lnk=gst=form+rendering+api#6bbb2bf4d2f6752c
extensive discussions] on the django-developers mailing list about the
API.

This ticket is to track the remaining work to get this template-based form
rendering API into trunk. The most recent code is at
https://github.com/carljm/django/compare/master...soc2011%2Fform-rendering
- that branch also contains code for #15667 and #16921.

I expect that of those three tickets, #16921 can be merged first, then
#15667, and this one last.

The primary issue that still needs to be resolved on this ticket, as well
as #15667, is performance. https://github.com/carljm/formrenderbench can
help with setting up benchmarks.

--
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] #16921: Add assertHTMLEqual and related assert methods to TestCase

2011-09-23 Thread Django

#16921: Add assertHTMLEqual and related assert methods to TestCase
---+---
   Reporter:  carljm   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Testing framework
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  form-rendering
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by carljm):

 The Python standard library HTMLParser bug described
 [https://github.com/gregmuellegger/django/issues/1 here] and
 [http://bugs.python.org/issue670664 here] is an issue that needs to be
 resolved before this patch is ready for trunk. One possible workaround is
 demonstrated [https://github.com/jedie/django-
 tools/commit/aa722b3ddeaa7989fc497665ca894ab9282fe0dd 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.

[Django] #16921: Add assertHTMLEqual and related assert methods to TestCase

2011-09-23 Thread Django

#16921: Add assertHTMLEqual and related assert methods to TestCase
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  new
Milestone:   |Component:  Testing
  Version:  SVN  |  framework
 Keywords:  form-rendering   | Severity:  Normal
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
 This need came out of the form-rendering GSoC branch, due to a bunch of
 existing form rendering tests that test against HTML strings. Switching to
 template-based rendering would often cause spurious test failures due to
 irrelevant differences in HTML tag attribute ordering or whitespace. So in
 the branch we've added `assertHTMLEqual` and `assertHTMLNotEqual` methods,
 as well as a boolean "html" argument to `assertContains`.

 These additions can be committed separately from the rest of the branch,
 but need to be split out first.

 Most up-to-date code for the branch is at
 https://github.com/carljm/django/compare/master...soc2011%2Fform-rendering

-- 
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] #15667: Implement template-based widget rendering

2011-09-23 Thread Django

#15667: Implement template-based widget rendering
---+
   Reporter:  brutasse |  Owner:  brutasse
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Forms
Version:   |   Severity:  Normal
 Resolution:   |   Keywords:  form-rendering
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+
Changes (by carljm):

 * keywords:   => form-rendering
 * needs_better_patch:  0 => 1
 * ui_ux:   => 0


Comment:

 Currently, the most up-to-date version of this patch lives in the 2011
 GSoC form-rendering branch. The original GSoC branch is at
 https://github.com/gregmuellegger/django/compare/master...soc2011%2Fform-
 rendering and I've been making some further updates in
 https://github.com/carljm/django/compare/master...soc2011%2Fform-rendering

 That branch combines the templated widgets with a new form-rendering API.
 The problem with the branch is still speed, and since it doesn't appear
 we're going to get speed improvements in the template language in the
 short term from Armin's GSoC, we need to look for other solutions. My
 planned next step is to split back out just the templated-widgets from the
 form-rendering branch in order to focus on seeing if we can improve that
 to the point where we can commit it and close this ticket. Then we can
 deal with the rest of the form-rendering API in a separate step.

 There's also a bit of a framework for speed comparisons using djangobench
 here: https://github.com/carljm/formrenderbench

-- 
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] #5625: Custom admin views get wrong 'Home' breadcrumb url

2011-09-23 Thread Django

#5625: Custom admin views get wrong 'Home' breadcrumb url
-+-
   Reporter:  Bjorn  |  Owner:  nobody
  Ruud | Status:  closed
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  duplicate  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by ramiro):

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


Comment:

 Duplicate of #15294.

-- 
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] #16884: Add message level argument to ModelAdmin's message_user

2011-09-23 Thread Django

#16884: Add message level argument to ModelAdmin's message_user
+---
   Reporter:  shelldweller  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  admin
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+---

Comment (by ramiro):

 #15007 asked for the type of the message shown after adding a model
 instance to be ''success'' instead of ''info''. I closed it as duplicate
 of this one becasue it would provide the feature needed to set different
 types to messages related to different admin actions.

-- 
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] #15007: Wrong message-tag when successfully adding an entry

2011-09-23 Thread Django

#15007: Wrong message-tag when successfully adding an entry
-+---
   Reporter:  parsch |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.admin
Version:  1.2|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+---
Changes (by ramiro):

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


Comment:

 I'm closing this as a duplicate of #16884 that proposes the same as
 comment:2.

-- 
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] #13900: New admin feature: Delete and replace with existing object (was: New admin feature: Delete and replace with existing ocject)

2011-09-23 Thread Django

#13900: New admin feature: Delete and replace with existing object
-+-
   Reporter: |  Owner:  nobody
  riccardodivirgilio | Status:  new
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  admin, delete_view
Version:  SVN|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-
Changes (by ramiro):

 * easy:   => 0


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

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

Re: [Django] #14678: Users are able to add more than one page to the same url

2011-09-23 Thread Django

#14678: Users are able to add more than one page to the same url
-+-
   Reporter:  seler  |  Owner:  j4nu5
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  contrib.flatpages
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  flatpages, unique,
   Triage Stage:  Accepted   |  sites
Needs documentation:  1  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by carljm):

 Replying to [comment:20 carljm]:
 > After poking around a bit, I think we'd be better off to pre-emptively
 trap the problem in the `clean` method of `FlatpageForm`, rather than
 trying to catch the `IntegrityError` after the fact. The latter requires
 special-casing in the view, which is always a last resort. Model-
 validation doesn't have access to m2m data, but a form's clean method
 does. The form should perhaps also be moved out of `admin.py` and into a
 new `forms.py`, so it's clearer that it's not just admin-specific but is
 useful for user code dealing with flatpages. And it should be documented.
 >
 > And I think we should leave the current patch's signal-receiver in place
 that raises `IntegrityError` - that provides earlier warning for anyone
 writing code to save flatpages that doesn't go through the validation in
 `FlatpageForm`. (The documentation for `FlatpageForm` should mention that
 it validates this uniqueness requirement, and that any user code that
 saves flatpages should do so too or be prepared to catch
 `IntegrityError`).
 >
 > As far as I can see, this is the best compromise we have available,
 since model-validation simply isn't able to handle validation of m2m
 fields (at least not in time to work nicely with a `ModelForm`).

 I just realized that this proposal is essentially to combine the two
 patches that have already been proposed on this ticket.

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

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

Re: [Django] #14678: Users are able to add more than one page to the same url

2011-09-23 Thread Django

#14678: Users are able to add more than one page to the same url
-+-
   Reporter:  seler  |  Owner:  j4nu5
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  contrib.flatpages
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  flatpages, unique,
   Triage Stage:  Accepted   |  sites
Needs documentation:  1  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by carljm):

 Replying to [comment:19 j4nu5]:
 > I can catch the exception in Flatpage's ModelForm and display a message
 (from django.contrib) or something similar but the calling view is
 expecting the object to be successfully saved when it calls form's save
 method and thus, those view have to be made aware of the fact that an
 error may occur when form.save is called and therefore have to be patched.
 >
 > Since the views have to be patched anyway, why don't we leave the error
 catching mechanism in ModelForm and instead put it the views which call
 form.save (add_view and change_view in admin specifically). We can then
 update the documentation stating that custom Flatpage views should expect
 IntegrityError when calling the save method. Its a bit ugly but prettier
 than other options. Tell me what you think.

 After poking around a bit, I think we'd be better off to pre-emptively
 trap the problem in the `clean` method of `FlatpageForm`, rather than
 trying to catch the `IntegrityError` after the fact. The latter requires
 special-casing in the view, which is always a last resort. Model-
 validation doesn't have access to m2m data, but a form's clean method
 does. The form should perhaps also be moved out of `admin.py` and into a
 new `forms.py`, so it's clearer that it's not just admin-specific but is
 useful for user code dealing with flatpages. And it should be documented.

 And I think we should leave the current patch's signal-receiver in place
 that raises `IntegrityError` - that provides earlier warning for anyone
 writing code to save flatpages that doesn't go through the validation in
 `FlatpageForm`. (The documentation for `FlatpageForm` should mention that
 it validates this uniqueness requirement, and that any user code that
 saves flatpages should do so too or be prepared to catch
 `IntegrityError`).

 As far as I can see, this is the best compromise we have available, since
 model-validation simply isn't able to handle validation of m2m fields (at
 least not in time to work nicely with a `ModelForm`).

-- 
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] #16913: Admin error when trying to delete object with a GenericRelation

2011-09-23 Thread Django

#16913: Admin error when trying to delete object with a GenericRelation
-+---
   Reporter:  r1cky  |  Owner:  carljm
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by carljm):

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


Comment:

 Thanks!

 Closing this as duplicate of #16920, since that's the real bug 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] #16920: Models with GenericRelation are unnecessarily validated for clashes in reverse manager accessor

2011-09-23 Thread Django

#16920: Models with GenericRelation are unnecessarily validated for clashes in
reverse manager accessor
-+-
   Reporter:  r1cky  |  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
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by carljm):

 Also, as part of this fix `GenericRelation` should probably be modified so
 it doesn't silently accept the useless (and problematic) `related_name`
 argument 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] #16920: Models with GenericRelation are unnecessarily validated for clashes in reverse manager accessor

2011-09-23 Thread Django

#16920: Models with GenericRelation are unnecessarily validated for clashes in
reverse manager accessor
-+-
   Reporter:  r1cky  |  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
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 This probably blocks on #16905.

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

2011-09-23 Thread Django

#13165: Display edit link beside add button for ForeignKey fields in admin
-+-
   Reporter:  DrMeers|  Owner:  stefanw
   Type:  New| Status:  new
  feature|  Component:  contrib.admin
  Milestone:  1.3|   Severity:  Normal
Version:  SVN|   Keywords:  admin foreign key
 Resolution: |  edit link
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
Changes (by stefanw):

 * owner:  DrMeers => stefanw
 * needs_better_patch:  1 => 0
 * status:  reopened => new


Comment:

 I ported the latest patch to trunk including the following additional
 changes:

  - CSS names now contain - (dashes) instead of _ (underscores)
  - link generation in admin.util.get_changelink_html includes escaping

 The related-field-changelink CSS class needs some styling (like vertical-
 align: middle or something).

-- 
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] #14678: Users are able to add more than one page to the same url

2011-09-23 Thread Django

#14678: Users are able to add more than one page to the same url
-+-
   Reporter:  seler  |  Owner:  j4nu5
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  contrib.flatpages
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  flatpages, unique,
   Triage Stage:  Accepted   |  sites
Needs documentation:  1  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by j4nu5):

 Replying to [comment:18 carljm]:
 > In any case, comment 9 is still inaccurate since m2m's can't go in
 unique_together. And j4nu5 is right that it can't go in the model
 validation code on the `FlatPage` model because m2ms haven't even been
 saved at that point. I think the options are either m2m_changed signal, or
 adding an explicit through model to the m2m and doing the validation
 there. In the end those will look pretty similar. In either case, the
 trick is finding a way that that error can be caught and presented nicely
 at the `ModelForm` layer (most importantly for the admin, but it should
 ideally not be implemented just for the admin), rather than just raising
 an `IntegrityError`. I don't think the current patch takes care of this.
 > > I can catch the exception in Flatpage's ModelForm and display a
 message (from django.contrib) or something similar but the calling view is
 expecting the object to be successfully saved when it calls form's save
 method and thus, those view have to be made aware of the fact that an
 error may occur when form.save is called and therefore have to be patched.

 > > Since the views have to be patched anyway, why don't we leave the
 error catching mechanism in ModelForm and instead put it the views which
 call form.save (add_view and change_view in admin specifically). We can
 then update the documentation stating that custom Flatpage views should
 expect IntegrityError when calling the save method. Its a bit ugly but
 prettier than other options. Tell me what you think.

-- 
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] r16897 - in django/trunk: django/contrib/humanize django/contrib/humanize/locale/en/LC_MESSAGES django/contrib/humanize/templatetags docs/ref/contrib tests/regressiontests

2011-09-23 Thread noreply

Author: jezdez
Date: 2011-09-23 09:45:40 -0700 (Fri, 23 Sep 2011)
New Revision: 16897

Added:
   django/trunk/django/contrib/humanize/models.py
   django/trunk/django/contrib/humanize/tests.py
Removed:
   django/trunk/tests/regressiontests/humanize/
Modified:
   django/trunk/django/contrib/humanize/locale/en/LC_MESSAGES/django.po
   django/trunk/django/contrib/humanize/templatetags/humanize.py
   django/trunk/docs/ref/contrib/humanize.txt
Log:
Fixed #16878 -- Improved intword filter to support numbers up to decillion and 
googol. Thanks to crodjer for the initial patch.

Modified: django/trunk/django/contrib/humanize/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/contrib/humanize/locale/en/LC_MESSAGES/django.po
2011-09-23 16:33:52 UTC (rev 16896)
+++ django/trunk/django/contrib/humanize/locale/en/LC_MESSAGES/django.po
2011-09-23 16:45:40 UTC (rev 16897)
@@ -4,14 +4,27 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-05-16 17:30+0200\n"
+"POT-Creation-Date: 2011-09-23 17:43+0200\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
+"Language: en\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 
+#: tests.py:101 templatetags/humanize.py:170
+msgid "today"
+msgstr ""
+
+#: tests.py:101 templatetags/humanize.py:174
+msgid "yesterday"
+msgstr ""
+
+#: tests.py:101 templatetags/humanize.py:172
+msgid "tomorrow"
+msgstr ""
+
 #: templatetags/humanize.py:25
 msgid "th"
 msgstr ""
@@ -28,148 +41,248 @@
 msgid "rd"
 msgstr ""
 
-#: templatetags/humanize.py:78
+#: templatetags/humanize.py:57
 #, python-format
 msgid "%(value).1f million"
 msgid_plural "%(value).1f million"
 msgstr[0] ""
 msgstr[1] ""
 
-#: templatetags/humanize.py:79
+#: templatetags/humanize.py:58
 #, python-format
 msgid "%(value)s million"
 msgid_plural "%(value)s million"
 msgstr[0] ""
 msgstr[1] ""
 
-#: templatetags/humanize.py:84
+#: templatetags/humanize.py:61
 #, python-format
 msgid "%(value).1f billion"
 msgid_plural "%(value).1f billion"
 msgstr[0] ""
 msgstr[1] ""
 
-#: templatetags/humanize.py:85
+#: templatetags/humanize.py:62
 #, python-format
 msgid "%(value)s billion"
 msgid_plural "%(value)s billion"
 msgstr[0] ""
 msgstr[1] ""
 
-#: templatetags/humanize.py:90
+#: templatetags/humanize.py:65
 #, python-format
 msgid "%(value).1f trillion"
 msgid_plural "%(value).1f trillion"
 msgstr[0] ""
 msgstr[1] ""
 
-#: templatetags/humanize.py:91
+#: templatetags/humanize.py:66
 #, python-format
 msgid "%(value)s trillion"
 msgid_plural "%(value)s trillion"
 msgstr[0] ""
 msgstr[1] ""
 
-#: templatetags/humanize.py:108
+#: templatetags/humanize.py:69
+#, python-format
+msgid "%(value).1f quadrillion"
+msgid_plural "%(value).1f quadrillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:70
+#, python-format
+msgid "%(value)s quadrillion"
+msgid_plural "%(value)s quadrillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:73
+#, python-format
+msgid "%(value).1f quintillion"
+msgid_plural "%(value).1f quintillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:74
+#, python-format
+msgid "%(value)s quintillion"
+msgid_plural "%(value)s quintillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:77
+#, python-format
+msgid "%(value).1f sextillion"
+msgid_plural "%(value).1f sextillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:78
+#, python-format
+msgid "%(value)s sextillion"
+msgid_plural "%(value)s sextillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:81
+#, python-format
+msgid "%(value).1f septillion"
+msgid_plural "%(value).1f septillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:82
+#, python-format
+msgid "%(value)s septillion"
+msgid_plural "%(value)s septillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:85
+#, python-format
+msgid "%(value).1f octillion"
+msgid_plural "%(value).1f octillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:86
+#, python-format
+msgid "%(value)s octillion"
+msgid_plural "%(value)s octillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:89
+#, python-format
+msgid "%(value).1f nonillion"
+msgid_plural "%(value).1f nonillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:90
+#, python-format
+msgid "%(value)s nonillion"
+msgid_plural "%(value)s nonillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:93
+#, python-format
+msgid "%(value).1f decillion"
+msgid_plural "%(value).1f decillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:94
+#, python-format
+msgid "%(value)s decillion"
+msgid_plural "%(value)s decillion"
+msgstr[0] ""
+msgstr[1] ""
+
+#: templatetags/humanize.py:97
+#, python-format
+msgid "%(value).1f googol"
+msgid_plural "%(value).1f googol"

Re: [Django] #16878: Improve the "intword" filter

2011-09-23 Thread Django

#16878: Improve the "intword" filter
---+--
   Reporter:  crodjer  |  Owner:  crodjer
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  contrib.humanize
Version:  SVN  |   Severity:  Normal
 Resolution:  fixed|   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by jezdez):

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


Comment:

 In [16897]:
 {{{
 #!CommitTicketReference repository="" revision="16897"
 Fixed #16878 -- Improved intword filter to support numbers up to decillion
 and googol. Thanks to crodjer for the initial patch.
 }}}

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

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

[Changeset] r16896 - django/trunk

2011-09-23 Thread noreply

Author: jacob
Date: 2011-09-23 09:33:52 -0700 (Fri, 23 Sep 2011)
New Revision: 16896

Modified:
   django/trunk/README
Log:
Test commit - please ignore.

Modified: django/trunk/README
===
--- django/trunk/README 2011-09-23 04:22:30 UTC (rev 16895)
+++ django/trunk/README 2011-09-23 16:33:52 UTC (rev 16896)
@@ -43,5 +43,3 @@
 * Follow the instructions in the "Unit tests" section of
   docs/internals/contributing/writing-code/unit-tests.txt, published 
online at
   
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#running-the-unit-tests
-
-

-- 
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] #14574: Initial values support for inline model formsets

2011-09-23 Thread Django

#14574: Initial values support for inline model formsets
-+-
   Reporter:  simon29|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  inlineformset_factory
   Triage Stage:  Accepted   |  BaseInlineFormSet BaseModelFormSet
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0


Comment:

 I attached a starting point for supporting initial values for model
 formsets. If this approach and implementation is accepted, I might then
 work on tests and maybe adding an example to the doc.

-- 
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] #16903: Add '--no-location' option for 'makemessages' command

2011-09-23 Thread Django

#16903: Add '--no-location' option for 'makemessages' command
-+-
   Reporter:  alpar  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-

Comment (by alpar):

 Replying to [comment:1 aaugustin]:
 > It would be nice to add a test in tests/regressiontests/i18n/commands.

 The [attachment:no-location-with-tests.patch newly attached patch] also
 performs some basic tests. Let me know if this is sufficient or not.

 (Thanks for the help on testing.)

-- 
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] #16920: Models with GenericRelation are unnecessarily validated for clashes in reverse manager accessor

2011-09-23 Thread Django

#16920: Models with GenericRelation are unnecessarily validated for clashes in
reverse manager accessor
-+-
   Reporter:  r1cky  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by jsocol):

 * cc: james@… (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

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

Re: [Django] #16913: Admin error when trying to delete object with a GenericRelation

2011-09-23 Thread Django

#16913: Admin error when trying to delete object with a GenericRelation
+---
   Reporter:  r1cky |  Owner:  carljm
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---

Comment (by r1cky):

 Replying to [comment:5 r1cky]:
 > Replying to [comment:4 carljm]:
 > > Yeah, that's a bug. If no reverse manager is actually added, there's
 no collision. Mind filing that one too?
 > Sure, will do!
 Filed #16920

-- 
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] #159: Circular logout problem

2011-09-23 Thread Django

#159: Circular logout problem
+
   Reporter:  Manuzhai  |  Owner:  ashchristopher
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:|   Severity:  Normal
 Resolution:|   Keywords:  admin logout
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
Changes (by ashchristopher):

 * owner:  adrian => ashchristopher
 * status:  reopened => new


-- 
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] #16873: removal of deprecated settings.DATABASE code causes shell scripts to raise ImproperlyConfigured

2011-09-23 Thread Django

#16873: removal of deprecated settings.DATABASE code causes shell scripts to 
raise
ImproperlyConfigured
-+-
   Reporter:  ptone  |  Owner:  ptone
   Type:  Bug| Status:  assigned
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Release blocker
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by ptone):

 OK, reset the branch on the pull with the improved implementation - reran
 test suite - all OK.

 conferred with jezdez on IRC and he backs basic approach as suggested by
 carljm

-- 
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] #16919: Pass user to set_password_form in GET requests

2011-09-23 Thread Django

#16919: Pass user to set_password_form in GET requests
--+--
 Reporter:  jaimeirurzun  |  Owner:  nobody
 Type:  New feature   | Status:  new
Milestone:|  Component:  contrib.auth
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+--
 SetPasswordForm is being passed None on GET requests even though there is
 always a user available at that point. This patch passes user, so you can
 use it in the form constructor for whatever - e.g. populate initial with
 values that depend on the user involved.

-- 
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] #10933: Avoid " TypeError: Cannot convert Decimal("0.0000") to Decimal " when the decimal module has been reloaded

2011-09-23 Thread Django

#10933: Avoid " TypeError: Cannot convert Decimal("0.") to Decimal  " when 
the
decimal module has been reloaded
-+-
   Reporter:  gagravarr  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  dceu2011
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by ejohnstone@…):

 Here's the approach I am taking, now, that seems to be working.  First
 thanks for the str() suggestion.  It seemed to work sometimes, meaning I
 didn't catch it in all places or there was something else going on.

 However I found that configurations #2 and #3 below worked, so far,
 without depending on the str() fix.

 I will post 3 configurations from my /usr/local/etc/apache22/extra/httpd-
 vhosts.conf (FreeBSD path).  The first one is the configuration that does
 not work, i.e that gives the error.  The second one works, and the third
 one works.  I've commented them with the relevant information, and I'm
 currently using the third one.


 {{{
   ServerName my_site.com
   ..
   ..
   ## Configuration #1
   ## WSGIScriptAlias / /path_to_my_app/apache/django.wsgi

   ## Configuration #2
   ## Solved decimal loading problem
   ## http://www.defitek.com/blog/2010/06/29/cant-adapt-type-decimal-
 error-with-django-apache-postgresql-psycopg2/
   ## http://groups.google.com/group/django-
 users/browse_thread/thread/44c2670de1509ac5
   ## WSGIDaemonProcess my_site
   ## WSGIScriptAlias / /path_to_my_app/apache/django.wsgi process-
 group=my_site application-group=%{GLOBAL}

   ## Configuration #3
   ## Also solved decimal loading problem
   ## From "Django 1.1 Testing and Debugging" by Karen M. Tracey
   ## Great! book
   WSGIScriptAlias / /path_to_my_app/apache/django.wsgi
   WSGIDaemonProcess my_site
   WSGIProcessGroup my_site

 }}}

 Information about version, OS, hardware:
 {{{
 pkg_info -XI 'wsgi|python|django|apache' |egrep -v registration
 ap22-mod_wsgi-3.3_1 Python WSGI adapter module for Apache
 apache-2.2.19   Version 2.2.x of Apache web server with prefork MPM.
 py27-django-1.3 High-level Python Web framework
 python27-2.7.2_1An interpreted object-oriented programming language

 uname -rpmi
 8.0-RELEASE-p4-jc2 amd64 amd64 jail8
 }}}

-- 
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] #16873: removal of deprecated settings.DATABASE code causes shell scripts to raise ImproperlyConfigured

2011-09-23 Thread Django

#16873: removal of deprecated settings.DATABASE code causes shell scripts to 
raise
ImproperlyConfigured
-+-
   Reporter:  ptone  |  Owner:  ptone
   Type:  Bug| Status:  assigned
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Release blocker
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by ptone):

 Replying to [comment:5 carljm]:
 > Ok, so sorry I didn't think of this until after your good work on the
 patch, but - why don't we just put the default dummy-backend database in
 `conf/global_settings.py` instead? It's simpler and should have the same
 effect. In "normal" cases it will have no impact because there will be a
 DATABASES setting in the settings module that overrides it, but it'll
 provide the dummy default backend for the settings.configure() case. Any
 issues with this approach that I'm overlooking?

 I can't think of any issue with that - I just didn't know enough about the
 default conf being in there.  Its all good learning experience.

 Not sure about testing - seems like there is no "behavior" to test - no
 code to speak of really.

-- 
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] #8060: Admin Inlines do not respect user permissions

2011-09-23 Thread Django

#8060: Admin Inlines do not respect user permissions
-+-
   Reporter: |  Owner:  sjaensch
  p.patruno@…| Status:  assigned
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  inlines User
 Resolution: |  authentication
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by sjaensch):

 I added a new patch with all the changes requested by carljm. diff_v2_v3
 shows the difference between this patch and the last. All the inline
 permission tests are split up now and are in their own TestCase class.

-- 
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] #16455: Postgis 2.0 Compatibility

2011-09-23 Thread Django

#16455: Postgis 2.0 Compatibility
---+-
   Reporter:  ckarrie  |  Owner:  jbronn
   Type:  New feature  | Status:  assigned
  Milestone:  1.4  |  Component:  GIS
Version:  1.3-beta |   Severity:  Normal
 Resolution:   |   Keywords:  postgis 2.0
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+-
Changes (by cmutel@…):

 * cc: cmutel@… (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] #16878: Improve the "intword" filter

2011-09-23 Thread Django

#16878: Improve the "intword" filter
---+--
   Reporter:  crodjer  |  Owner:  crodjer
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.humanize
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+--

Comment (by crodjer):

 Replying to [comment:8 jezdez]:
 >
 > That's not enough, the string needs to be one and only one string to be
 translated, not something that consists of two separate strings.
 >
 > > In the commit, I have manually edited only one language translation
 file (de) for use in the i18n regressions tests. Rest are all
 autogenerated.
 >
 > Right, please revert the changes done to the other po files. You can
 prevent updating all those files by passing the specific language you want
 makemessages to update with the `-l` option.

 Updated the code according to your suggestions. Now no changes in existing
 translations would be needed, just additions maybe for largeer number
 strings.

-- 
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] #80: Browsing to http://127.0.0.1:8000 fails when running django-admin.py runserver

2011-09-23 Thread Django

#80: Browsing to http://127.0.0.1:8000 fails when running django-admin.py
runserver
-+-
   Reporter:  pkropf@…   |  Owner:  adrian
   Type:  defect | Status:  closed
  Milestone:  1.4|  Component:  Python 3
Version:  1.3-beta   |   Severity:  Release blocker
 Resolution: |   Keywords:
  worksforme |  http://127.0.0.1:8000
   Triage Stage: |  Has patch:  1
  Someday/Maybe  |Needs tests:  1
Needs documentation:  1  |  Easy pickings:  1
Patch needs improvement:  1  |
  UI/UX:  1  |
-+-
Changes (by anonymous):

 * severity:  critical => Release blocker
 * needs_better_patch:  0 => 1
 * component:  contrib.admin => Python 3
 * needs_tests:  0 => 1
 * version:   => 1.3-beta
 * easy:   => 1
 * milestone:   => 1.4
 * keywords:   => http://127.0.0.1:8000
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * ui_ux:   => 1
 * stage:  Unreviewed => Someday/Maybe


-- 
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] #10899: easier manipulation of sessions by test client

2011-09-23 Thread Django

#10899: easier manipulation of sessions by test client
---+---
   Reporter:  tallfred |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Testing framework
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by bmihelac):

 * cc: bmihelac@… (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] #8060: Admin Inlines do not respect user permissions

2011-09-23 Thread Django

#8060: Admin Inlines do not respect user permissions
-+-
   Reporter: |  Owner:  sjaensch
  p.patruno@…| Status:  assigned
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  inlines User
 Resolution: |  authentication
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by carljm):

 Replying to [comment:23 sjaensch]:
 > Agreed. I'm not yet sure if removing a FlatPage-Site relationship is a
 change to the FlatPage or to the Site.

 If the user is already on the edit page for the model on this side, they
 obviously have change permissions for it. So we're really requiring them
 to have change permission for both sides of the relationship in order to
 muck with the inlines, which I think is correct. (If they're on the add
 page for this side, they might not have change permission - but it's
 reasonable that if you have add permission for a model you can create some
 initial m2m relationships when you add an instance of that model).

 > I'll post a patch later that checks the change permission of the related
 model, let's see how it feels. :)

 Sounds good, 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] #8060: Admin Inlines do not respect user permissions

2011-09-23 Thread Django

#8060: Admin Inlines do not respect user permissions
-+-
   Reporter: |  Owner:  sjaensch
  p.patruno@…| Status:  assigned
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  inlines User
 Resolution: |  authentication
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by sjaensch):

 Replying to [comment:22 carljm]:
 > I'm pretty sure treating the through model as if it were the destination
 model is not the right semantic. Consider the M2M relationship between,
 say, `FlatPage` and `Site` (if it used inlines, which it doesn't by
 default). If someone is forbidden from deleting `Site` objects, there's no
 reason that should imply they can't remove a given `FlatPage` from a
 particular site. Removing a `FlatPage` relationship is, if anything, a
 change to a `Site` - it certainly isn't equivalent to deleting a `Site`.

 Agreed. I'm not yet sure if removing a FlatPage-Site relationship is a
 change to the FlatPage or to the Site. I guess this can be argued either
 way, since the relationship is M2M - there is no direction like in the
 ForeignKey case. It might also depend on the particular use case. I'll
 post a patch later that checks the change permission of the related model,
 let's see how it feels. :)

-- 
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] #16918: BaseDateDetailView's get_object ignores queryset argument (was: BaseDateDetailView's get_object ignore queryset argument)

2011-09-23 Thread Django

#16918: BaseDateDetailView's get_object ignores queryset argument
--+---
   Reporter:  mitar   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Generic views
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+---
Changes (by mitar):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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] #16918: BaseDateDetailView's get_object ignore queryset argument

2011-09-23 Thread Django

#16918: BaseDateDetailView's get_object ignore queryset argument
---+---
 Reporter:  mitar  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Generic views
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+---
 !BaseDateDetailView's `get_object` ignore `queryset` argument, while in
 documentation it is written that:
  If `queryset` is provided, that `queryset` will be used as the source of
 objects; otherwise, `get_queryset()` will be 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] #10933: Avoid " TypeError: Cannot convert Decimal("0.0000") to Decimal " when the decimal module has been reloaded

2011-09-23 Thread Django

#10933: Avoid " TypeError: Cannot convert Decimal("0.") to Decimal  " when 
the
decimal module has been reloaded
-+-
   Reporter:  gagravarr  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  dceu2011
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by adrian.boczkowski@…):

 Check something like this before return statement:
 {{{
 if type(self.bid_price) != type(self.amt_paid):
raise Exception
 }}}

 I guess you will see an error. It raises an exception, because decimal
 module gets reloaded (as I read comments before), and the first
 decimal.Decimal and the second decimal.Decimal aren't the same. If you
 wan't to workaround it now, cast Decimals to str, and then to Decimal
 (decimal.Decimal(str(self.bid.price))) - I used it, but you'll probably
 have to change many lines of your code...

 Has anyone seen this error on other platforms (not apache+mod_wsgi based
 servers)? It seems it's rather mod_wsgi bug.

 Replying to [comment:13 ejohnstone@…]:
 > I saw a similar problem today, and it was isolated to Internet Explorer
 7 and 8.
 > This error did not show up on Firefox 6.01, nor Opera 11.51
 >
 > In my case, I had mistakenly written
 > {{{
 > return Decimal(self.bid_price - self.amt_paid)
 > }}}
 >
 > And self.bid_price and self.amt_paid were already of type 'Decimal'.
 > IE raised the error on this, yet Firefox and Opera didn't.
 > This seems strange to me.
 > I am using django 1.3.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.

45 matches

Mail list logo