Re: [Django] #9154: Huge improvements in templates rendering

[Django]

#9154: Huge improvements in templates rendering
-+--
  Reporter:  msaelices   | Owner:  
Status:  new | Milestone:  
 Component:  Template system |   Version:  SVN 
Resolution:  |  Keywords:  templates, cache
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  1   |   Needs_tests:  1   
Needs_better_patch:  0   |  
-+--
Changes (by Kronuz):

 * cc: german...@gmail.com (added)
  * keywords:  => templates, cache

Comment:

 There was a bug in the way {{ block.super }} extended certain parents not
 defining the block in question.

 For parents which did not define a given BlockNode name defined in the
 child, the KeyError exception was raised and the block was added to the
 parent's ExtendsNode nodelist. The parent's complete list of BlockNode was
 then not fully restored by the last part of the patched render() function,
 leaving the added BlockNode in the parent's ExtendsNode nodelist.

 The patch I'm attaching cleans the parent's ExtendsNode's nodelist to the
 state it was before, effectively restoring the full parent's nodelist.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11002: Databrowse does not have map widgets for GIS fields.

[Django]

#11002: Databrowse does not have map widgets for GIS fields.
-+--
  Reporter:  ingenieroariel  | Owner:  jbronn
Status:  new | Milestone:  1.2   
 Component:  GIS |   Version:  SVN   
Resolution:  |  Keywords:  databrowse
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * milestone:  => 1.2
  * owner:  nobody => jbronn
  * needs_docs:  => 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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  lukeplant
Status:  assigned| Milestone:   
 Component:  Uncategorized   |   Version:  SVN  
Resolution:  |  Keywords:  csrf 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Comment (by Glenn):

 Replying to [comment:29 lukeplant]:
 > a page on `attacker.example.com` could send a header like this `Set-
 Cookie: csrf=myval,domain=.example.com`.

 But in that case, you can just use a pre-fabricated cookie and token.
 Just access the site once in advance to get a cookie and token that match
 up.

 Similar problems happen (as described in the PDF you linked) with HTTPS.
 A MITM attack, using HTTP, could set the CSRF cookie; then, even if your
 sensitive forms are HTTPS, you could still CSRF into HTTPS using the
 cookie you MITM'd earlier.

 This response is getting complicated, so I'm going to enumerate the
 attacks being discussed before continuing:

 1: A same-domain site sets a known CSRF cookie in order to set a known
 CSRF token, and uses it to perform generic CSRF.
 2: An active attacker does an MITM to establish an HTTP session, creating
 a known CSRF on a user's system.  It then performs a CSRF attack on the
 user, targetting HTTPS.
 3: A same-domain site sets a known CSRF cookie in order to set a known
 CSRF token, and then uses that to perform login CSRF.

 #1: In principle, this could be fixed by keeping a record of all CSRF
 tokens which were supplied for each session.  Reject any CSRF token which
 has not legitimately been used for a session.  This gets complicated; for
 example, if the session is reset (creating a new session on logout), the
 existing CSRF token needs to be copied over to the new session.  I hate
 this idea automatically, and I hope there's a better way.

 #2: This one is serious in principle.  If your site is completely HTTPS,
 you reasonably expect CSRF protection to be very strong and not subject to
 MITM attacks, but if the attacker can MITM, he can fool a user into
 loading an HTTP page to manipulate the CSRF cookie.  Probably any fix for
 #1 would fix this, too.

 #3: If the attacker can manipulate cookies like this, preventing login
 CSRF is very difficult.  No form of "lock CSRF token to session" works--
 the attacker can simply clear the session cookie, since he doesn't care if
 the user gets logged out when performing login CSRF.  The only way I can
 think of (with the CSRF token approach) is to lock the CSRF token to the
 user's IP, so an attacker can't use a pre-fabricated CSRF token.  This is
 unacceptable; some users still have rapidly changing IPs.  I suspect this
 attack combination (login CSRF + same domain) is narrow enough that not
 protecting against it is acceptable, as long as it's documented.

 I'm not personally too concerned about same-domain attacks, as long as the
 weakness is well-documented.  There's a simpler way to fix it: get your
 own domain and stop sharing a domain with people you don't trust.  (I
 don't know all of the issues with cookie domains, though.  I know--having
 just tried it--that I can't set a domain cookie on a TLD, eg. ".com", at
 least in FF.  Can a user on www.ed.ac.uk set a domain cookie for
 ".ac.uk"?)

 The MITM case bothers me, though.  One "fix" would be to challenge-
 response it.  One HTTPS request (eg. "checkout") brings up a new form with
 a new, one-time-use token; and it has another form (eg. "confirm
 purchase") which submits using the one-time token.  Of course, almost
 every sane online store does this, to prevent duplicating a purchase, and
 it'd prevent the MITM issue as well.  But it's not a general solution,
 since you don't want to have to double-confirm everything.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10895: Improvements in BRCPFField and BRCNPJField in localflavor.br.forms

[Django]

#10895: Improvements in BRCPFField and BRCNPJField in localflavor.br.forms
-+--
  Reporter:  luizvital   | Owner:  waa  
   
Status:  assigned| Milestone:   
   
 Component:  django.contrib.localflavor  |   Version:  SVN  
   
Resolution:  |  Keywords:  localflavor 
brcpffield, brcpnjfield, br, localflavor
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

 * cc: semente+djangoproj...@taurinus.org (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] #9874: Added template cache in template loader

[Django]

#9874: Added template cache in template loader
-+--
  Reporter:  novoya  | Owner:  novoya
Status:  reopened| Milestone:
 Component:  Template system |   Version:  SVN   
Resolution:  |  Keywords:  template cache
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by ramiro):

 See also #9154, it contains a patch with a similar implementation and it
 seems to take in account problems found with the `{{ block.super}}`
 variable.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
