Re: [Django] #14608: Adding a INPhoneNumberField to indian localflavor

[Django]

#14608: Adding a INPhoneNumberField to indian localflavor
---+---
   Reporter:  lawgon   |Owner:  lawgon
   Type:  New feature  |   Status:  reopened
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  india phone
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  1|
---+---

Comment (by julien):

 I think I've found the root cause for this problem and posted a proposed
 fix in #15805. If that fix gets checked in then your patch will be 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] #15805: assertFieldOutput should not use assertRaisesRegexp

[Django]

#15805: assertFieldOutput should not use assertRaisesRegexp
--+-
   Reporter:  julien  |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  Testing framework
Version:  1.2 | Severity:  Release blocker
   Keywords:  | Triage Stage:  Unreviewed
  Has patch:  1   |  Needs documentation:  0
Needs tests:  0   |  Patch needs improvement:  0
--+-
 The fact that `assertFieldOutput` uses `assertRaisesRegexp` causes some
 weird and inconsistent behaviours, which I describe in more detail in
 #14608 and in http://groups.google.com/group/django-
 developers/browse_thread/thread/96da81267aadade0

 Not only does it make no sense to use regular expressions here, but also
 pretty much all the tests in `regressiontests.forms.localflavor` using
 `assertFieldOutput` are currently passing without being absolutely sure
 that the expected error messages are correct (To verify that, try
 modifying any error message in those tests -- the tests will still pass).

 See attached patch fixing the behaviour and also straightening some tests
 that were incorrectly passing before.

 Marking as Release Blocker since, in effect, the test suite is currently
 broken because of this behaviour.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13719: blocktrans in Django 1.2 doesn't work any more

[Django]

#13719: blocktrans in Django 1.2 doesn't work any more
-+-
   Reporter: |Owner:  nobody
  schmid.ul@…|   Status:  closed
   Type: |Component:  Internationalization
  Uncategorized  | Severity:  Normal
  Milestone: | Keywords:  blocktrans
Version:  1.2|Has patch:  0
 Resolution:  invalid|  Needs tests:  0
   Triage Stage: |
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by Weslie Ni ):

 * cc: nispray@… (added)
 * type:   => Uncategorized
 * severity:   => Normal


Comment:

 Hi, seems the same problem comes to me.
 Is this ticket solved or just usage error?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15797: *_COOKIE_DOMAIN settings should reject values that won't work in modern browsers

[Django]

#15797: *_COOKIE_DOMAIN settings should reject values that won't work in modern
browsers
--+
   Reporter:  estebistec  |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  Core (Other)
Version:  1.3 | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by estebistec):

 * needs_better_patch:  1 => 0


Comment:

 Okay, updated the patch per comment 2.

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

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

Re: [Django] #14608: Adding a INPhoneNumberField to indian localflavor

[Django]

#14608: Adding a INPhoneNumberField to indian localflavor
---+---
   Reporter:  lawgon   |Owner:  lawgon
   Type:  New feature  |   Status:  reopened
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  india phone
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  1|
---+---

Comment (by lawgon):

 Given that the framework itself does not barf when the patch is used, I
 think that this bug needs to be fixed. The world will not end if django
 does not yet have an Indian Phone number field, but I have a few more of
 this type of thing in the Queue and some of them also use '-' in the error
 messages. So please take it up on the dev list. Frankly I do not think
 that error messages should compile as regex.

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

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

[Django]

#14608: Adding a INPhoneNumberField to indian localflavor
---+---
   Reporter:  lawgon   |Owner:  lawgon
   Type:  New feature  |   Status:  reopened
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  india phone
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  1|
---+---

