Re: [Django] #16131: When deleting a model instance, deletion signals for its relations are fired after deleting the instance

[Django]

#16131: When deleting a model instance, deletion signals for its relations are
fired after deleting the instance
+
   Reporter:  brodie|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  delete signals
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+
Changes (by aaugustin):

 * component:  Database layer (models, ORM) => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 Like you, I think it make sense to fire `post_delete` after the object is
 actually deleted from the database. In your last example, you'd have to
 store the user's details in `pre_delete` and actually send the email in
 `post_delete`. Sure, that's a bit cumbersome.

 However, introducing an undocumented backwards incompatibility is a
 problem: +1 for a mention in the release 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] #15250: Cannot fill parent model instance in cache

[Django]

#15250: Cannot fill parent model instance in cache
-+-
   Reporter:  vzima  |  Owner:  marekw2143
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * easy:   => 0


Comment:

 See #16043 for a similar bug that has a test case.

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

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

Re: [Django] #16043: Specialization cache should be filled/shared with parent object cache (multitable inheritance)

[Django]

#16043: Specialization cache should be filled/shared with parent object cache
(multitable inheritance)
-+-
   Reporter:  zimnyx |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 This looks a lot like #15250, but it's not exactly the same bug. At least,
 the patch currently available on #15250 does not fix this issue.

 I'm attaching a test case in the form of a patch.

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

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

Re: [Django] #16121: Duplicating loggin or Change formatter every time

[Django]

#16121: Duplicating loggin or Change formatter every time
--+---
   Reporter:  niwi@…  |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Uncategorized
Version:  1.3 |   Severity:  Normal
 Resolution:  needsinfo   |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---

Comment (by anonymous):

 Ok. I understand that it is difficult to reproduce this bug. Keep working
 on this, to know where it came from.

 In a few days will update this issue with more specific information if I
 find the problem.

 Thank you very much.

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

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

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

[Django]

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

Comment (by julien):

 Thank you for your patch. I've made a number of modifications to it:

 * Renamed the hook to `save_related()`.
 * Took the call to `save_model()` out of that hook so that it focuses
 solely on form/formset saving business.
 * Removed the test that was in `regressiontests.modeladmin` as it was
 testing internal implementation details, which is best to avoid doing. The
 other test verifies the external behaviour, which is enough here.
 * Tweaked the doc and added release notes.

 Please take a look and see whether this addresses your original request.
 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] #16131: When deleting a model instance, deletion signals for its relations are fired after deleting the instance

[Django]

#16131: When deleting a model instance, deletion signals for its relations are
fired after deleting the instance
-+-
   Reporter:  brodie |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  delete signals
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by brodie):

 Thinking about this some more, maybe the new behavior is correct. You
 could argue that firing post_delete after an instance and all of its
 relations are deleted from the database is the more correct thing to do,
 and that if one needs to access a relation during deletion, pre_delete
 would be a better choice. Maybe this just deserves a mention in the
 release notes.

 For a real world example, django-piston's oauth Consumer model has an FK
 on django.contrib.auth.models.User. When a consumer is deleted, a
 post_delete signal for it is fired. The signal sends an email to the user
 telling them that consumer has been canceled/removed. This works fine most
 of the time, except when the consumer is being deleted because the user is
 being deleted. Should it be able to send that email? Should it instead use
 pre_delete? What if the deletion fails after pre_delete's fired? It can't
 roll back sending the email.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16131: When deleting a model instance, deletion signals for its relations are fired after deleting the instance

[Django]

#16131: When deleting a model instance, deletion signals for its relations are
fired after deleting the instance
-+-
   Reporter:  brodie |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  delete signals
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by brodie):

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


Comment:

 Whoops, I messed up the attachment. It should really have .patch or .diff
 as the file extension.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16131: When deleting a model instance, deletion signals for its relations are fired after deleting the instance

[Django]

#16131: When deleting a model instance, deletion signals for its relations are
fired after deleting the instance
+--
 Reporter:  brodie  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Database layer (models, ORM)
  Version:  1.3 |   Severity:  Normal
 Keywords:  delete signals  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
+--
 In Django 1.2, you could be sure that if you had a post_delete signal on a
 model with a ForeignKey relation, you would be able to access that
 relation in the signal handler. Even if code called .delete() on the
 related object, the signal would be fired before the related object was
 deleted from the database.

 As of Django 1.3, if you call .delete() on that related object, the signal
 handler gets fired *after* the related object is deleted from the
 database. In other words, it deletes the object and its relations in the
 wrong order.

 This regression was introduced by [14507]. It's still present on the
 releases/1.3.X branch as of [16296], and it's still present on trunk as of
 [16299].

 I'm attaching a patch that adds regression tests for this behavior. The
 first test registers a post_delete signal handler for child object,
 deletes the related/parent object, and queries the database in the signal
 handler for the related object. The second test does the same, but its
 signal handler simply accesses the related object.

 When applied to releases/1.2.X, both tests pass. When applied to
 releases/1.3.X, both tests fail. The first test fails to find it in the
 DB, and the second test encounters a DoesNotExist exception.

 Also, this is somewhat unrelated, but when writing the tests I noticed
 that the objects received by the signal handler did not equal (with ==)
 the objects I instantiated in the test. The PKs were all the same, but
 ._get_pk_val() returned None for the objects passed to the signal handler.
 That might be worth another bug report.

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

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

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

[Django]

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

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


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

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

Re: [Django] #16026: Inform user which object triggered error in loaddata

[Django]

#16026: Inform user which object triggered error in loaddata
-+-
   Reporter: |  Owner:  gabrielhurley
  gabrielhurley  | Status:  new
   Type:  New|  Component:  Core (Management
  feature|  commands)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

 * needs_tests:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 There doesn't seem to be a reason to skip tests - see
 modeltests/fixtures/tests.py - so I'm changing the flags accordingly.

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

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

Re: [Django] #15619: Logout link should be protected

[Django]

#15619: Logout link should be protected
+---
   Reporter:  void  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:  1.4   |  Component:  contrib.admin
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 lukeplant):

 In the admin we can also have some jQuery (or other javascript) code that
 will change the logout link so that it does a POST to the logout view by
 submitting a (dynamically generated) POST form. That would be better than
 a pass through page because it requires just one HTTP request.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16129: FormView's "success_url" attr should accept named URLs

[Django]

#16129: FormView's "success_url" attr should accept named URLs
-+-
   Reporter: |  Owner:  nobody
  renatopedigoni | Status:  closed
   Type: |  Component:  Generic views
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution:  wontfix|Needs tests:  1
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  1  |
Patch needs improvement:  1  |
-+-
Changes (by lukeplant):

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


Comment:

 Closing WONTFIX for the reasons aaugustin gave.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16130: Add some information about admin media in staticfiles documentation (was: Add)

[Django]

#16130: Add some information about admin media in staticfiles documentation
-+-
   Reporter:  aroy   |  Owner:  d0ugal
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  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.

[Changeset] r16299 - django/trunk/docs/ref

[noreply]

Author: lukeplant
Date: 2011-05-30 15:50:11 -0700 (Mon, 30 May 2011)
New Revision: 16299

Modified:
   django/trunk/docs/ref/clickjacking.txt
Log:
Fixed some typos/grammar in clickjacking docs

Modified: django/trunk/docs/ref/clickjacking.txt
===
--- django/trunk/docs/ref/clickjacking.txt  2011-05-30 22:27:47 UTC (rev 
16298)
+++ django/trunk/docs/ref/clickjacking.txt  2011-05-30 22:50:11 UTC (rev 
16299)
@@ -24,7 +24,7 @@
 of their own pages, and load the store's page in a transparent iframe such that
 the "Buy Now" button is invisibly overlaid on the "I Like Ponies" button. If 