---+
  Reporter:  danbrwn   | Owner:  nobody 
   
Status:  new   | Milestone:  1.1
   
 Component:  Database layer (models, ORM)  |   Version:  
1.0-alpha-2   
Resolution:|  Keywords:  
foreign,key,quoted
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by GDorn):

 Confirming that happens to me as well in the 1.1 beta 1, freshly
 installed.  I also can show an identical case (except for declaration
 order) which doesn't cause the problem.

 This arrangement causes the {{{AttributeError}}}:
 {{{
 class ClassA(models.Model):
 ref = models.ForeignKey("ClassB")

 class ClassAForm(ModelForm):
 class Meta:
 model=ClassA

 class ClassB(models.Model):
 pass
 }}}


 This arrangement does not:
 {{{
 class ClassA(models.Model):
 ref = models.ForeignKey("ClassB")

 class ClassB(models.Model):
 pass

 class ClassAForm(ModelForm):
 class Meta:
 model=ClassA
 }}}

 Hope this helps.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  lukeplant
Status:  assigned| Milestone:   
 Component:  Uncategorized   |   Version:  SVN  
Resolution:  |  Keywords:  csrf 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Comment (by lukeplant):

 Replying to [comment:28 Glenn]:

 > Another thought: is there a specific benefit to hashing the token?  The
 cookies are sensitive data to begin with; if someone can read your
 cookies, you're already doomed.  There's a benefit to eliminating this
 hash: JavaScript that creates a form dynamically can include the CSRF
 token client-side simply by reading the cookie.  Right now, scripts
 doesn't have access to the token unless it's exposed manually in some
 other way.


 I've pondered this too - I originally added the hashing with a server-side
 secret to make sure that the form had indeed been generated by the server,
 and not by anyone else.

 Having thought about it, I can come up with at least one scenario where
 having this hash is useful.  In the case of untrusted sub-domains, a page
 on `attacker.example.com` could send a header like this `Set-Cookie:
 csrf=myval,domain=.example.com`.  They would then be able to generate a
 form targeted at `victim.example.com` containing ``, and since the token would match the cookie they set, the
 CSRF attack would be successful.  With the server side hashing of the
 token, we avoid this.  (I believe that attempts by malicious subdomains to
 get around this by javascript and iframes etc. will fail due to browser
 policies, just as with cross-domain attacks).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

[Django]

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
---+
  Reporter:  ikelly| Owner:  mtredinnick
Status:  assigned  | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by JasonCreighton):

 It's worth noting that in some circumstances, this bug can drastically
 increase the number of queries run. For instance, each time an instance of
 a model that uses inheritance is displayed in a form using a
 ModelChoiceField, an extra query is run. So if you display 50 items in
 select box, 51 queries will be run. (1 for the initial list, and an extra
 query for each item in the list.)

 It becomes even worse if you have multiple select boxes, as you might with
 an inline formset, since the extra query will be run for '''each''' item
 in '''each''' select box, which can easily lead to hundreds of unnecessary
 queries being run.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10973: simpler doctesting

[Django]

#10973: simpler doctesting
+---
  Reporter:  pcicman| Owner:  nobody 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version:  1.0
Resolution: |  Keywords:  doctest modules
 Stage:  Unreviewed | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  1  
Needs_better_patch:  0  |  
+---
Changes (by Nate):

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

Comment:

 For what it's worth, I agree with this suggestion. I had actually done
 something similar to automate the doctesting of my own modules. Pcicman, I
 took the liberty of making a patch out of your code. It could use some
 tests, though.

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

Re: [Django] #11005: ./manage query -- query the django orm from the command line

[Django]

#11005: ./manage query -- query the django orm from the command line
-+--
  Reporter:  den...@kaarsemaker.net  | Owner:  nobody
Status:  new | Milestone:
 Component:  django-admin.py |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

  * needs_better_patch:  => 0
  * component:  Uncategorized => django-admin.py
  * needs_tests:  => 0
  * needs_docs:  => 0

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

[Django] #11007: Add django.db.Model.changes(self) that returns a dict of differences

[Django]

#11007: Add django.db.Model.changes(self) that returns a dict of differences
--+-
 Reporter:  den...@kaarsemaker.net|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 The attached patch adds a method to the Model class that returns a dict of
 differences between the current instance and the values stored in the
 database.

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

[Django] #11006: Cannot set intiial data with inline model formset

[Django]