Comment (by julien):

 Wow, it took me a long time to track this down. In fact, there's nothing
 really wrong with your patch. I think the problem is in the way that
 `django.tests.regressiontests.forms.localflavor.utils.assertFieldOutput`
 works.

 `assertFieldOutput` calls `assertRaisesRegexp` and passes the expected
 errors as a unicode string:

 In
 source:django/trunk/tests/regressiontests/forms/localflavor/utils.py#L40 :
 {{{#!python
 self.assertRaisesRegexp(ValidationError, unicode(errors),
 required.clean, input
 )
 }}}

 ... and further down the track, in `assertRaisesRegexp`, that string is
 compiled as a regular expression:

 In source:django/trunk/django/utils/unittest/case.py#L991 :
 {{{#!python
 expected_regexp = re.compile(expected_regexp)
 }}}

 Now, the issue here is that the error message in your patch contains some
 '-' characters, which are interpreted as a range, hence the 'bad character
 range' error that is raised when running the tests:

 {{{#!python
 class INLocalFlavorTests(LocalFlavorTestCase):
 def test_INPhoneNumberField(self):
 error_format = [u'Phone numbers must be in 02X-7X or 03X-6X or
 04X-5X format.']
 ...
 }}}

 Remove those '-' characters and the tests will pass... Now of course, this
 is not satisfactory. I tend to think it's a bug in the test framework. Let
 me know if somebody has an opinion on this, otherwise I might bring this
 up on django-dev.

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

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

Re: [Django] #15803: A slug on form fields like 'select' 'input' or 'checkbox'

[Django]

#15803: A slug on form fields like 'select' 'input' or 'checkbox'
-+-
   Reporter: |Owner:  nobody
  whalesalad |   Status:  closed
   Type:  New|Component:  Forms
  feature| Severity:  Normal
  Milestone: | Keywords:  forms fields widgets
Version: |  slugs
 Resolution:  duplicate  |Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by russellm):

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


Comment:

 I'm going to mark this as a duplicate of #15667. That ticket is proposing
 a move to template-based widget rendering, which should be a superset of
 what you're describing here.

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

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

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

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |Owner:  nobody
  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:  0
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

 * 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] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |Owner:  nobody
  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: |Has patch:  0
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by emulbreh):

 I could not reproduce the error with adamnelson's example. But I could
 reproduce it with aaron's code. My first patch was completly wrong.
 But the second patch fixes the issue for me with MySQL 5.5.10. Basically,
 we drop all but the first dependency, which causes the bad deletion order.

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

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

Re: [Django] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
   Reporter: |Owner:  nobody
  Rick.van.Hattem@…  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3| Severity:  Normal
 Resolution: | Keywords:  database, postgres,
   Triage Stage:  Accepted   |  postgresql, connection, closed
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-

Comment (by anonymous):

 Although it would be cleaner to only do this in case of an `connection
 already closed` `InterfaceError`. I can't really think of a valid reason
 to keep `self.connection` after trying to close it.

 Either it succeeded or failed, but the odds are that the connection is not
 usable anymore in either case. It shouldn't be much of a problem since the
 exception is re-raised anyway.


 But a clean solution (catching this specific error silently) would be
 preferred indeed.

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

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

[Django]

#14903: wsgiref usage
-+-
   Reporter:  maxbublis  |Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  Core (Other)
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * cc: aymeric.augustin@… (added)


Comment:

 I re-did the job from scratch in order to check if I would end up with the
 same patch. I mostly did :)

 Interesting differences with the original patch are:
 - I updated the module's docstring
 - I kept the customized error_status - the value in the stdlib is
 a bit whacky
 - I kept the customized get_environ() method of WSGIRequestHandler
 - it's fixing a bug
 - I removed the handle() method of WSGIRequestHandler - it's not
 changed

 I compared every line I removed with the source of Python 2.5.5.

 I checked the commit history for django/core/servers/basehttp.py back to
 r174, where the file was first committed. All changes are preserved by the
 patch, except the following:
 - r6780 is lost. However, #6063 was re-opened and the root cause
 was fixed at r6895, making the change in r6780 unecessary. So it is fine.
 - r6634 is lost. However, the definition of format_date_time() in
 wsgiref.handlers is correct. #5816 was actually introduced by a incorrect
 fix in r5712. I think wsgiref.handlers was fixed independently after
 Django forked it.
 - r5511 reverts r5483.
 - r5091 is lost. However, the goal was a "slight performance
 improvement". This does not seem a sufficient reason to keep a forked
 version of a module of the standard library.
 - r3530 was lost by the previous patch, which would have caused a
 regression on #2494. I fixed that in my patch.
 - r3113 was lost by the previous patch, which was probably
 innocuous. I fixed that in my patch.
 - r2809 is the customized error_status mentioned above.

 All tests pass.

 Not marking this as RFC since I modified the patch, but I think it's
 pretty close.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15804: Query lookup types should be scoped to the last joined field's model

[Django]

#15804: Query lookup types should be scoped to the last joined field's model
-+-
   Reporter:  adrian |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  |