the
 user visits the attacker site and clicks "I Like Ponies" he will inadvertently
-click on the online store's "Buy Now" button and unknowningly purchase the 
item.
+click on the online store's "Buy Now" button and unknowingly purchase the item.
 
 Preventing clickjacking
 ===
@@ -70,7 +70,7 @@
 
 When using the middleware there may be some views where you do **not** want the
 X-Frame-Options header set. For those cases, you can use a view decorator that
-tells the middleware to not set the header::
+tells the middleware not to set the header::
 
 from django.http import HttpResponse
 from django.views.decorators.clickjacking import xframe_options_exempt

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16130: Add

[Django]

#16130: Add
-+-
   Reporter:  aroy   |  Owner:  d0ugal
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by d0ugal):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => d0ugal
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Seems like a reasonable idea. It may be better placed under the admin
 documentation however, with links to 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.

[Changeset] r16298 - in django/trunk: . django/conf django/conf/project_template django/middleware django/views/decorators docs docs/ref docs/releases tests/regressiontests/decorators tests/regressio

[noreply]

Author: lukeplant
Date: 2011-05-30 15:27:47 -0700 (Mon, 30 May 2011)
New Revision: 16298

Added:
   django/trunk/django/middleware/clickjacking.py
   django/trunk/django/views/decorators/clickjacking.py
   django/trunk/docs/ref/clickjacking.txt
Modified:
   django/trunk/AUTHORS
   django/trunk/django/conf/global_settings.py
   django/trunk/django/conf/project_template/settings.py
   django/trunk/docs/index.txt
   django/trunk/docs/ref/index.txt
   django/trunk/docs/ref/middleware.txt
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/regressiontests/decorators/tests.py
   django/trunk/tests/regressiontests/middleware/tests.py
Log:
Fixed #14261 - Added clickjacking protection (X-Frame-Options header)

Many thanks to rniemeyer for the patch!

Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2011-05-30 16:33:23 UTC (rev 16297)
+++ django/trunk/AUTHORS2011-05-30 22:27:47 UTC (rev 16298)
@@ -534,6 +534,7 @@
 Jarek Zgoda 
 Cheng Zhang
 Zlatko Mašek 
+Ryan Niemeyer 
 
 A big THANK YOU goes to:
 

Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2011-05-30 16:33:23 UTC (rev 
16297)
+++ django/trunk/django/conf/global_settings.py 2011-05-30 22:27:47 UTC (rev 
16298)
@@ -406,6 +406,9 @@
 DEFAULT_TABLESPACE = ''
 DEFAULT_INDEX_TABLESPACE = ''
 
+# Default X-Frame-Options header value
+X_FRAME_OPTIONS = 'SAMEORIGIN'
+
 ##
 # MIDDLEWARE #
 ##

Modified: django/trunk/django/conf/project_template/settings.py
===
--- django/trunk/django/conf/project_template/settings.py   2011-05-30 
16:33:23 UTC (rev 16297)
+++ django/trunk/django/conf/project_template/settings.py   2011-05-30 
22:27:47 UTC (rev 16298)
@@ -98,6 +98,8 @@
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
+# Uncomment the next line for simple clickjacking protection:
+# 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 )
 
 ROOT_URLCONF = '{{ project_name }}.urls'

Added: django/trunk/django/middleware/clickjacking.py
===
--- django/trunk/django/middleware/clickjacking.py  
(rev 0)
+++ django/trunk/django/middleware/clickjacking.py  2011-05-30 22:27:47 UTC 
(rev 16298)
@@ -0,0 +1,51 @@
+"""
+Clickjacking Protection Middleware.
+
+This module provides a middleware that implements protection against a
+malicious site loading resources from your site in a hidden frame.
+"""
+
+from django.conf import settings
+
+class XFrameOptionsMiddleware(object):
+"""
+Middleware that sets the X-Frame-Options HTTP header in HTTP responses.
+
+Does not set the header if it's already set or if the response contains
+a xframe_options_exempt value set to True.
+
+By default, sets the X-Frame-Options header to 'SAMEORIGIN', meaning the
+response can only be loaded on a frame within the same site. To prevent the
+response from being loaded in a frame in any site, set X_FRAME_OPTIONS in
+your project's Django settings to 'DENY'.
+
+Note: older browsers will quietly ignore this header, thus other
+clickjacking protection techniques should be used if protection in those
+browsers is required.
+
+http://en.wikipedia.org/wiki/Clickjacking#Server_and_client
+"""
+def process_response(self, request, response):
+# Don't set it if it's already in the response
+if response.get('X-Frame-Options', None) is not None:
+return response
+
+# Don't set it if they used @xframe_options_exempt
+if getattr(response, 'xframe_options_exempt', False):
+return response
+
+response['X-Frame-Options'] = self.get_xframe_options_value(request,
+response)
+return response
+
+def get_xframe_options_value(self, request, response):
+"""
+Gets the value to set for the X_FRAME_OPTIONS header.
+
+By default this uses the value from the X_FRAME_OPTIONS Django
+settings. If not found in settings, defaults to 'SAMEORIGIN'.
+
+This method can be overridden if needed, allowing it to vary based on
+the request or response.
+"""
+return getattr(settings, 'X_FRAME_OPTIONS', 'SAMEORIGIN').upper()

Added: django/trunk/django/views/decorators/clickjacking.py
===
--- django/trunk/django/views/decorators/clickjacking.py
(rev 0)
+

Re: [Django] #14261: Add clickjacking protection (X-Frame-Options header)

[Django]

#14261: Add clickjacking protection (X-Frame-Options header)
-+-
   Reporter:  rniemeyer  |  Owner:  rniemeyer
   Type:  New| Status:  closed
  feature|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:  clickjacking
 Resolution:  fixed  |  x_frame_options
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by lukeplant):

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