#11006: Cannot set intiial data with inline model formset
+---
 Reporter:  Joshua "jag" Ginsberg   |   Owner:  nobody 
   
   Status:  new |   Milestone:  
  
Component:  Forms   | Version:  1.0 
  
 Keywords:  |   Stage:  
Unreviewed
Has_patch:  0   |  
+---
 It should be possible to set initial data for non-instance related forms
 in an inline model formset, and it's presently not supported with the
 initial= kwarg. This should be supported to mimic the other form/formset
 factory functions.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11005: ./manage query -- query the django orm from the command line

[Django]

#11005: ./manage query -- query the django orm from the command line
+---
 Reporter:  den...@kaarsemaker.net  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Uncategorized   | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 Attached patch adds a new ./manage.py command to query the django ORM from
 the command line. Output is either comma-separated or done with a
 template, documentation included in 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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  lukeplant
Status:  assigned| Milestone:   
 Component:  Uncategorized   |   Version:  SVN  
Resolution:  |  Keywords:  csrf 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Comment (by Glenn):

 > Why don't we reject all POST requests that have neither CSRF cookie nor
 the session cookie

 The rationale was so forms don't break if the user is filtering cookies
 (eg. Privoxy), and because this was the existing behavior.

 This isn't a problem as long as CSRF exemption is being used properly.  I
 suspect it often won't be--minority cases are often overlooked.  But,
 handling login CSRF is probably more important.

 > Why do we actually need to have a unique CSRF cookie

 It probably doesn't matter; if the user has multiple sites on the same
 domain with access to each others' cookies, they have to trust each other
 anyway.

 There's a somewhat more convincing argument for explicitly including the
 CSRF form token in that PDF than the ones I've heard here: if it's added
 automatically, then any form going out of the trusted site will leak the
 token.

 Another thought: is there a specific benefit to hashing the token?  The
 cookies are sensitive data to begin with; if someone can read your
 cookies, you're already doomed.  There's a benefit to eliminating this
 hash: JavaScript that creates a form dynamically can include the CSRF
 token client-side simply by reading the cookie.  Right now, scripts
 doesn't have access to the token unless it's exposed manually in some
 other way.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11004: cache.set should raise an exception when key is too long

[Django]

#11004: cache.set should raise an exception when key is too long
---+
 Reporter:  RaceCondition  |   Owner:  nobody
   Status:  new|   Milestone:  1.1   
Component:  Cache system   | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 At least when using DB caching, the maximum allowed cache key length is
 255 because the cache table is created that way. But when cache.set() is
 not currently aware of this and when caching a value using a key longer
 than 255 characters, a database error is thrown (which, at least in the
 case of Postgres, is not very clear about the reason).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10204: Validation fails in spanish localflavor ESIdentityCardNumberField

[Django]

#10204: Validation fails in spanish localflavor ESIdentityCardNumberField
-+--
  Reporter:  meaksh  | Owner:  meaksh   
 
Status:  assigned| Milestone:   
 
 Component:  django.contrib.localflavor  |   Version:  SVN  
 
Resolution:  |  Keywords:  
ESIdentityCardNumberField, NIE
 Stage:  Accepted| Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  1   |  
-+--
Changes (by Cesar Ortiz ):

  * needs_better_patch:  0 => 1

Comment:

 The 'T' letter is not a valid cif/nif.
 References:
 http://es.wikipedia.org/wiki/NIF
 http://es.wikipedia.org/wiki/C%C3%B3digo_de_identificaci%C3%B3n_fiscal
 http://es.wikipedia.org/wiki/NIE

 Furthemore... to support the XYZ the algorithm must be changed. An '0'
 (for X), '1' (for the Y), '2' (for Z) should be added at the beggining of
 the number before the casting to int.


 Replying to [ticket:10204 meaksh]:
 > The spanish localflavor ESIdentityCardNumberField accepts the syntax of
 the spanish official cards type, but due the new revision of the law
 (http://www.boe.es/boe/dias/2008/07/15/pdfs/A30880-30880.pdf), it need to
 be updated.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #5863: list_display does not allow functions of referenced objects

[Django]

#5863: list_display does not allow functions of referenced objects
---+
  Reporter:  Beat Bolli   | Owner:  nobody 
 
Status:  reopened  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  
list_display
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by kmtracey):

 Replying to [comment:22 haffi67]:
 > One thing that I think no one has pointed out yet; if it were possible
 to set {{{table__field}}} in list_display, you could order the list by
 that field in the interface, which you can't do with callables.

 You can set admin_order_field on a callable to specify ordering; doc on
 that is the last bullet under
 
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display.
 If that doesn't currently support the double-underscore syntax to
 reference a ordering by a field in a related object, then I doubt it would
 'just work' for things specified that way in list_display.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11001: Crash (double free) on OpenBSD on POST request

[Django]

#11001: Crash (double free) on OpenBSD on POST request
--+-
  Reporter:  thesta...@gmail.com  | Owner:  nobody  
Status:  closed   | Milestone:  
 Component:  Core framework   |   Version:  1.0 
Resolution:  invalid  |  Keywords:  segfault openbsd
 Stage:  Unreviewed   | Has_patch:  0   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by thesta...@gmail.com):

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