-+-
Description changed by adrian:

Old description:

> This is kind of obscure and best described by example. I have two models:
>
> {{{
> from django.db import models
> from django.contrib.gis.db import models as geo_models
>
> # Note this is a geo-aware model.
> class Place(geo_models.Model):
> geom = geo_models.GeometryField()
>
> # Note this is NOT a geo-aware model.
> class Person(models.Model):
> name = models.CharField(max_length=50)
> hometown = models.ForeignKey(Place)
> }}}
>
> I'd like to be able to do this:
>
> {{{
> Person.objects.filter(hometown__geom__intersects=some_geometry)
> }}}
>
> ...but that doesn't work. It gives me this error:
>
> {{{
> django.core.exceptions.FieldError: Join on field 'geom' not permitted.
> Did you misspell 'intersects' for the lookup type?
> }}}
>
> This happens because {{{Person}}} isn't a geo-aware model, so it doesn't
> know that {{{__intersects}}} is a valid lookup type. I can fix it by
> changing {{{Person}}} to extend {{{django.contrib.gis.db.models}}}, but
> that feels hacky because the {{{Person}}} model itself doesn't have any
> geo fields.
>
> The solution could be to change Django's join code so that it looks at
> the model of the last field in the chain when determining whether a
> lookup is valid. I haven't looked into how difficult this would be,
> though. I think it's just enough of an edge case that it wouldn't be
> worth fixing if it required a ton of refactoring and hoop-jumping. But if
> it's easy, let's do it.

New description:

 This is kind of obscure and best described by example. I have two models:

 {{{
 from django.db import models
 from django.contrib.gis.db import models as geo_models

 # Note this is a geo-aware model.
 class Place(geo_models.Model):
 geom = geo_models.GeometryField()

 # Note this is NOT a geo-aware model.
 class Person(models.Model):
 name = models.CharField(max_length=50)
 hometown = models.ForeignKey(Place)
 }}}

 I'd like to be able to do this:

 {{{
 Person.objects.filter(hometown__geom__intersects=some_geometry)
 }}}

 ...but that doesn't work. It gives me this error:

 {{{
 django.core.exceptions.FieldError: Join on field 'geom' not permitted. Did
 you misspell 'intersects' for the lookup type?
 }}}

 This happens because {{{Person}}} isn't a geo-aware model, so it doesn't
 know that {{{__intersects}}} is a valid lookup type. I can fix it by
 changing {{{Person}}} to extend {{{django.contrib.gis.db.models}}} and
 adding the {{{GeoManager}}}, but that feels hacky because the {{{Person}}}
 model itself doesn't have any geo fields.

 The solution could be to change Django's join code so that it looks at the
 model of the last field in the chain when determining whether a lookup is
 valid. I haven't looked into how difficult this would be, though. I think
 it's just enough of an edge case that it wouldn't be worth fixing if it
 required a ton of refactoring and hoop-jumping. But if it's easy, let's do
 it.

--

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

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

Re: [Django] #3011: Allow for extendable auth_user module

[Django]

#3011: Allow for extendable auth_user module
-+
   Reporter:  nowell strite  |Owner:  seocam
   Type:  New feature|   Status:  assigned
  Milestone: |Component:  contrib.auth
Version: | Severity:  Normal
 Resolution: | Keywords:  auth_user
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  1  |
-+

Comment (by Kronuz):

 I found the current patch produces a bug if used alongside the
 `contrib.admin` app under certain circumstances when the new User model
 has foreign key fields with lazy relations to other app models. This
 problem arises since those models are still unresolved when django later
 attempts to import the `INSTALLED_APP` modules, while fetching the locales
 during the creation of the languages translation object, at that point,
 while importing the `admin` app, `contrib/admin/__init__.py` tries to
 import `contrib.admin.sites`, which results in the importing of
 `AuthenticationForm`... `__new__()` then tries to use` formfield()` on the
 User's available fields for the User model, but since those foreign key
 fields still contain unresolved strings, it throws an exception
 (`AttributeError: 'str' object has no attribute '_default_manager'`). I'm
 attaching a new patch which fixes this issue.

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

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

[Changeset] r16025 - django/trunk/django/db/models/sql

[noreply]

Author: adrian
Date: 2011-04-11 14:48:47 -0700 (Mon, 11 Apr 2011)
New Revision: 16025