Comment:

 In [16298]:
 {{{
 #!CommitTicketReference repository="" revision="16298"
 Fixed #14261 - Added clickjacking protection (X-Frame-Options header)

 Many thanks to rniemeyer for the 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] #14261: Add clickjacking protection (X-Frame-Options header)

[Django]

#14261: Add clickjacking protection (X-Frame-Options header)
-+-
   Reporter:  rniemeyer  |  Owner:  rniemeyer
   Type:  New| Status:  assigned
  feature|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:  clickjacking
 Resolution: |  x_frame_options
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by lukeplant):

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


Comment:

 Thanks for the great patch, I will commit it shortly.

 I did have to change a fair number of things - it was easier for me to do
 so because I'm familiar with all our standards etc. Since I'd like to
 encourage you to continue contributing to Django, but want to make it
 easier to add your contributions, I've included below the list of things I
 changed, mainly to highlight things you probably wouldn't have been aware
 of:

 * Docs:
   * wrapped to 80 characters, as per our
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-
 documentation/ guidelines for writing docs]
   * added some blanklines after headers. This makes it easier to re-wrap
 in editors, and is consistent with the rest of our docs.
   * corrected some indentation, so that lists appeared correctly
 formatted.
   * moved the main docs file out of the contrib directory - that's for
 contrib apps. (The CSRF docs are currently in the wrong place, because
 that **used** to be a contrib app, but now is core, and I don't think
 we've got a good way of doing re-direction yet).
   * added a 'versionadded' Sphinx directive
   * fixed some Python syntax errors (noticed from the lack of code
 highlighting in the built docs.)
   * used standard capitalization of X-Frame-Options throughout.
   * other misc spelling corrections to docs.
   * added section to ref/middleware.txt
   * added section to ref/settings.txt
 * Code:
   * added setting to django/conf/global_settings.py
   * removed trailing whitespace in various files. (You can often configure
 your editor to show this, and most colorized diff tools, like
 [http://colordiff.sourceforge.net/ colordiff], will highlight this - they
 can often be used in conjuction with 'svn diff' etc.).
   * used standard capitalization of X-Frame-Options in response header.
   * changed tearDown in tests so that it restores the original value of
 the setting (which will now always be there, since we added it to
 gloab_settings.py), rather than remove any setting.
   * removed a Python 2.4 fallback that's no longer necessary.

 And also:
 * as discussed, I added the middleware to the project template, commented
 out.
 * added this to the release notes, as a worthy feature addition.
 * added you to AUTHORS. I put your Google profile as the link - please say
 if you'd prefer your e-mail address or a different website.

 Finally, as a matter of process, you should update the 'Patch needs
 improvement/Needs docs/Needs tests' flags when you think you've addressed
 any issues - otherwise the committers will generally wait for the original
 author to fix the patch up unless they are particularly motivated about
 the feature/bug.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16130: Add

[Django]

#16130: Add
---+---
 Reporter:  aroy   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
---+---
 I think it would help to add a section to
 https://docs.djangoproject.com/en/1.3/howto/static-files/ about how
 django.contrib.staticfiles affects admin media.  When you search the page
 for the word "admin", it's not in there.

 Even if the section just says to set ADMIN_MEDIA_PREFIX (with a link to
 https://docs.djangoproject.com/en/1.3/ref/settings/#admin-media-prefix)
 that would help.

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

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

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

[Django]

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

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


Comment:

 Note that #15271 is also about `GeometryField.clean()`.

 Something should be done about the first comment in the patch: `# Never
 checked: stop passing this?` => needs improvement.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
   Reporter:  xkennyx@…  |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  cascade delete
Needs documentation:  0  |  proxy meta
Patch needs improvement:  0  |  Has patch:  0
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 OK, here's a test case that exhibits the problem. Indeed, I think it's a
 bug.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16112: Excluding some value in a related model excludes objects without that model

[Django]

#16112: Excluding some value in a related model excludes objects without that 
model
-+-
   Reporter:  adehnert   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Design |   Keywords:
  decision needed|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by aaugustin):

 Addendum: this might be a duplicate of #14876 — I'm not sure.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16112: Excluding some value in a related model excludes objects without that model

[Django]

#16112: Excluding some value in a related model excludes objects without that 
model
-+-
   Reporter:  adehnert   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Design |   Keywords:
  decision needed|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Design decision needed


Comment:

 The docs basically say that the ORM won't crash'n'burn when you're
 filtering on `foo__bar=42` just because one of your objects doesn't have a
 related `Foo` object. See the paragraph that follows your quote. It
 doesn't really say anything about "negative queries".

 That said, I agree with your analysis. Assuming a given object doesn't
 have an associated `Foo` object, the value of its `foo__bar` is something
 akin to `NaN`. Since `NaN != ` evaluates to `True`, this analogy
 supports your interpretation.

 Fixing this problem would be backwards incompatible: it would change the
 result of "negative queries". IMO, we can't say it's an obvious bug,
 rather an under-defined behavior. So I'll mark it as DDN.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16121: Duplicating loggin or Change formatter every time

[Django]

#16121: Duplicating loggin or Change formatter every time
--+---
   Reporter:  niwi@…  |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Uncategorized
Version:  1.3 |   Severity:  Normal
 Resolution:  needsinfo   |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---
Changes (by aaugustin):

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


Comment:

 I fail to see how this is related to Django:

 - `logging` is a module from the standard library, provided by Python.
 - `gevent` has no relation with Django.

 So I'm pretty sure you could reproduce the same problem without Django
 (with a dummy wsgi app, logging.config.dictConfig, etc.).

 Anyway, it's hard to diagnose your problem with the information you've
 provided. If you think there's a bug in Django, could you provide a
 simpler test case (something we can easily reproduce), and tell us which
 part of Django is misbehaving?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
   Reporter:  xkennyx@…  |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  cascade delete
  Unreviewed |  proxy meta
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by xkennyx@…):

 {{{
 (this was not posted)
 Try this attached test.
 and these steps:

 1) go to admin page
 2) create new user "test"
 3) create new profile for user "test"
 4) try delete user "test"
 and there starts problem, only user is deleted and not profile.
 (It can be deleted in sqlite3 but in postgresql it fail because of
 constrain)

 when you change in model the foreign key to User
 then delete ask to delete also profile
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16129: FormView's "success_url" attr should accept named URLs

[Django]

#16129: FormView's "success_url" attr should accept named URLs
-+-
   Reporter: |  Owner:  nobody
  renatopedigoni | Status:  new
   Type: |  Component:  Generic views
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  1
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  1  |
Patch needs improvement:  1  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 1
 * needs_docs:   => 1
 * needs_tests:   => 1
 * stage:  Unreviewed => Design decision needed


Comment:

 I'm -1 on this patch for the following reasons:

 - that would only work for named urls that don't have any captures, since
 you can't pass `*args` or `**kwargs` to `redirect`;
 - that would allow passing a model instance as `success_url`, and I don't
 think that makes sense here;
 - `redirect` is not very well defined, it does more magic than necessary
 here, see the source:  `# If this doesn't "feel" like a URL, re-
 raise.` . Ugh.

 I think `django.shortcuts` in general, and `redirect` in particular, are
 little hacks to ease developers' lives, and not something that should be
 used in Django itself. Currently, `django.shortcuts` is only used in
 contrib apps, never in the core; and the only functions used are
 `get_object_or_404` and `render_to_response`. Both of these are more
 straightforward than `redirect`; they don't do any magic.

 I think `success_url = urlresolvers.reverse(my_url_name)` is explicit and
 works in your situation.

 However, since I'm not 100% sure that we don't want this feature, I'll
 mark the ticket as DDN and let a core developer make the decision. If it's
 accepted, the patch still needs tests and documentations.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
   Reporter:  xkennyx@…  |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  cascade delete
  Unreviewed |  proxy meta
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by xkennyx@…):

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


Comment:

 please try this example code,
 But when I look at your testcase I probably know the problem.

 You are creating and deleting AuthUserProxy. It probably works , but when
 I delete the base of AuthUserProxy the (AuthUser) then it fail.
 And because AuthUser and AuthUserProxy are the same for database, then it
 lead to integrity problems.

 I'm not now sure if it is bug of feature ;-) I will leave it to you. But
 it is annoying

 And thanks for fast response :)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #12856: Decide on public API/documentation for form.BoundField attributes

[Django]

#12856: Decide on public API/documentation for form.BoundField attributes
-+-
   Reporter:  mnbayazit  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  boundfield required
 Resolution: |  is_hidden auto_id
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * easy:   => 0


Comment:

 #16125 was a duplicate. The tickets suggests some fields that should be
 documented in priority.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16125: document BoundField's id_for_label attribute

[Django]

#16125: document BoundField's id_for_label attribute
-+-
   Reporter:  Keryn  |  Owner:  nobody
  Knight| Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  boundfield forms
Version:  1.3|  Has patch:  0
 Resolution:  duplicate  |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  1
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * status:  new => closed
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => duplicate
 * stage:  Unreviewed => Design decision needed


Comment:

 This is a duplicate of #12856.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16126: please add information on rendering DELETE checkbox manually for formset

[Django]

#16126: please add information on rendering DELETE checkbox manually for formset
-+-
   Reporter:  tim@…  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:   => 0
 * 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] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
   Reporter:  xkennyx@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
  worksforme |   Keywords:  cascade delete
   Triage Stage: |  proxy meta
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 In case it would be specific to django.contrib.auth.models.User, I wrote a
 second test case. It passes too.

 xkennyx, could you provide a complete test case that exhibits the bug?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16129: FormView's "success_url" attr should accept named URLs