Comment:

 You guessed perfectly right. This module was installed as dependency to
 pylint and after removing it, my application worked fine again.

 Sorry for the noise, and thank you for the quick answer.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11001: Crash (double free) on OpenBSD on POST request

[Django]

#11001: Crash (double free) on OpenBSD on POST request
--+-
  Reporter:  thesta...@gmail.com  | Owner:  nobody  
Status:  new  | Milestone:  
 Component:  Core framework   |   Version:  1.0 
Resolution:   |  Keywords:  segfault openbsd
 Stage:  Unreviewed   | Has_patch:  0   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by ramiro):

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

Comment:

 The stack dump shows
 [http://www.egenix.com/products/python/mxBase/mxTextTools/ mxTextTools]
 is, for some reason, involved:

 {{{
 #5  0x079dcd2b in mxBMS_Free () from /usr/local/lib/python2.5/site-
 packages/mx/TextTools/mxTextTools/mxTextTools.so
 }}}

 Can you try testing without that module installed?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11003: Add USE INDEX, FORCE INDEX capabilities to ORM

[Django]

#11003: Add USE INDEX, FORCE INDEX capabilities to ORM
--+-
 Reporter:  Renato Alves  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:  INDEX USE FORCE   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Recently I've add significant performance issues with Django + MySQL.
 The reasons behind this are MySQL not using an existing index due to low
 cardinality and instead do a full table scan. In most cases this is the
 correct choice but there some exceptions. For these, the workaround is to
 add "FORCE INDEX (index_name)" to the SQL.
 However there is no support for this feature in the ORM.

 As for the relevance of this functionality, in my case, query time was
 0.09 sec when using FORCE INDEX and 10.3 sec when not.
 This problem becomes more visible if the columns involved are used in
 several JOIN operations.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11000: Spanish NIF/NIE not fully implemented

[Django]

#11000: Spanish NIF/NIE not fully implemented
--+-
  Reporter:  Cesar Ortiz   | Owner:  
nobody
Status:  closed   | Milestone:  
  
 Component:  Uncategorized|   Version:  1.0 
  
Resolution:  duplicate|  Keywords:  
localfavlor es nie nif
 Stage:  Unreviewed   | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by ramiro):

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

Comment:

 Duplicate of #10204. Please post you comments regarding the 'T' prefix
 there or better yet, coordinate with the reporter of that ticket to arrive
 at a correct, comprehensive 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] #10997: Admin backend uses `set` without the Python 2.3 fallback

[Django]

#10997: Admin backend uses `set` without the Python 2.3 fallback
---+
  Reporter:  anonymous | Owner: 
Status:  new   | Milestone: 
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by Tarken):

  * has_patch:  0 => 1

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

[Django] #11002: Databrowse does not have map widgets for GIS fields.

[Django]

#11002: Databrowse does not have map widgets for GIS fields.
+---
 Reporter:  ingenieroariel  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  GIS | Version:  SVN   
 Keywords:  databrowse  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Databrowse should have a way to configure a map widget for GIS fields
 instead of just showing the WKT

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #5863: list_display does not allow functions of referenced objects

[Django]

#5863: list_display does not allow functions of referenced objects
---+
  Reporter:  Beat Bolli   | Owner:  nobody 
 
Status:  reopened  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  
list_display
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by haffi67):

 One thing that I think no one has pointed out yet; if it were possible to
 set {{{table__field}}} in list_display, you could order the list by that
 field in the interface, which you can't do with callables.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11000: Spanish NIF/NIE not fully implemented

[Django]

#11000: Spanish NIF/NIE not fully implemented
-+--
 Reporter:  Cesar Ortiz   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  1.0   
 Keywords:  localfavlor es nie nif   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 In the file
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/localflavor/es/forms.py,

 the calculation of the nif/nif is not totally implemented.
 The nif_get_checksum() call, only will work for the letter X.
 It should be upgraded to support letters Y and Z.

 Furthemore the following definition is wrong:

 self.nie_types = 'XT'

 'T' is not a NIE type. I guess it shoudl be an 'Y'.

 When the number for a nie is calculated, the X,Y and Z should be replaced
 by 0,1 and 2.

 More info (there is talked about the Y but not about the Z):
 http://es.wikibooks.org/wiki/Algoritmo_para_obtener_la_letra_del_NIF

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #11001: Crash (double free) on OpenBSD on POST request

[Django]