Modified:
   django/trunk/django/db/models/sql/query.py
Log:
Made some negligible docstring fixes while I was poking around in the depths of 
query.py

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2011-04-11 20:27:53 UTC (rev 
16024)
+++ django/trunk/django/db/models/sql/query.py  2011-04-11 21:48:47 UTC (rev 
16025)
@@ -1406,13 +1406,13 @@
 the final join is against the same column as we are comparing against,
 and is an inner join, we can go back one step in a join chain and
 compare against the LHS of the join instead (and then repeat the
-optimization). The result, potentially, involves less table joins.
+optimization). The result, potentially, involves fewer table joins.
 
 The 'target' parameter is the final field being joined to, 'join_list'
 is the full list of join aliases.
 
 The 'last' list contains offsets into 'join_list', corresponding to
-each component of the filter.  Many-to-many relations, for example, add
+each component of the filter. Many-to-many relations, for example, add
 two tables to the join list and we want to deal with both tables the
 same way, so 'last' has an entry for the first of the two tables and
 then the table immediately after the second table, in that case.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15804: Query lookup types should be scoped to the last joined field's model

[Django]

#15804: Query lookup types should be scoped to the last joined field's model
-+-
   Reporter:  adrian |Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database
Version:  1.3|  layer (models, ORM)
   Keywords: | Severity:  Normal
  Has patch:  0  | Triage Stage:  Design
Needs tests:  0  |  decision needed
 |  Needs documentation:  0
 |  Patch needs improvement:  0
-+-
 This is kind of obscure and best described by example. I have two models:

 {{{
 from django.db import models
 from django.contrib.gis.db import models as geo_models

 # Note this is a geo-aware model.
 class Place(geo_models.Model):
 geom = geo_models.GeometryField()

 # Note this is NOT a geo-aware model.
 class Person(models.Model):
 name = models.CharField(max_length=50)
 hometown = models.ForeignKey(Place)
 }}}

 I'd like to be able to do this:

 {{{
 Person.objects.filter(hometown__geom__intersects=some_geometry)
 }}}

 ...but that doesn't work. It gives me this error:

 {{{
 django.core.exceptions.FieldError: Join on field 'geom' not permitted. Did
 you misspell 'intersects' for the lookup type?
 }}}

 This happens because {{{Person}}} isn't a geo-aware model, so it doesn't
 know that {{{__intersects}}} is a valid lookup type. I can fix it by
 changing {{{Person}}} to extend {{{django.contrib.gis.db.models}}}, but
 that feels hacky because the {{{Person}}} model itself doesn't have any
 geo fields.

 The solution could be to change Django's join code so that it looks at the
 model of the last field in the chain when determining whether a lookup is
 valid. I haven't looked into how difficult this would be, though. I think
 it's just enough of an edge case that it wouldn't be worth fixing if it
 required a ton of refactoring and hoop-jumping. But if it's easy, let's do
 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.

[Django] #15803: A slug on form fields like 'select' 'input' or 'checkbox'

[Django]

#15803: A slug on form fields like 'select' 'input' or 'checkbox'
+---
 Reporter:  whalesalad  | Owner:  nobody
 Type:  New feature |Status:  new
Milestone:  | Component:  Forms
  Version:  |  Severity:  Normal
 Keywords:  forms fields widgets slugs  |  Triage Stage:  Unreviewed
Has patch:  0   |
+---
 I'd love to have a slug on form fields so that inside of templates I can
 do things like, "if this is a checkbox, use this markup, otherwise use
 this other markup". Something like "{% ifequal field.type 'checkbox' %}"
 would be dandy. This might already exist in an alternate form, but I can't
 seem to figure it out.

 This is just a feature request... I hope that submitting something like
 this on Trac isn't out of line.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
   Reporter: |Owner:  nobody
  Rick.van.Hattem@…  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3| Severity:  Normal
 Resolution: | Keywords:  database, postgres,
   Triage Stage:  Accepted   |  postgresql, connection, closed
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-

Comment (by Alex):

 Relevant:
 
http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/dialects/postgresql/psycopg2.py#L310

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

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

[noreply]

Author: adrian
Date: 2011-04-11 13:27:53 -0700 (Mon, 11 Apr 2011)
New Revision: 16024