[Django]

#16129: FormView's "success_url" attr should accept named URLs
--+---
 Reporter:  renatopedigoni|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Generic views
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
--+---
 IMHO success_url should also accept named urls. I wrote a very simple
 patch that uses 'redirect' (from django.shortcuts) instead of
 HttpResponseRedirect.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
   Reporter:  xkennyx@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  cascade delete
  Unreviewed |  proxy meta
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 I have written a test case for the issue describe above, and that test
 passes. In other words, I'm unable to reproduce the problem at this point.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16068: Ease access to request headers

[Django]

#16068: Ease access to request headers
---+---
   Reporter:  jgorset  |  Owner:  jgorset
   Type:  New feature  | Status:  assigned
  Milestone:   |  Component:  HTTP handling
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:  headers
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---
Changes (by lukeplant):

 * stage:  Design decision needed => Accepted


Comment:

 On first look, this seems like an obvious and good enhancement. People
 using Django should be insulated from the rather strange way that CGI/WSGI
 mutilate header names.

 There are a few issues, however, for a patch to be accepted.

 1. Firstly - we really want 'one way to do it', for the sake of
 consistency, and especially to make it easy to grep source code for
 headers. But we already have a documented way of doing this - using META.
 Lots of code and tests already assume this, and
 `django.test.client.Client` and `RequestFactory` accept keywords
 parameters for updating the base environment using WSGI conventions - so
 you pass things like 'HTTP_REFERER'. It would suck if we had to remember
 that test code used WSGI names to set headers, but view code used HTTP
 names. Given that HTTP names are often not valid keyword argument names,
 we may need an additional 'headers' keyword argument to `RequestFactory`.

 2. We also need to think about how exactly we do the conversion, and
 issues of case sensitivity - HTTP headers are case insensitive.

 3. We need to think about at what point we do the conversion, and any
 overhead associated with that. Currently we have no overhead associated
 with headers, since we just use the environment dictionary passed from
 mod_wsgi (I think).`

 I think these issues together mean that `__getitem__` and `__setitem__`
 will strictly be wrappers around request.META. But note that Content-Type
 and Content-Length are handled differently, and don't get the `'HTTP_'`
 prefix.

 So, I'm going to accept. But this is actually quite a lot of work - we
 want a patch that will leave our code base with a single way to examine
 headers in requests, and set request headers in test code, with
 compatibility with the old way. (We might make exceptions for the
 implementation of `RequestFactory`, but for our own '''use''' of
 `RequestFactory` and other people's use of it, there should be One Way to
 spell HTTP headers).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Database layer
  Version:  1.3  |  (models, ORM)
 Keywords:  cascade delete proxy |   Severity:  Normal
  meta   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+-
 Hi all :), there is problem with cascade delete, when proxy model is used.
 example:

 {{{
 class ExUser(User):
 class Meta:
 proxy = True

 # work:
 class Profile(models.Model):
 user = models.ForeignKey(User)

 # does not work:
 class Profile(models.Model):
 user = models.ForeignKey(ExUser)

 }}}
 when I delete user, then in first scenario is profile also deleted, but
 when I want use proxy as foreign key, then profile is not deleted, and it
 lead to integrity problem in DB

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16068: Ease access to request headers

[Django]

#16068: Ease access to request headers
-+-
   Reporter:  jgorset|  Owner:  jgorset
   Type:  New| Status:  assigned
  feature|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  headers
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jgorset):

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


Comment:

 This ought to be an easy design decision to make. It's pretty crude to
 parse environment variables for the request headers, and I'd be happy to
 alleviate 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.

[Changeset] r16297 - in django/trunk: django/contrib/auth tests/regressiontests/test_client_regress

[noreply]

Author: lukeplant
Date: 2011-05-30 09:33:23 -0700 (Mon, 30 May 2011)
New Revision: 16297

Modified:
   django/trunk/django/contrib/auth/middleware.py
   django/trunk/tests/regressiontests/test_client_regress/models.py
Log:
Fixed #15929 - test.client.RequestFactory keeps state/AuthMiddleware does 
monkey patching

Thanks to m.vantellingen for the report and tests, and to aaugustin for
work on the tests.

Modified: django/trunk/django/contrib/auth/middleware.py
===
--- django/trunk/django/contrib/auth/middleware.py  2011-05-30 16:19:53 UTC 
(rev 16296)
+++ django/trunk/django/contrib/auth/middleware.py  2011-05-30 16:33:23 UTC 
(rev 16297)
@@ -13,7 +13,13 @@
 class AuthenticationMiddleware(object):
 def process_request(self, request):
 assert hasattr(request, 'session'), "The Django authentication 
middleware requires session middleware to be installed. Edit your 
MIDDLEWARE_CLASSES setting to insert 
'django.contrib.sessions.middleware.SessionMiddleware'."
-request.__class__.user = LazyUser()
+
+# We dynamically subclass request.__class__ rather than monkey patch 
the
+# original class.
+class RequestWithUser(request.__class__):
+user = LazyUser()
+
+request.__class__ = RequestWithUser
 return None
 
 

Modified: django/trunk/tests/regressiontests/test_client_regress/models.py
===
--- django/trunk/tests/regressiontests/test_client_regress/models.py
2011-05-30 16:19:53 UTC (rev 16296)
+++ django/trunk/tests/regressiontests/test_client_regress/models.py
2011-05-30 16:33:23 UTC (rev 16297)
@@ -12,7 +12,7 @@
 Context, Template, loader)
 import django.template.context
 from django.test import Client, TestCase
-from django.test.client import encode_file
+from django.test.client import encode_file, RequestFactory
 from django.test.utils import ContextList
 
 
@@ -908,3 +908,32 @@
 response = self.client.get("/test_client_regress/raw_post_data/")
 except AssertionError:
 self.fail("Accessing request.raw_post_data from a view fetched 
with GET by the test client shouldn't fail.")
+
+
+class RequestFactoryStateTest(TestCase):
+"""Regression tests for #15929."""
+# These tests are checking that certain middleware don't change certain
+# global state. Alternatively, from the point of view of a test, they are
+# ensuring test isolation behaviour. So, unusually, it doesn't make sense 
to
+# run the tests individually, and if any are failing it is confusing to run
+# them with any other set of tests.
+
+def setUp(self):
+self.factory = RequestFactory()
+
+def common_test_that_should_always_pass(self):
+request = self.factory.get('/')
+request.session = {}
+self.assertFalse(hasattr(request, 'user'))
+
+def test_request(self):
+self.common_test_that_should_always_pass()
+
+def test_request_after_client(self):
+# apart from the next line the three tests are identical
+self.client.get('/')
+self.common_test_that_should_always_pass()
+
+def test_request_after_client_2(self):
+# This test is executed after the previous one
+self.common_test_that_should_always_pass()

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15929: test.client.RequestFactory keeps state

[Django]

#15929: test.client.RequestFactory keeps state
-+-
   Reporter: |  Owner:  nobody
  m.vantellingen@…   | Status:  closed
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 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:  new => closed
 * resolution:   => fixed


Comment:

 In [16297]:
 {{{
 #!CommitTicketReference repository="" revision="16297"
 Fixed #15929 - test.client.RequestFactory keeps state/AuthMiddleware does
 monkey patching

 Thanks to m.vantellingen for the report and tests, and to aaugustin for
 work on the tests.
 }}}

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

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

Re: [Django] #16127: Queryset which uses defer() method not serialize in Json

[Django]

#16127: Queryset which uses defer() method not serialize in Json
-+-
   Reporter: |  Owner:  nobody
  eguevara2012@… | Status:  new
   Type:  Bug|  Component:  Core
  Milestone: |  (Serialization)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by ramiro):

 * needs_better_patch:   => 0
 * component:  Database layer (models, ORM) => Core (Serialization)
 * needs_tests:   => 0
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Old description:

> Hello!
> I have this function using json and a queryset with defer() method, but
> the fields not target in queryset, i need only "id" and "nome":
>
> models.py
>
> class Pessoa(models.Model):
> nome = models.CharField(max_length=50)
> data_nascimento = models.DateField()
> data_inclusao = models.DateField()
> cpf = models.CharField(max_length=14)
> telefone = models.CharField(max_length=13)
> celular = models.CharField(max_length=13)
>
> class Meta:
> abstract = True
>
> class Proprietario(Pessoa):
> endereco = models.ForeignKey(Endereco)
>
> def __unicode__(self):
> return "%s, %s" % (self.nome, self.cpf)
>
> views.py:
>
> def load_proprietarios(request):
> data =
> serializers.serialize('json',Proprietario.objects.defer('cpf','telefone','celular','data_nascimento','data_inclusao',),ensure_ascii=False))
> return HttpResponse(data, mimetype="application/javascript")
>
> This is the output:
>
> [{"pk": 1, "model":
> "proprietario.proprietario_deferred_celular_cpf_telefone_data_inclusao_data_nascimento",
> "fields": {}}]
>
> Note that the "id" and the "nome" fields (class Proprietario / class
> abstract Pessoa) does not appear after defer() method.
>
> Regards.

New description:

 Hello!
 I have this function using json and a queryset with defer() method, but
 the fields not target in queryset, i need only "id" and "nome":

 models.py
 {{{
 class Pessoa(models.Model):
 nome = models.CharField(max_length=50)
 data_nascimento = models.DateField()
 data_inclusao = models.DateField()
 cpf = models.CharField(max_length=14)
 telefone = models.CharField(max_length=13)
 celular = models.CharField(max_length=13)

 class Meta:
 abstract = True

 class Proprietario(Pessoa):
 endereco = models.ForeignKey(Endereco)

 def __unicode__(self):
 return "%s, %s" % (self.nome, self.cpf)
 }}}

 views.py:
 {{{
 def load_proprietarios(request):
 data =
 
serializers.serialize('json',Proprietario.objects.defer('cpf','telefone','celular','data_nascimento','data_inclusao',),ensure_ascii=False))
 return HttpResponse(data, mimetype="application/javascript")
 }}}

 This is the output:
 {{{
 [{"pk": 1, "model":
 
"proprietario.proprietario_deferred_celular_cpf_telefone_data_inclusao_data_nascimento",
 "fields": {}}]
 }}}

 Note that the "id" and the "nome" fields (class Proprietario / class
 abstract Pessoa) does not appear after defer() method.

 Regards.

--

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16296 - in django/branches/releases/1.3.X: django/db/models tests/regressiontests/delete_regress

[noreply]

Author: lukeplant
Date: 2011-05-30 09:19:53 -0700 (Mon, 30 May 2011)
New Revision: 16296

Modified:
   django/branches/releases/1.3.X/django/db/models/deletion.py
   django/branches/releases/1.3.X/tests/regressiontests/delete_regress/models.py
   django/branches/releases/1.3.X/tests/regressiontests/delete_regress/tests.py
Log:
[1.3.X] Fixed #15776 - delete regression in Django 1.3 involving nullable 
foreign keys

Many thanks to aaron.l.madison for the detailed report and to emulbreh for
the fix.

Backport of [16295] from trunk.

Modified: django/branches/releases/1.3.X/django/db/models/deletion.py
===
--- django/branches/releases/1.3.X/django/db/models/deletion.py 2011-05-30 
16:04:25 UTC (rev 16295)
+++ django/branches/releases/1.3.X/django/db/models/deletion.py 2011-05-30 
16:19:53 UTC (rev 16296)
@@ -83,8 +83,8 @@
 def add(self, objs, source=None, nullable=False, reverse_dependency=False):
 """
 Adds 'objs' to the collection of objects to be deleted.  If the call is
-the result of a cascade, 'source' should be the model that caused it
-and 'nullable' should be set to True, if the relation can be null.
+the result of a cascade, 'source' should be the model that caused it,
+and 'nullable' should be set to True if the relation can be null.
 
 Returns a list of all objects that were not already collected.
 """
@@ -100,7 +100,7 @@
 # Nullable relationships can be ignored -- they are nulled out before
 # deleting, and therefore do not affect the order in which objects have
 # to be deleted.
-if new_objs and source is not None and not nullable:
+if source is not None and not nullable:
 if reverse_dependency:
 source, model = model, source
 self.dependencies.setdefault(source, set()).add(model)

Modified: 
django/branches/releases/1.3.X/tests/regressiontests/delete_regress/models.py
===
--- 
django/branches/releases/1.3.X/tests/regressiontests/delete_regress/models.py   
2011-05-30 16:04:25 UTC (rev 16295)
+++ 
django/branches/releases/1.3.X/tests/regressiontests/delete_regress/models.py   
2011-05-30 16:19:53 UTC (rev 16296)
@@ -51,3 +51,19 @@
 class Eaten(models.Model):
 food = models.ForeignKey(Food, to_field="name")
 meal = models.CharField(max_length=20)
+
+
+# Models for #15776
+
+class Policy(models.Model):
+policy_number = models.CharField(max_length=10)
+
+class Version(models.Model):
+policy = models.ForeignKey(Policy)
+
+class Location(models.Model):
+version = models.ForeignKey(Version, blank=True, null=True)
+
+class Item(models.Model):
+version = models.ForeignKey(Version)
+location = models.ForeignKey(Location, blank=True, null=True)

Modified: 
django/branches/releases/1.3.X/tests/regressiontests/delete_regress/tests.py
===
--- 
django/branches/releases/1.3.X/tests/regressiontests/delete_regress/tests.py
2011-05-30 16:04:25 UTC (rev 16295)
+++ 
django/branches/releases/1.3.X/tests/regressiontests/delete_regress/tests.py
2011-05-30 16:19:53 UTC (rev 16296)
@@ -5,7 +5,8 @@
 from django.test import TestCase, TransactionTestCase, skipUnlessDBFeature
 
 from models import (Book, Award, AwardNote, Person, Child, Toy, PlayedWith,
-PlayedWithNote, Contact, Email, Researcher, Food, Eaten)
+PlayedWithNote, Contact, Email, Researcher, Food, Eaten,
+Policy, Version, Location, Item)
 
 
 # Can't run this test under SQLite, because you can't
@@ -102,7 +103,14 @@
 # first two asserts just sanity checks, this is the kicker:
 self.assertEqual(PlayedWithNote.objects.count(), 0)
 
+def test_15776(self):
+policy = Policy.objects.create(pk=1, policy_number="1234")
+version = Version.objects.create(policy=policy)
+location = Location.objects.create(version=version)
+item = Item.objects.create(version=version, location=location)
+policy.delete()
 
+
 class DeleteCascadeTransactionTests(TransactionTestCase):
 def test_inheritance(self):
 """

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

Re: [Django] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |  Owner:  lukeplant
  aaron.l.madison@…  | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3|   Severity:  Release blocker
 Resolution:  fixed  |   Keywords:  db mysql delete
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by lukeplant):

 In [16296]:
 {{{
 #!CommitTicketReference repository="" revision="16296"
 [1.3.X] Fixed #15776 - delete regression in Django 1.3 involving nullable
 foreign keys

 Many thanks to aaron.l.madison for the detailed report and to emulbreh for
 the fix.

 Backport of [16295] 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] r16295 - in django/trunk: django/db/models tests/regressiontests/delete_regress

[noreply]

Author: lukeplant
Date: 2011-05-30 09:04:25 -0700 (Mon, 30 May 2011)
New Revision: 16295

Modified:
   django/trunk/django/db/models/deletion.py
   django/trunk/tests/regressiontests/delete_regress/models.py
   django/trunk/tests/regressiontests/delete_regress/tests.py
Log:
Fixed #15776 - delete regression in Django 1.3 involving nullable foreign keys

Many thanks to aaron.l.madison for the detailed report and to emulbreh for
the fix.

Modified: django/trunk/django/db/models/deletion.py
===
--- django/trunk/django/db/models/deletion.py   2011-05-30 12:11:46 UTC (rev 
16294)
+++ django/trunk/django/db/models/deletion.py   2011-05-30 16:04:25 UTC (rev 
16295)
@@ -82,8 +82,8 @@
 def add(self, objs, source=None, nullable=False, reverse_dependency=False):
 """
 Adds 'objs' to the collection of objects to be deleted.  If the call is
-the result of a cascade, 'source' should be the model that caused it
-and 'nullable' should be set to True, if the relation can be null.
+the result of a cascade, 'source' should be the model that caused it,
+and 'nullable' should be set to True if the relation can be null.
 
 Returns a list of all objects that were not already collected.
 """
@@ -99,7 +99,7 @@
 # Nullable relationships can be ignored -- they are nulled out before
 # deleting, and therefore do not affect the order in which objects have
 # to be deleted.
-if new_objs and source is not None and not nullable:
+if source is not None and not nullable:
 if reverse_dependency:
 source, model = model, source
 self.dependencies.setdefault(source, set()).add(model)

Modified: django/trunk/tests/regressiontests/delete_regress/models.py
===
--- django/trunk/tests/regressiontests/delete_regress/models.py 2011-05-30 
12:11:46 UTC (rev 16294)
+++ django/trunk/tests/regressiontests/delete_regress/models.py 2011-05-30 
16:04:25 UTC (rev 16295)
@@ -51,3 +51,19 @@
 class Eaten(models.Model):
 food = models.ForeignKey(Food, to_field="name")
 meal = models.CharField(max_length=20)
+
+
+# Models for #15776
+
+class Policy(models.Model):
+policy_number = models.CharField(max_length=10)
+
+class Version(models.Model):
+policy = models.ForeignKey(Policy)
+
+class Location(models.Model):
+version = models.ForeignKey(Version, blank=True, null=True)
+
+class Item(models.Model):
+version = models.ForeignKey(Version)
+location = models.ForeignKey(Location, blank=True, null=True)

Modified: django/trunk/tests/regressiontests/delete_regress/tests.py
===
--- django/trunk/tests/regressiontests/delete_regress/tests.py  2011-05-30 
12:11:46 UTC (rev 16294)
+++ django/trunk/tests/regressiontests/delete_regress/tests.py  2011-05-30 
16:04:25 UTC (rev 16295)
@@ -5,7 +5,8 @@
 from django.test import TestCase, TransactionTestCase, skipUnlessDBFeature
 
 from models import (Book, Award, AwardNote, Person, Child, Toy, PlayedWith,
-PlayedWithNote, Contact, Email, Researcher, Food, Eaten)
+PlayedWithNote, Contact, Email, Researcher, Food, Eaten,
+Policy, Version, Location, Item)
 
 
 # Can't run this test under SQLite, because you can't
@@ -102,7 +103,14 @@
 # first two asserts just sanity checks, this is the kicker:
 self.assertEqual(PlayedWithNote.objects.count(), 0)
 
+def test_15776(self):
+policy = Policy.objects.create(pk=1, policy_number="1234")
+version = Version.objects.create(policy=policy)
+location = Location.objects.create(version=version)
+item = Item.objects.create(version=version, location=location)
+policy.delete()
 
+
 class DeleteCascadeTransactionTests(TransactionTestCase):
 def test_inheritance(self):
 """

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

Re: [Django] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |  Owner:  lukeplant
  aaron.l.madison@…  | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3|   Severity:  Release blocker
 Resolution:  fixed  |   Keywords:  db mysql delete
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by lukeplant):

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


Comment:

 In [16295]:
 {{{
 #!CommitTicketReference repository="" revision="16295"
 Fixed #15776 - delete regression in Django 1.3 involving nullable foreign
 keys

 Many thanks to aaron.l.madison for the detailed report and to emulbreh for
 the fix.
 }}}

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

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

Re: [Django] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |  Owner:  lukeplant
  aaron.l.madison@…  | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:  db mysql delete
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by lukeplant):

 OK, I'm about to commit the fix. Some notes, for your information:

 The models `ItemRateCode`, `PropertyItem` and `Coverage` are irrelevant
 and can be removed from the example (so I did in the tests). Same for
 needing multiple 'Item' objects.

 To expand on emulbreh's explanation of his patch:

 The bug occurs because the 'Item' object is first reached via the
 'Location' object, and since the relation is nullable, the dependency is
 not added. The second time it is reached, directly from the 'Version'
 object, it is not 'new', therefore the dependency is not counted. This
 last bit of logic needs to be removed - an object may have already been
 seen, but that doesn't mean the route to the object has already been seen,
 and we need to include the dependency nonetheless.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16127: Queryset which uses defer() method not serialize in Json

[Django]

#16127: Queryset which uses defer() method not serialize in Json
+--
 Reporter:  eguevara2012@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Database layer (models, ORM)
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
+--
 Hello!
 I have this function using json and a queryset with defer() method, but
 the fields not target in queryset, i need only "id" and "nome":

 models.py

 class Pessoa(models.Model):
 nome = models.CharField(max_length=50)
 data_nascimento = models.DateField()
 data_inclusao = models.DateField()
 cpf = models.CharField(max_length=14)
 telefone = models.CharField(max_length=13)
 celular = models.CharField(max_length=13)

 class Meta:
 abstract = True

 class Proprietario(Pessoa):
 endereco = models.ForeignKey(Endereco)

 def __unicode__(self):
 return "%s, %s" % (self.nome, self.cpf)

 views.py:

 def load_proprietarios(request):
 data =
 
serializers.serialize('json',Proprietario.objects.defer('cpf','telefone','celular','data_nascimento','data_inclusao',),ensure_ascii=False))
 return HttpResponse(data, mimetype="application/javascript")

 This is the output:

 [{"pk": 1, "model":
 
"proprietario.proprietario_deferred_celular_cpf_telefone_data_inclusao_data_nascimento",
 "fields": {}}]

 Note that the "id" and the "nome" fields (class Proprietario / class
 abstract Pessoa) does not appear after defer() method.

 Regards.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |  Owner:  lukeplant
  aaron.l.madison@…  | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:  db mysql delete
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by lukeplant):

 For other people trying to reproduce this, it seems only to be a problem
 with the InnoDB engine. You'll need this in your settings file:


 {{{

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.mysql',
 # ...
 'OPTIONS': {"init_command": "SET storage_engine=INNODB"},
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |  Owner:  lukeplant
  aaron.l.madison@…  | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone:  1.3|  (models, ORM)
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:  db mysql delete
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by lukeplant):

 * owner:  nobody => lukeplant


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16031: Custom comment form is incomplete and wrong.

[Django]

#16031: Custom comment form is incomplete and wrong.
-+-
   Reporter:  ddshore@…  |  Owner:  teraom
   Type: | Status:  assigned
  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:  1  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1


Comment:

 The patch introduces a third column, which is not correct since the form
 only has two columns. It would be more correct to have a single ``.

 For completeness it'd also be good to wrap the form with ``
 tags, and also to clean up a similar example in
 https://docs.djangoproject.com/en/dev/ref/contrib/comments/example/

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

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

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

[Django]

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

Comment (by julien):

 Just a note. `slug_keyword` and `pk_keyword` don't feel very explicit to
 me. I wonder if they shouldn't be `slug_url_kwarg` and `pk_url_kwarg`
 instead. Not the prettiest but at least more explicit, and also consistent
 with `django.views.generic.edit.FormMixin.get_form_kwargs()`.

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

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

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

[Django]

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

 * stage:  Accepted => Ready for checkin


Comment:

 The other patch was only fixing one of the three typos ;-)

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

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

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

[Django]

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

 * 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] #16091: typo in model instance docs

[Django]

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

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

[Django] #16126: please add information on rendering DELETE checkbox manually for formset

[Django]

#16126: please add information on rendering DELETE checkbox manually for formset
---+---
 Reporter:  tim@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  SVN|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
---+---
 https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-the-
 formset-in-the-template


 {{{
 
 {{ formset.management_form }}
 {% for form in formset %}
 {{ form.id }}
 
 {{ form.name }}
 {{ form.age }}
 {{ form.DELETE }}   
 
 {% endfor %}
 

 }}}

 http://stackoverflow.com/questions/2635410/

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #5805: Specify multicolumn indexes.

[Django]

#5805: Specify multicolumn indexes.
-+-
   Reporter:  Stavros|  Owner:  nobody
  Korokithakis| Status:  reopened
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  index multicolumn
 Resolution: |  indexes database
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by jgelens):

 * cc: jeffrey@… (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] #16093: Typo in "Performing raw SQL queries"

[Django]

#16093: Typo in "Performing raw SQL queries"
-+-
   Reporter:  direvus@…  |  Owner:  teraom
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  typo apostrophe its
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-

Comment (by timo):

 In [16294]:
 {{{
 #!CommitTicketReference repository="" revision="16294"
 [1.3.X] Fixed #16093 - Typo in "Performing raw SQL queries"; thanks
 direvus.

 Backport of r16293 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] r16294 - django/branches/releases/1.3.X/docs/topics/db

[noreply]

Author: timo
Date: 2011-05-30 05:11:46 -0700 (Mon, 30 May 2011)
New Revision: 16294

Modified:
   django/branches/releases/1.3.X/docs/topics/db/sql.txt
Log:
[1.3.X] Fixed #16093 - Typo in "Performing raw SQL queries"; thanks direvus.

Backport of r16293 from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/db/sql.txt
===
--- django/branches/releases/1.3.X/docs/topics/db/sql.txt   2011-05-30 
12:11:10 UTC (rev 16293)
+++ django/branches/releases/1.3.X/docs/topics/db/sql.txt   2011-05-30 
12:11:46 UTC (rev 16294)
@@ -228,7 +228,7 @@
 If you are using more than one database you can use
 ``django.db.connections`` to obtain the connection (and cursor) for a
 specific database. ``django.db.connections`` is a dictionary-like
-object that allows you to retrieve a specific connection using it's
+object that allows you to retrieve a specific connection using its
 alias::
 
 from django.db import connections

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16293 - django/trunk/docs/topics/db

[noreply]

Author: timo
Date: 2011-05-30 05:11:10 -0700 (Mon, 30 May 2011)
New Revision: 16293

Modified:
   django/trunk/docs/topics/db/sql.txt
Log:
Fixed #16093 - Typo in "Performing raw SQL queries"; thanks direvus.

Modified: django/trunk/docs/topics/db/sql.txt
===
--- django/trunk/docs/topics/db/sql.txt 2011-05-29 23:26:44 UTC (rev 16292)
+++ django/trunk/docs/topics/db/sql.txt 2011-05-30 12:11:10 UTC (rev 16293)
@@ -228,7 +228,7 @@
 If you are using more than one database you can use
 ``django.db.connections`` to obtain the connection (and cursor) for a
 specific database. ``django.db.connections`` is a dictionary-like
-object that allows you to retrieve a specific connection using it's
+object that allows you to retrieve a specific connection using its
 alias::
 
 from django.db import connections

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16093: Typo in "Performing raw SQL queries"

[Django]

#16093: Typo in "Performing raw SQL queries"
-+-
   Reporter:  direvus@…  |  Owner:  teraom
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  typo apostrophe its
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by timo):

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


Comment:

 In [16293]:
 {{{
 #!CommitTicketReference repository="" revision="16293"
 Fixed #16093 - Typo in "Performing raw SQL queries"; thanks direvus.
 }}}

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

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

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

[Django]

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

Comment (by igors):

 Thanks for the feedback julien. I agree with you that the method name is
 too long, specially because it has an "and". I'm not very good on giving
 names. What about "save_all", or "save_all_objects"?

 I've added a new patch with tests, there is a unit test mocking external
 calls to make sure it calls the correct methods, and a more high level
 test, to make sure I can do what I want, that is edit all related objects
 on add_view and change_view.

 I'll work on some docs for it later.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16123: DateTimeField, DateField fails covert unicode date string with non-ascii characters

[Django]

#16123: DateTimeField, DateField fails covert unicode date string with non-ascii
characters
+--
   Reporter:  Gene  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Forms
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  unicode, date, forms
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  0
+--
Changes (by ramiro):

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


Comment:

 Patch need to be generated from the root of the source code tree, needs
 tests.

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

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

Re: [Django] #16084: makemessages command doesn't respect LOCALE_PATHS setting (was: makemessages command doesn't respect LOCALE_PATHS setting at all)

[Django]

#16084: makemessages command doesn't respect LOCALE_PATHS setting
-+-
   Reporter:  heylinus   |  Owner:  nobody
   Type:  New| Status:  reopened
  feature|  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by ramiro):

 * status:  closed => reopened
 * stage:  Unreviewed => Accepted
 * resolution:  invalid =>


Comment:

 agree this is something that isn't completely eas to use after the changes
 that start deprecation of a locale/ subdir of the ''project dir''. We need
 to give users the ability to specify an output directory when running
 `makemessages`, or similar solution. Reopening.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16124: makemessages failed with UnicodeDecodeError

[Django]

#16124: makemessages failed with UnicodeDecodeError
---+---
   Reporter:  serg.partizan@…  |  Owner:  nobody
   Type:  Bug  | Status:  closed
  Milestone:   |  Component:  Uncategorized
Version:  1.3  |   Severity:  Normal
 Resolution:  duplicate|   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---
Changes (by ramiro):

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


Comment:

 Duplicate of #15848 -- Unfortunately this bug is present in 1.3, was fixed
 afterwards in the 1.3.X branch and that fix will be available in a future
 1.3.1 release. You might want to use a SVN checkout of that branch for the
 time being.

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

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

Re: [Django] #16123: DateTimeField, DateField fails covert unicode date string with non-ascii characters

[Django]

#16123: DateTimeField, DateField fails covert unicode date string with non-ascii
characters
+--
   Reporter:  Gene  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Forms
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  unicode, date, forms
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+--
Changes (by jonash):

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


Comment:

 Seems like the right solution to me.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16125: document BoundField's id_for_label attribute

[Django]

#16125: document BoundField's id_for_label attribute
+---
 Reporter:  Keryn Knight   |  Owner:  nobody
 Type:  Cleanup/optimization| Status:  new
Milestone:  |  Component:  Documentation
  Version:  1.3 |   Severity:  Normal
 Keywords:  boundfield forms|   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  1
+---
 As there is no separate documentation on BoundField -- its just rolled
 into the [https://docs.djangoproject.com/en/dev/topics/forms/ page on
 forms] -- it would be good to have additional fields even passingly
 documented under the section on
 [https://docs.djangoproject.com/en/dev/topics/forms/?from=olddocs#looping-
 over-the-form-s-fields looping over the form's fields]. Specifically, it
 may be necessary on occassion to target one field with more than one
 label, which requires knowledge of BoundField.id_for_label or rooting
 through the source code.

 I'd be tempted to also document css_classes and auto_id, although I
 suppose auto_id could be considered
 
private?https://code.djangoproject.com/browser/django/trunk/django/forms/forms.py

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

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

[Django] #16124: makemessages failed with UnicodeDecodeError

[Django]

#16124: makemessages failed with UnicodeDecodeError
-+---
 Reporter:  serg.partizan@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Uncategorized
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+---
 {{{
 python manage.py makemessages -l ru
 processing language ru
 Traceback (most recent call last):
   File "manage.py", line 11, in 
 execute_manager(settings)
   File "/usr/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 438, in execute_manager
 utility.execute()
   File "/usr/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/lib/python2.7/site-packages/django/core/management/base.py",
 line 191, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/usr/lib/python2.7/site-packages/django/core/management/base.py",
 line 220, in execute
 output = self.handle(*args, **options)
   File "/usr/lib/python2.7/site-packages/django/core/management/base.py",
 line 351, in handle
 return self.handle_noargs(**options)
   File "/usr/lib/python2.7/site-
 packages/django/core/management/commands/makemessages.py", line 365, in
 handle_noargs
 make_messages(locale, domain, verbosity, process_all, extensions,
 symlinks, ignore_patterns, no_wrap, no_obsolete)
   File "/usr/lib/python2.7/site-
 packages/django/core/management/commands/makemessages.py", line 233, in
 make_messages
 f.write(templatize(src, orig_file[2:]))
   File "/usr/lib/python2.7/site-
 packages/django/utils/translation/__init__.py", line 127, in templatize
 return _trans.templatize(src, origin)
   File "/usr/lib/python2.7/site-
 packages/django/utils/translation/trans_real.py", line 450, in templatize
 content = u''.join(comment)
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xd1 in position 11:
 ordinal not in range(128)
 }}}

 This error happens when parsing template with {% comment %} some cyrillic
 text {% endcomment %}
 I was fixed this for myself in this way:
 {{{
 content = u''.join(map(lambda s: s.decode('utf-8'), comment))
 }}}
 in /usr/lib/python2.7/site-packages/django/utils/translation/trans_real.py
 at line 450

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

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

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

[Django]

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

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16123: DateTimeField, DateField fails covert unicode date string with non-ascii characters

[Django]

#16123: DateTimeField, DateField fails covert unicode date string with non-ascii
characters
--+
 Reporter:  Gene  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Forms
  Version:  1.3   |   Severity:  Normal
 Keywords:  unicode, date, forms  |   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
--+
 it's old python bug - [python-Bugs-1280061]
 in my case (ru_RU)


 {{{
 >>>from sys import platform
 >>>from locale import setlocale, LC_ALL
 >>>locale = 'russian' if platform == 'win32' else ''
 >>>setlocale(LC_ALL, locale) #set locale for '%d %b %Y' convertion
 }}}



 {{{
 >>>import time, datetime
 >>>datetime.date(*time.strptime(u'31 мая 2011', '%d %b %Y')[:3]) # like in
 django/forms/fields.py, Line 362
 ValueError: time data u'31 \u043c\u0430\u044f 2011' does not match format
 '%d %b %Y'
 }}}
 for strings contains non-ascii characters, you need
 {{{
 'string'.encode('utf8')
 }}}


 {{{
 >>>datetime.date(*time.strptime(u'31 мая 2011'.encode('utf8'), '%d %b
 %Y')[:3])
 datetime.date(2011, 5, 31)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
-+-
   Reporter: |  Owner:  adrian
  jkocherhans| Status:  reopened
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Fixed on   |  Easy pickings:  0
  a branch   |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * easy:  1 => 0


Comment:

 Not an easy picking ;)

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

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

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

[Django]

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

Comment (by geber@…):

 Django, just as it is selected in VERSION: 1.3
 Sorry, about the Backend. MySQL, we use.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
-+-
   Reporter: |  Owner:  adrian
  jkocherhans| Status:  reopened
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Fixed on   |  Easy pickings:  1
  a branch   |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by nfg):

 * easy:  0 => 1


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

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

Re: [Django] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
-+-
   Reporter: |  Owner:  adrian
  jkocherhans| Status:  reopened
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Fixed on   |  Easy pickings:  0
  a branch   |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by nfg):

 * cc: nils@… (added)
 * easy:   => 0


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

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

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

[Django]

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

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


Old description:

> Currently, in SingleObjectMixin, Django looks for a 'pk' or 'slug'
> keyword argument to use for looking up an instance of a model. You can
> override slug_field when the field on the model is something other than
> "slug". What you can't do is designate different URL keywords to use for
> these lookup, and to override this in a subclass the whole get_object
> method needs to be reimplemented.
>
> My proposition is to have a 'pk_keyword' and 'slug_keyword' field on
> SingleObjectMixin which default to 'pk' and 'slug' respectively, but can
> easily be overridden.
>
> Use case:
>
> I have a product app with a URL like this:
>
> /(r'^(?P[\w-]+)/(?P[\w-]*)-(?P\d+)/$'
>
> The view uses a subclass of DetailView with the pk keyword being used for
> fetching the product. But we also have optional product review URLs which
> are only included if the reviews app is installed, and are included like
> this:
>
> url(r'^(?P[\w-]+)/(?P[\w-]*)-(?P\d+)/',
> include(self.reviews_app.urls)),
>
> Within the reviews URLs we have a review detail view which also uses
> DetailView, this means I end up with two pk keywords in the URLs. Now I
> could just use a different keyword for the product pk keyword for this
> include, but I prefer consistency in my URL patterns. I would rather use
> 'item_pk' and 'review_pk' in all cases, which I can't currently do.
> I've had a look at the code and it seems like a straightforward change,
> I'm happy to submit the patch myself if this issue is accepted.

New description:

 Currently, in `SingleObjectMixin`, Django looks for a 'pk' or 'slug'
 keyword argument to use for looking up an instance of a model. You can
 override slug_field when the field on the model is something other than
 "slug". What you can't do is designate different URL keywords to use for
 these lookup, and to override this in a subclass the whole get_object
 method needs to be reimplemented.

 My proposition is to have a 'pk_keyword' and 'slug_keyword' field on
 `SingleObjectMixin` which default to 'pk' and 'slug' respectively, but can
 easily be overridden.

 Use case:

 I have a product app with a URL like this:
 {{{#!python
 r'^(?P[\w-]+)/(?P[\w-]*)-(?P\d+)/$'
 }}}
 The view uses a subclass of `DetailView` with the pk keyword being used
 for fetching the product. But we also have optional product review URLs
 which are only included if the reviews app is installed, and are included
 like this:
 {{{#!python
 url(r'^(?P[\w-]+)/(?P[\w-]*)-(?P\d+)/reviews',
 include(self.reviews_app.urls)),
 }}}
 Within the reviews URLs we have a review detail view which also uses
 `DetailView`, this means I end up with two pk keywords in the URLs. Now I
 could just use a different keyword for the product pk keyword for this
 include, but I prefer consistency in my URL patterns. I would rather use
 'item_pk' and 'review_pk' in all cases, which I can't currently do.
 I've had a look at the code and it seems like a straightforward change,
 I'm happy to submit the patch myself if this issue is accepted.

--

Comment:

 (Fixed the ticket description's formatting).

 Accepting as this seems like a simple and reasonable way of increasing
 `SingleObjectMixin`'s flexibility. Like for any new feature, the patch
 will need to include tests and documentation.

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

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