#11001: Crash (double free) on OpenBSD on POST request
-+--
 Reporter:  thesta...@gmail.com  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Core framework   | Version:  1.0   
 Keywords:  segfault openbsd |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 I currently experience crashes when issuing some POST request on my
 application. Repoduced anytime with:

 {{{
 % ./manage.py shell
 >>> from django.test.client import Client
 >>> c = Client()
 >>> c.post('/admin/')
 python in free(): error: bogus pointer (double free?)
 }}}

 The code used to not crash, and one day, I found it not working anymore. I
 am definitively unable to find the cause of the behaviour change.

 '''Box configuration'''

 {{{
 % uname -mprsv
 OpenBSD 4.5 GENERIC.MP#0 i386 Intel(R) Atom(TM) CPU N270 @ 1.60GHz
 ("GenuineIntel" 686-class)
 % ./manage.py shell
 15:30
 Python 2.5.4 (r254:67916, Mar  1 2009, 15:10:20)
 [GCC 3.3.5 (propolice)] on openbsd4
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> import django
 >>> django.get_version()
 '1.0.2 final'
 }}}

 I tried the very same code on another box (not same hardware) with same
 OS, python and django versions, and it works (I so hope this is not an
 hardware issue).

 '''Some debugging'''

 I narrowed down the source of the error to the following line from
 django/http/multipartparser.py file using pdb. Do not hesitate asking some
 more information.

 {{{
 609 yield parse_boundary_stream(sub_stream, 1024)
 }}}

 Please find below the stack extracted from gdb. I tried using pystack but
 it not seems working.

 {{{
 #0  0x09fa6f81 in kill () from /usr/lib/libc.so.50.1
 #1  0x09ff3907 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
 #2  0x09fcb8e1 in wrterror (p=0x29f766ee "bogus pointer (double free?)")
 at /usr/src/lib/libc/stdlib/malloc.c:375
 #3  0x09fcd2cd in free (ptr=0x80fca5d4) at
 /usr/src/lib/libc/stdlib/malloc.c:1328
 #4  0x09f9e2b1 in bm_free (pat=0x823d1000) at
 /usr/src/lib/libc/string/bm.c:142
 #5  0x079dcd2b in mxBMS_Free () from /usr/local/lib/python2.5/site-
 packages/mx/TextTools/mxTextTools/mxTextTools.so
 #6  0x00170b41 in meth_dealloc () from /usr/local/lib/libpython2.5.so.1.0
 #7  0x0016e410 in dict_dealloc () from /usr/local/lib/libpython2.5.so.1.0
 #8  0x001838bb in subtype_dealloc () from
 /usr/local/lib/libpython2.5.so.1.0
 #9  0x0016e410 in dict_dealloc () from /usr/local/lib/libpython2.5.so.1.0
 #10 0x001838bb in subtype_dealloc () from
 /usr/local/lib/libpython2.5.so.1.0
 #11 0x001adc67 in PyEval_EvalFrameEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #12 0x001b1be6 in fast_function () from /usr/local/lib/libpython2.5.so.1.0
 #13 0x001b17a1 in call_function () from /usr/local/lib/libpython2.5.so.1.0
 #14 0x001afa5f in PyEval_EvalFrameEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #15 0x001b1be6 in fast_function () from /usr/local/lib/libpython2.5.so.1.0
 #16 0x001b17a1 in call_function () from /usr/local/lib/libpython2.5.so.1.0
 #17 0x001afa5f in PyEval_EvalFrameEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #18 0x001b1be6 in fast_function () from /usr/local/lib/libpython2.5.so.1.0
 #19 0x001b17a1 in call_function () from /usr/local/lib/libpython2.5.so.1.0
 #20 0x001afa5f in PyEval_EvalFrameEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #21 0x001b03c8 in PyEval_EvalCodeEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #22 0x0016188a in function_call () from /usr/local/lib/libpython2.5.so.1.0
 #23 0x00148a28 in PyObject_Call () from /usr/local/lib/libpython2.5.so.1.0
 #24 0x00148ac4 in call_function_tail () from
 /usr/local/lib/libpython2.5.so.1.0
 #25 0x00148b57 in PyObject_CallFunction () from
 /usr/local/lib/libpython2.5.so.1.0
 #26 0x00154511 in property_descr_get () from
 /usr/local/lib/libpython2.5.so.1.0
 #27 0x00173043 in PyObject_GenericGetAttr () from
 /usr/local/lib/libpython2.5.so.1.0
 #28 0x00172ba5 in PyObject_GetAttr () from
 /usr/local/lib/libpython2.5.so.1.0
 #29 0x001af527 in PyEval_EvalFrameEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #30 0x001b03c8 in PyEval_EvalCodeEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #31 0x0016188a in function_call () from /usr/local/lib/libpython2.5.so.1.0
 #32 0x00148a28 in PyObject_Call () from /usr/local/lib/libpython2.5.so.1.0
 #33 0x001b20a3 in ext_do_call () from /usr/local/lib/libpython2.5.so.1.0
 #34 0x001afdbe in PyEval_EvalFrameEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #35 0x001b03c8 in PyEval_EvalCodeEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #36 0x001b1b63 in fast_function () from /usr/local/lib/libpython2.5.so.1.0
 #37 0x001b17a1 in call_function () from /usr/local/lib/libpython2.5.so.1.0
 #38 0x001afa5f in PyEval_EvalFrameEx () from
 /usr/local/lib/libpython2.5.so.1.0
 #39 0x001b03c8 in 

Re: [Django] #11000: Spanish NIF/NIE not fully implemented

[Django]

#11000: Spanish NIF/NIE not fully implemented
--+-
  Reporter:  Cesar Ortiz   | Owner:  
nobody
Status:  new  | Milestone:  
  
 Component:  Uncategorized|   Version:  1.0 
  
Resolution:   |  Keywords:  
localfavlor es nie nif
 Stage:  Unreviewed   | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by Cesar Ortiz ):

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

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

Re: [Django] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  lukeplant
Status:  assigned| Milestone:   
 Component:  Uncategorized   |   Version:  SVN  
Resolution:  |  Keywords:  csrf 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Comment (by lukeplant):

 Glenn, a few thoughts after some reflection:

  1. Why don't we reject all POST requests that have neither CSRF cookie
 nor the session cookie (apart from those views that have been specifically
 exempted of course)?  The current patch will let through POST requests
 that don't have a CSRF cookie, which allows for login CSRF
 (http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf).  A
 simple change and we can secure against login CSRF, and I can't see any
 disadvantage to this.

  2. Why do we actually need to have a unique CSRF cookie if the user has
 specified a non-default session cookie name?  Since the CSRF is now
 decoupled from the session framework, and is orthogonal to it, I don't see
 the need for this.

  3. I think a CSRF_COOKIE_DOMAIN setting (default None) would be useful.
 This way, it is possible for a form that appears on one sub-domain with a
 target on another subdomain to be CSRF enabled and get through the
 mechanism.  I imagine this would be particularly useful if we go with
 suggestion (1), which could otherwise cause a cross-sub-domain POST
 request to be rejected.

 With these addressed, I think we have an ace patch:

  1. Login CSRF is eliminated (hitherto unaddressed)
  2. CSRF protection is decoupled from session framework, removing most
 false positives caused by session key cycling
  3. Post-processing is eliminated (at least for all core/contrib apps, you
 can still use it if you want), removing performance hit and general
 nastiness

 BTW, I've added your changes in last patch, note you need to 'svn add'
 some new files.  We really should use git or something to collaborate on
 this...

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

Re: [Django] #7539: Add ON DELETE and ON UPDATE support to Django

[Django]

#7539: Add ON DELETE and ON UPDATE support to Django
---+
  Reporter:  glassfordm| Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  feature
 Stage:  Design decision needed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by road):

 * cc: road (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
-~--~~~~--~~--~--~---

[Django] #10999: Filtering non english database

[Django]

#10999: Filtering non english database
--+-
 Reporter:  pbzrpa|   Owner:  nobody
   Status:  new   |   Milestone:  1.0.3 
Component:  Internationalization  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have a huge problem with filtering a database using foo.objects.filter()
 where the database has foreign letters and you only have access to English
 letters.

 For example:

 {{{
 foo.objects.filter(field__icontains = 'glos') can not find a record with
 the name "głos".
 }}}

 It would really help if one was able to add custom operators so that I
 could call a function on the database that would convert the letters.

 I was unable to find any documentation on the website and I also see that
 the admin interface also filters only if the correct letters are used. I
 have a polish database of users and I would like the admin interface to
 find the surname "Głos" when I enter the English version "Glos"

 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] #10825: Template filter date 'U' raises an AttributeError under certain circumstances

[Django]

#10825: Template filter date 'U' raises an AttributeError under certain
circumstances
--+-
  Reporter:  mk   | Owner:  gsong
Status:  assigned | Milestone:  1.1  
 Component:  Template system  |   Version:  SVN  
Resolution:   |  Keywords:  template date
 Stage:  Accepted | Has_patch:  1
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by mk):

 This patch works for me, 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] #10992: Unable to re-save inlines with custom char primary key