Modified:
   django/trunk/django/db/models/query.py
Log:
Fixed incorrect usage of its in query.py docstring

Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2011-04-09 18:47:59 UTC (rev 
16023)
+++ django/trunk/django/db/models/query.py  2011-04-11 20:27:53 UTC (rev 
16024)
@@ -712,7 +712,7 @@
 
 def using(self, alias):
 """
-Selects which database this QuerySet should excecute it's query 
against.
+Selects which database this QuerySet should excecute its query against.
 """
 clone = self._clone()
 clone._db = alias

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
   Reporter: |Owner:  nobody
  Rick.van.Hattem@…  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3| Severity:  Normal
 Resolution: | Keywords:  database, postgres,
   Triage Stage:  Accepted   |  postgresql, connection, closed
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by Alex):

 * 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] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
   Reporter: |Owner:  nobody
  Rick.van.Hattem@…  |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3| Severity:  Normal
 Resolution: | Keywords:  database, postgres,
   Triage Stage: |  postgresql, connection, closed
  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by Alex):

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


Comment:

 Well it should really only do this in the case that the InterfaceError is
 a "connection already closed" one, I remember seeing Mike Bayer bitching
 that there was no programmatic way to do it, so perhaps we should steal
 the hack he ended up using from him.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
 Reporter:  Rick.van.Hattem@…| Owner:  nobody
 Type:  Bug  |Status:  new
Milestone:   | Component:  Database layer
  Version:  1.3  |  (models, ORM)
 Keywords:  database, postgres,  |  Severity:  Normal
  postgresql, connection, closed |  Triage Stage:  Unreviewed
Has patch:  0|
-+-
 In some cases (database restart, network connection lost, hard pgBouncer
 restart, etc...) the connection to the database is lost without giving
 Django a notification.

 Currently Django doesn't handle that very gracefully... it just keeps
 trying to close an already closed connection (and gets errors because of
 that) so after you've somehow lost your database connection for a bit you
 have to restart all of your mod_wsgi processes (means executing a reload
 command on 5 servers for me right now) before Django starts working again.

 The stacktrace:
 {{{#!python
 Traceback (most recent call last):
   File "django/core/handlers/wsgi.py", line 267, in
 __call__
 signals.request_finished.send(sender=self.__class__)
   File "django/dispatch/dispatcher.py", line 162, in send
 response = receiver(signal=self, sender=sender, **named)
   File "django/db/__init__.py", line 84, in
 close_connection
 conn.close()
   File "django/db/backends/__init__.py", line 72, in
 close
 self.connection.close()
 InterfaceError: connection already closed

 }}}

 Proposed patch, replace the `close()` method in
 `django/db/backends/__init__.py` so it becomes this:
 {{{#!python
 def close(self):
 if self.connection is not None:
 try:
 self.connection.close()
 self.connection = None
 except InterfaceError:
 self.connection = None
 raise
 }}}

 I see no valid reason for giving a non-recoverable error while closing the
 database connection. Yes, something is wrong and yes, the exception can be
 shown. But looping the error is completely futile here.

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

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

Re: [Django] #15801: Logging docs: Incorrect external link for dictConfig

[Django]

#15801: Logging docs: Incorrect external link for dictConfig
-+-
   Reporter:  David  |Owner:  nobody
  Niergarth    |   Status:  new
   Type:  Bug|Component:  Documentation
  Milestone: | Severity:  Normal
Version:  1.2| Keywords:
 Resolution: |Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by David Niergarth ):

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


Comment:

 The same problem exists here as well:

 http://docs.djangoproject.com/en/dev/ref/settings/#std:setting-
 LOGGING_CONFIG

 The "dictConfig" link should point to

 http://docs.python.org/library/logging.config.html#configuration-
 dictionary-schema

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #11580: Unable to query TextField against oracle nclob 10Gr4

[Django]

#11580: Unable to query TextField against oracle nclob 10Gr4
-+-
   Reporter: |Owner:  nobody
  nosrednakram   |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version: | Severity:  Normal
  1.1-beta-1 | Keywords:  oracle TextField
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by morgy.wahl@…):

 Thanks. Those return:

 NLS_CHARACTERSET  WE8MSWIN1252

 NLS_NCHAR_CHARACTERSET   AL16UTF16

 and:

 Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit
 Production

 So it seems my NCLOBs are indeed UTF-16, which confirms the 4000-byte
 limit. And, on Oracle 11g at least, just removing the call to
 DBMS_LOB.SUBSTR works.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15801: Logging docs: Incorrect external link for dictConfig