[Django]

#10992: Unable to re-save inlines with custom char primary key
---+
  Reporter:  marcob| Owner:  nobody 
  
Status:  new   | Milestone:  1.1
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  inline custom 
primary key
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 Apologies Marco - I misread your suggestion as just removing the .pk
 portion. However, you are correct - this is a workaround, not a solution.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10992: Unable to re-save inlines with custom char primary key

[Django]

#10992: Unable to re-save inlines with custom char primary key
---+
  Reporter:  marcob| Owner:  nobody 
  
Status:  new   | Milestone:  1.1
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  inline custom 
primary key
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by marcob):

 Russell, sorry for not having attached a patch, but the fix "runs" only
 with an Attribute Error Exception. So it's impossible it can break other
 cases.
 You have to substitute line 521 with this 4 lines:
 {{{
   try:
 pk_value = form.fields[pk_name].clean(raw_pk_value).pk
   except AttributeError:
 pk_value = form.fields[pk_name].clean(raw_pk_value)

 }}}

 Btw I do agree this is a workaround. We need to fix clean (with charfield
 it doesn't return the instance).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #9206: Improve documentation on PostgreSQL transactions, exceptions and savepoints

[Django]

#9206: Improve documentation on PostgreSQL transactions, exceptions and 
savepoints
---+
  Reporter:  Richard Davies   |
 Owner:  nobody
Status:  reopened  | 
Milestone:  1.1   
 Component:  Documentation |   
Version:  SVN   
Resolution:|  
Keywords:
 Stage:  Accepted  | 
Has_patch:  1 
Needs_docs:  0 |   
Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Richard Davies ):

  * needs_better_patch:  1 => 0