[Django]

#15801: Logging docs: Incorrect external link for dictConfig
+--
 Reporter:  David Niergarth   | Owner:  nobody
 Type:  Bug |Status:  new
Milestone:  | Component:  Documentation
  Version:  1.2 |  Severity:  Normal
 Keywords:  |  Triage Stage:  Unreviewed
Has patch:  0   |
+--
 On http://docs.djangoproject.com/en/dev/topics/logging/, the link for
 "dictConfig format" points to

 http://docs.python.org/library/logging.html#configuration-dictionary-
 schema

 but that link should instead be

 http://docs.python.org/library/logging.config.html#configuration-
 dictionary-schema

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #11580: Unable to query TextField against oracle nclob 10Gr4

[Django]

#11580: Unable to query TextField against oracle nclob 10Gr4
-+-
   Reporter: |Owner:  nobody
  nosrednakram   |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version: | Severity:  Normal
  1.1-beta-1 | Keywords:  oracle TextField
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by ikelly):

 Replying to [comment:5 morgy.wahl@…]:
 > I have the same problem here. In tests (which may be dependent on my
 data), I didn't get the error for substring lengths of 2000 or less, but
 did for 2001 and greater. I'm not the DBA so I'm not sure how CLOBs are
 encoded, but UTF-16 with a 4000-byte limit would make sense, since all the
 text I'm storing is in the ASCII set (and thus would be 2 bytes per
 character in UTF-16). I'm not sure what Oracle version I'm using. (how can
 I find out?)

 This query will show you your database character set (CLOBs) and your
 national character set (NCLOBs):

 {{{SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER IN
 ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');}}}

 This query will show you the database version:

 {{{SELECT * FROM V$VERSION;}}}

 > I tried removing the call to SUBSTR all together, and it worked fine (at
 least, with __icontains).

 Interesting, according to the docs it appears that LIKE is actually
 supported for CLOBs, although = and <> are not.  That will be very useful
 in fixing 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] #15776: Delete Regression in Django 1.3

[Django]

#15776: Delete Regression in Django 1.3
-+-
   Reporter: |Owner:  nobody
  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: |Has patch:  0
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by adamnelson):

 I have the same problem with a much simpler model structure in Django 1.3
 and MySQL 5.1/5.5 (I tried both):


 {{{
 class Tag(models.Model):
 name = models.CharField(max_length=150, unique=True)
 order = models.PositiveSmallIntegerField(default=0)
 score = models.PositiveSmallIntegerField(default=0)
 slug = models.SlugField(unique=True)

 class TagCombo(models.Model):
 tag = models.ForeignKey('tag.Tag')


 tag = Tag.objects.get(id=1234)
 tag.delete()

 }}}

 Exception:

 {{{


 Traceback (most recent call last):
   File "", line 1, in 
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/django/db/models/base.py", line 581, in delete
 collector.delete()
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/django/db/models/deletion.py", line 63, in decorated
 func(self, *args, **kwargs)
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/django/db/models/deletion.py", line 254, in delete
 query.delete_batch(pk_list, self.using)
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/django/db/models/sql/subqueries.py", line 44, in delete_batch
 self.do_query(self.model._meta.db_table, where, using=using)
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/django/db/models/sql/subqueries.py", line 29, in do_query
 self.get_compiler(using).execute_sql(None)
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 735, in execute_sql
 cursor.execute(sql, params)
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/django/db/backends/util.py", line 34, in execute
 return self.cursor.execute(sql, params)
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/django/db/backends/mysql/base.py", line 86, in execute
 return self.cursor.execute(query, args)
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/MySQLdb/cursors.py", line 174, in execute
 self.errorhandler(self, exc, value)
   File "/Users/adam/Development/example-env/lib/python2.7/site-
 packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
 raise errorclass, errorvalue
 IntegrityError: (1451, 'Cannot delete or update a parent row: a foreign
 key constraint fails (`example_local`.`tag_tagcombo`, CONSTRAINT
 `tag_id_refs_id_39193e2d9b20ff37` FOREIGN KEY (`tag_id`) REFERENCES
 `tag_tag` (`id`))')

 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #11580: Unable to query TextField against oracle nclob 10Gr4

[Django]

#11580: Unable to query TextField against oracle nclob 10Gr4
-+-
   Reporter: |Owner:  nobody
  nosrednakram   |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version: | Severity:  Normal
  1.1-beta-1 | Keywords:  oracle TextField
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by morgy.wahl@…):

 I have the same problem here. In tests (which may be dependent on my
 data), I didn't get the error for substring lengths of 2000 or less, but
 did for 2001 and greater. I'm not the DBA so I'm not sure how CLOBs are
 encoded, but UTF-16 with a 4000-byte limit would make sense, since all the
 text I'm storing is in the ASCII set (and thus would be 2 bytes per
 character in UTF-16). I'm not sure what Oracle version I'm using. (how can
 I find out?)

 I tried removing the call to SUBSTR all together, and it worked fine (at
 least, with __icontains).

 FYI the Oracle docs seem to indicate DBMS_LOB.SUBSTR defaults to an offset
 of 1 and a length of 32767 (i.e. 2^15^ - 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] #15797: *_COOKIE_DOMAIN settings should reject values that won't work in modern browsers

[Django]

#15797: *_COOKIE_DOMAIN settings should reject values that won't work in modern
browsers
--+
   Reporter:  estebistec  |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  Core (Other)
Version:  1.3 | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  1   |
--+
Changes (by estebistec):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #15797: *_COOKIE_DOMAIN settings should reject values that won't work in modern browsers

[Django]

#15797: *_COOKIE_DOMAIN settings should reject values that won't work in modern
browsers
--+
   Reporter:  estebistec  |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  Core (Other)
Version:  1.3 | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+

Comment (by estebistec):

 I need to fix this patch (probably do it tonight). I failed to consider
 the case where you really only want to support a naked domain, e.g.,
 example.com. This cookie domain would be valid and simply wouldn't match
 any sub-domains at all. So the new condition will be: starts with a dot
 and has 2+, or doesn't and has at least one.

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

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

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |Owner:  jkocherhans
  Honza_Kral |   Status:  assigned
   Type:  New|Component:  contrib.admin
  feature| Severity:  Normal
  Milestone: | Keywords:  nfa-someday
Version:  SVN|  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  0  |
-+-

Comment (by julien):

 One more thing, `SimpleFilterSpec` also automatically adds "All" as the
 fist, default option for the custom filter.

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

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

[Django]

#14608: Adding a INPhoneNumberField to indian localflavor
---+---
   Reporter:  lawgon   |Owner:  lawgon
   Type:  New feature  |   Status:  reopened
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  india phone
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  1|
---+---

Comment (by lawgon):

 I now tried with a simple re containing the '\d' repeated 85 times (this
 makes it the same length of my re). The tests accept it. So it must lie in
 the complexity.

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

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

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |Owner:  jkocherhans
  Honza_Kral |   Status:  assigned
   Type:  New|Component:  contrib.admin
  feature| Severity:  Normal
  Milestone: | Keywords:  nfa-someday
Version:  SVN|  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  1  |  Needs tests:  1
Patch needs improvement:  0  |
-+-

Comment (by julien):

 OK, so I've tweaked the patch some more and tried to come up with an API
 that's (hopefully) simple and easy to use, introducing a new
 `SimpleFilterSpec` class. Here's an example:

 {{{
 #!python

 # The model
 class Person(models.Model):
 name = models.CharField(max_length=100)
 age = models.PositiveIntegerField()


 from django.contrib.admin.filterspecs import SimpleFilterSpec

 # The custom filter spec
 class AgeCategoryFilterSpec(SimpleFilterSpec):

 def get_title(self):
 return u'age category'

 def get_choices(self, request):
 return (
 (u'0-19', u'0 to 19'),
 (u'20-39', u'20 to 39'),
 (u'40-over', u'40 and over'),
 )

 def get_query_set(self, cls, qs):
 age_category = self.get_value()
 if age_category == u'0-19':
 return qs.filter(age__gte=0, age__lte=19)
 if age_category == u'20-39':
 return qs.filter(age__gte=20, age__lte=39)
 if age_category == u'40-over':
 return qs.filter(age__gte=40)
 return qs

 # The admin
 class PersonAdmin(admin.ModelAdmin):
 list_display = ('name', 'age')
 list_filter = ('age', AgeCategoryFilterSpec,)
 }}}

 `SimpleFilterSpec` does all the boring work for you, i.e. yielding the
 iterator items when rendering the template, managing the query string both
 in and out, and fetching the requested value. All you need to provide is
 the title and the choices, and then you can filter the queryset based on
 the requested value. The lookup parameter defaults to the title slugified
 (i.e. "age-category" with the example above), although you can customise
 it by overriding the `get_lookup_parameter()` hook.

 I think this API would cover the majority of use cases. If you want
 something more eccentric then you can always directly extend the
 `FilterSpec` class.

 It's all implemented in the attached patch, including tests for this new
 feature.

 Also, here are some notable changes I've made:

 * I've renamed the `choices()` method to `_choices()` as I think it feels
 more like internal API, and also to avoid users mistakingly overriding it
 instead of the proposed new official `get_choices()` method.
 * The name of  the `title()` method didn't feel right so I've renamed it
 `get_title()`. Hopefully this is isn't considered backwards-incompatible
 (it's easily reversible if so).

 So that's it. At this stage I'd really like to get some feedback both on
 the API and on the implementation approach, so please let me know what you
 think. If people like it then I'll write more tests and get started with
 the doc.

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

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

Re: [Django] #14608: Adding a INPhoneNumberField to indian localflavor

[Django]

#14608: Adding a INPhoneNumberField to indian localflavor
---+---
   Reporter:  lawgon   |Owner:  lawgon
   Type:  New feature  |   Status:  reopened
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  india phone
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  1|
---+---

Comment (by lawgon):

 I am unable to fix this. Import of INPhoneNumberField into a form works as
 advertised. I also tried with a single line re (without VERBOSE) but the
 same re error comes up in the tests. Finally I tried with a very simple re
 - r'\d*'. This works. My conclusion is that in testing, an re beyond a
 certain length (or maybe beyond a certain level of complexity) will cause
 a syntax error although the same works in django itself. This is beyond my
 competence to correct. Should I file 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.

[Django] #15800: Documentation error for django.views.generic.forms.FormMixin

[Django]

#15800: Documentation error for django.views.generic.forms.FormMixin
--+--
 Reporter:  Natim | Owner:  nobody
 Type:  Cleanup/optimization  |Status:  new
Milestone:| Component:  Documentation
  Version:  1.3   |  Severity:  Normal
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+--
 We are still talking about `django.views.generic.forms.FormMixin` but it
 is now `django.views.generic.edit.FormMixin`


 http://docs.djangoproject.com/en/dev/ref/class-based-views/#editing-mixins

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #11595: Fixture validation errors should report their data

[Django]

#11595: Fixture validation errors should report their data
-+-
   Reporter:  freyley|Owner:  raulcd
   Type: |   Status:  assigned
  Cleanup/optimization   |Component:  Core (Serialization)
  Milestone: | Severity:  Normal
Version:  1.0| Keywords:  easy-pickings
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by raulcd):

 @russellm -- I am sorry I misunderstood the documentation. I thought the
 meaning of the ready for chekin was set the ticket as "ey guys, can anyone
 take a look, I did my patch". I will know that for the next one. About the
 tests I executed the full test suite and as no test failed I thought the
 "literal" of the error may not be tested. I will prepare the tests and
 submit the new patch, just a question (as I am new) where do you think is
 the best location to create the tests? In
 /trunk/tests/modeltests/validation or create a new folder with the tests.
 I am sorry for this questions, but as a newbie I want to follow your
 standards.

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

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

[Django]

#15705: Localflavor for Croatia
-+-
   Reporter:  zmasek |Owner:  zmasek
   Type:  New|   Status:  new
  feature|Component:  contrib.localflavor
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  localflavor croatia
 Resolution: |Has patch:  1
   Triage Stage:  Ready for  |  Needs tests:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by zmasek):

 I'm glad I could contribute! Thanks for the tips and all the help, julien.
 :)

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

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

[Django]

#14608: Adding a INPhoneNumberField to indian localflavor
---+---
   Reporter:  lawgon   |Owner:  lawgon
   Type:  New feature  |   Status:  reopened
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  india phone
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  1|
---+---

Comment (by lawgon):

 it fails in 2.6 also. However the unit tests of the re expression pass in
 2.6. I will investigate.

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

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