Comment:

 I've split out separate documentation of savepoints, have added some more
 explanation of the different between savepoint and transaction rollback
 (the example is sufficiently complex, just wasn't sufficiently well
 explained) and have reformatted so that I can use versionadded again.

 Hope this is now OK!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10998: Django does not work with Python 3

[Django]

#10998: Django does not work with Python 3
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.1-beta-1
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by russellm):

 Because when we decide to support Python 3.0, it will be a major change -
 you won't need to be subscribed to a ticket to hear about it. It will be a
 major announcement.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10996: CSRF documentation doesn't note login CSRF vulnerability

[Django]

#10996: CSRF documentation doesn't note login CSRF vulnerability
+---
  Reporter:  smehmood   | Owner:  lukeplant
Status:  new| Milestone:   
 Component:  Documentation  |   Version:  1.0  
Resolution: |  Keywords:  CSRF 
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by lukeplant):

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

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

Re: [Django] #10998: Django does not work with Python 3

[Django]

#10998: Django does not work with Python 3
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.1-beta-1
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 But at some point it should be supported, so why not have the issue open
 so that it can be tracked and subscribed to by interested parties?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10998: Django does not work with Python 3

[Django]

#10998: Django does not work with Python 3
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.1-beta-1
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 We know.  Python 3.0 is, for now, an unsupported platform.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10997: Admin backend uses `set` without the Python 2.3 fallback

[Django]

#10997: Admin backend uses `set` without the Python 2.3 fallback
---+
  Reporter:  anonymous | Owner: 
Status:  new   | Milestone: 
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * owner:  anonymous =>
  * status:  assigned => new

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

Re: [Django] #10997: Admin backend uses `set` without the Python 2.3 fallback

[Django]

#10997: Admin backend uses `set` without the Python 2.3 fallback
---+
  Reporter:  anonymous | Owner:  anonymous
Status:  assigned  | Milestone:   
 Component:  django.contrib.admin  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * owner:  nobody => anonymous
  * needs_better_patch:  => 0
  * status:  new => assigned
  * needs_tests:  => 0
  * needs_docs:  => 0

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

Re: [Django] #10998: Django does not work with Python 3

[Django]

#10998: Django does not work with Python 3
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.1-beta-1
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

 * cc: sund...@iki.fi (removed)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

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

[Django] #10998: Django does not work with Python 3

[Django]

#10998: Django does not work with Python 3
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1-beta-1
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Django is not compatible with Python 3.

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

Re: [Django] #8968: No way to utilize `next` parameter to redirect after comment deletion

[Django]

#8968: No way to utilize `next` parameter to redirect after comment deletion
--+-
  Reporter:  Dzhus| Owner:  kkubasik
Status:  reopened | Milestone:  1.1 
 Component:  django.contrib.comments  |   Version:  1.0 
Resolution:   |  Keywords:  comments
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  1|   Needs_tests:  1   
Needs_better_patch:  1|  
--+-
Comment (by kkubasik):

 Sounds good to me, if we want to utilize this inheritance order, then I'll
 implement it this week!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10698: Admin code overwrites property of models in inlineformsets

[Django]

#10698: Admin code overwrites property of models in inlineformsets
---+
  Reporter:  mk| Owner:  nobody
Status:  closed| Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:  duplicate |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mk):

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

Comment:

 Duplicate of #9362, fixed in [10667]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10997: Admin backend uses `set` without the Python 2.3 fallback

[Django]

#10997: Admin backend uses `set` without the Python 2.3 fallback
--+-
 Reporter:  anonymous |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 in line 38 of admin.actions.py:

 perms_needed = set()

 it gets error:

 global name 'set' is not defined

 with python 2.3.4

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10992: Unable to re-save inlines with custom char primary key

[Django]

#10992: Unable to re-save inlines with custom char primary key
---+
  Reporter:  marcob| Owner:  nobody 
  
Status:  new   | Milestone:  1.1
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  inline custom 
primary key
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 Verified that the problem exists, but the suggested fix doesn't work - it
 may fix the problem for charfield PK's, but it breaks all other cases (and
 the test suite verifies this).

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

[Changeset] r10674 - django/trunk/django/contrib/auth/tests

[noreply]

Author: russellm
Date: 2009-05-04 02:05:44 -0500 (Mon, 04 May 2009)
New Revision: 10674

Modified:
   django/trunk/django/contrib/auth/tests/remote_user.py
   django/trunk/django/contrib/auth/tests/urls.py
Log:
Fixed #10521 -- Modified the Remote User tests so that it isn't dependent on 
particular deployed URLs. Thanks to Kegan and Ramiro Morales for their 
contributions.

Modified: django/trunk/django/contrib/auth/tests/remote_user.py
===
--- django/trunk/django/contrib/auth/tests/remote_user.py   2009-05-03 
13:50:09 UTC (rev 10673)
+++ django/trunk/django/contrib/auth/tests/remote_user.py   2009-05-04 
07:05:44 UTC (rev 10674)
@@ -8,6 +8,7 @@
 
 class RemoteUserTest(TestCase):
 
+urls = 'django.contrib.auth.tests.urls'
 middleware = 'django.contrib.auth.middleware.RemoteUserMiddleware'
 backend = 'django.contrib.auth.backends.RemoteUserBackend'
 
@@ -28,15 +29,15 @@
 """
 num_users = User.objects.count()
 
-response = self.client.get('/')
+response = self.client.get('/remote_user/')
 self.assert_(isinstance(response.context['user'], AnonymousUser))
 self.assertEqual(User.objects.count(), num_users)
 
-response = self.client.get('/', REMOTE_USER=None)
+response = self.client.get('/remote_user/', REMOTE_USER=None)
 self.assert_(isinstance(response.context['user'], AnonymousUser))
 self.assertEqual(User.objects.count(), num_users)
 
-response = self.client.get('/', REMOTE_USER='')
+response = self.client.get('/remote_user/', REMOTE_USER='')
 self.assert_(isinstance(response.context['user'], AnonymousUser))
 self.assertEqual(User.objects.count(), num_users)
 
@@ -46,13 +47,13 @@
 as a User.
 """
 num_users = User.objects.count()
-response = self.client.get('/', REMOTE_USER='newuser')
+response = self.client.get('/remote_user/', REMOTE_USER='newuser')
 self.assertEqual(response.context['user'].username, 'newuser')
 self.assertEqual(User.objects.count(), num_users + 1)
 User.objects.get(username='newuser')
 
 # Another request with same user should not create any new users.
-response = self.client.get('/', REMOTE_USER='newuser')
+response = self.client.get('/remote_user/', REMOTE_USER='newuser')
 self.assertEqual(User.objects.count(), num_users + 1)
 
 def test_known_user(self):
@@ -62,12 +63,12 @@
 User.objects.create(username='knownuser')
 User.objects.create(username='knownuser2')
 num_users = User.objects.count()
-response = self.client.get('/', REMOTE_USER=self.known_user)
+response = self.client.get('/remote_user/', 
REMOTE_USER=self.known_user)
 self.assertEqual(response.context['user'].username, 'knownuser')
 self.assertEqual(User.objects.count(), num_users)
 # Test that a different user passed in the headers causes the new user
 # to be logged in.
-response = self.client.get('/', REMOTE_USER=self.known_user2)
+response = self.client.get('/remote_user/', 
REMOTE_USER=self.known_user2)
 self.assertEqual(response.context['user'].username, 'knownuser2')
 self.assertEqual(User.objects.count(), num_users)
 
@@ -82,13 +83,13 @@
 user.last_login = default_login
 user.save()
 
-response = self.client.get('/', REMOTE_USER=self.known_user)
+response = self.client.get('/remote_user/', 
REMOTE_USER=self.known_user)
 self.assertNotEqual(default_login, response.context['user'].last_login)
 
 user = User.objects.get(username='knownuser')
 user.last_login = default_login
 user.save()
-response = self.client.get('/', REMOTE_USER=self.known_user)
+response = self.client.get('/remote_user/', 
REMOTE_USER=self.known_user)
 self.assertEqual(default_login, response.context['user'].last_login)
 
 def tearDown(self):
@@ -113,7 +114,7 @@
 
 def test_unknown_user(self):
 num_users = User.objects.count()
-response = self.client.get('/', REMOTE_USER='newuser')
+response = self.client.get('/remote_user/', REMOTE_USER='newuser')
 self.assert_(isinstance(response.context['user'], AnonymousUser))
 self.assertEqual(User.objects.count(), num_users)
 

Modified: django/trunk/django/contrib/auth/tests/urls.py
===
--- django/trunk/django/contrib/auth/tests/urls.py  2009-05-03 13:50:09 UTC 
(rev 10673)
+++ django/trunk/django/contrib/auth/tests/urls.py  2009-05-04 07:05:44 UTC 
(rev 10674)
@@ -1,9 +1,18 @@
 from django.conf.urls.defaults import patterns
 from django.contrib.auth.urls import urlpatterns
+from django.http import HttpResponse
+from django.template import Template, RequestContext
 
+def remote_user_auth_view(request):
+

[Django] #10996: CSRF documentation doesn't note login CSRF vulnerability

[Django]

#10996: CSRF documentation doesn't note login CSRF vulnerability
---+
 Reporter:  smehmood   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords:  CSRF   |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 It is my understanding the the CsrfMiddleware module does not protect
 against the login CSRF attacks described in
 http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf.
 This post to the django-dev seems to confirm
 this:http://groups.google.com/group/django-
 
developers/browse_thread/thread/ae525f270ed46933/5a339c6d64d40868?lnk=gst=csrf#5a339c6d64d40868

 However, the documentation for the CsrfMiddleware class does not note
 this, despite having a specific 'Limitations' section.
 It also makes this false statement:
 "POST requests that are not accompanied by a session cookie are not
 protected, but they do not need to be protected, since the 'attacking' Web
 site could make these kind of requests anyway."

 Two things:

 1) The fact that an attacking website could make the requests anyway is
 not a reason to say they don't need to be protected. It might be more
 accurate to say that such requests are not authenticated, and thus, are
 unlikely to perform sensitive actions.
 2) This statement ignores the possibility of login CSRFs. These are
 requests that do not have a session cookie, but /do/ need to be protected.

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