Re: [Django] #11448: Defining relationships after querying a model does not add a reverse lookup to the referenced model

[Django]

#11448: Defining relationships after querying a model does not add a reverse 
lookup
to the referenced model
-+-
   Reporter:  Dennis |  Owner:  nobody
  Kaarsemaker| Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  1
-+-
Changes (by zuko):

 * easy:  0 => 1


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

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

Re: [Django] #5419: Add a model fuzz testing method to the test framework

[Django]

#5419: Add a model fuzz testing method to the test framework
---+---
   Reporter:  adrian   |  Owner:  kkubasik
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Testing framework
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  feature
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  0|  Easy pickings:  0
---+---

Comment (by anonymous):

 佳き日に、二人に送る[http://www.d-mailer.com/電報 結婚 文例]でお祝いの気持ちを伝える。

-- 
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] #11448: Defining relationships after querying a model does not add a reverse lookup to the referenced model

[Django]

#11448: Defining relationships after querying a model does not add a reverse 
lookup
to the referenced model
-+-
   Reporter:  Dennis |  Owner:  nobody
  Kaarsemaker| Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by zuko):

 * cc: zuko (added)
 * easy:   => 0


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

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

[Changeset] r16127 - django/branches/releases/1.3.X/docs/howto

[noreply]

Author: ramiro
Date: 2011-04-29 19:48:56 -0700 (Fri, 29 Apr 2011)
New Revision: 16127

Modified:
   django/branches/releases/1.3.X/docs/howto/custom-template-tags.txt
Log:
[1.3.X] Fixed small typos in custom template tags docs.

Backport of [16126] from trunk.

Modified: django/branches/releases/1.3.X/docs/howto/custom-template-tags.txt
===
--- django/branches/releases/1.3.X/docs/howto/custom-template-tags.txt  
2011-04-30 02:19:24 UTC (rev 16126)
+++ django/branches/releases/1.3.X/docs/howto/custom-template-tags.txt  
2011-04-30 02:48:56 UTC (rev 16127)
@@ -627,13 +627,13 @@
 Shortcut for simple tags
 
 
-Many template tags take a number of arguments -- strings or a template 
variables
+Many template tags take a number of arguments -- strings or template variables
 -- and return a string after doing some processing based solely on
-the input argument and some external information. For example, the
+the input arguments and some external information. For example, the
 ``current_time`` tag we wrote above is of this variety: we give it a format
 string, it returns the time as a string.
 
-To ease the creation of the types of tags, Django provides a helper function,
+To ease the creation of these types of tags, Django provides a helper function,
 ``simple_tag``. This function, which is a method of
 ``django.template.Library``, takes a function that accepts any number of
 arguments, wraps it in a ``render`` function and the other necessary bits

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

[noreply]

Author: ramiro
Date: 2011-04-29 19:19:24 -0700 (Fri, 29 Apr 2011)
New Revision: 16126

Modified:
   django/trunk/docs/howto/custom-template-tags.txt
Log:
Fixed small typos in custom template tags docs.

Modified: django/trunk/docs/howto/custom-template-tags.txt
===
--- django/trunk/docs/howto/custom-template-tags.txt2011-04-29 15:11:24 UTC 
(rev 16125)
+++ django/trunk/docs/howto/custom-template-tags.txt2011-04-30 02:19:24 UTC 
(rev 16126)
@@ -627,13 +627,13 @@
 Shortcut for simple tags
 
 
-Many template tags take a number of arguments -- strings or a template 
variables
+Many template tags take a number of arguments -- strings or template variables
 -- and return a string after doing some processing based solely on
-the input argument and some external information. For example, the
+the input arguments and some external information. For example, the
 ``current_time`` tag we wrote above is of this variety: we give it a format
 string, it returns the time as a string.
 
-To ease the creation of the types of tags, Django provides a helper function,
+To ease the creation of these types of tags, Django provides a helper function,
 ``simple_tag``. This function, which is a method of
 ``django.template.Library``, takes a function that accepts any number of
 arguments, wraps it in a ``render`` function and the other necessary bits

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15640: New initial digit in Spain phone numbers

[Django]

#15640: New initial digit in Spain phone numbers
-+-
   Reporter:  fenikso|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.localflavor
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  phone digit
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #15933: mysql inspectdb loosing primary_key information

[Django]

#15933: mysql inspectdb loosing primary_key information
-+-
   Reporter:  andi   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by andi):

 * cc: andi (added)
 * 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] #15933: mysql inspectdb loosing primary_key information

[Django]

#15933: mysql inspectdb loosing primary_key information
--+--
 Reporter:  andi  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Database layer (models, ORM)
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
--+--
 I've been inspecting a mysql 4 (4.0.16-standard) database. The resulting
 models file didn't handle all the primary_keys right if the primary key
 column is used in any other key.

 Example table layout:
 {{{
 CREATE TABLE `test` (
   `PrimaryKeyColumn` int(10),
   `AnotherColumn`int(10),
   `SomethingElse`int(10),
   PRIMARY KEY `PrimaryKeyColumn`,
   UNIQUE KEY `AnotherKey` (`PrimaryKeyColumn`,`AnotherColumn`)
 );
 }}}
 The {{{SHOW INDEX FROM %s}}} query would return the following table:
 {{{
 mysql> show index from test;
 
+---+++--+--+---+-+--++--++-+
 | Table | Non_unique | Key_name   | Seq_in_index | Column_name  |
 Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment
 |
 
+---+++--+--+---+-+--++--++-+
 | test  |  0 | PRIMARY|1 | PrimaryKeyColumn | A
 |   0 | NULL | NULL   |  | BTREE  | |
 | test  |  0 | AnotherKey |1 | PrimaryKeyColumn | A
 |NULL | NULL | NULL   |  | BTREE  | |
 | test  |  0 | AnotherKey |2 | AnotherColumn| A
 |NULL | NULL | NULL   | YES  | BTREE  | |
 
+---+++--+--+---+-+--++--++-+
 }}}
 After reading row 2 the primary_key information would be lost.
 To preserve this information i added a check to only update the
 {{{unique}}} field. Patch is attached.

 I had to apply #14618 to use inspectdb with my mysql version.

-- 
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] #15932: related_name='+' ignored in ManyToManyField validation

[Django]

#15932: related_name='+' ignored in ManyToManyField validation
+--
 Reporter:  Fredde  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Database layer (models, ORM)
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  1   |  Easy pickings:  0
+--
 According to the documentation
 
(http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name)
 setting related_name='+' to any relation field should prevent django from
 creating a related field. This also seems to be the case in the
 ''contribute_to_related_class'' functions. However the validation of
 ManyToMany fields ignors this and gives an error message anyway.

 To reproduce:
 {{{
 #!python
 class A(models.Model):
 pass

 class B(models.Model):
 # This works
 fk1 = models.ForeignKey(A, related_name = '+')
 fk2 = models.ForeignKey(A, related_name = '+')

 # This gives a "Accessor for m2m field 'm2m1' clashes with related
 m2m field 'A.+'" error
 m2m1 = models.ManyToManyField(A, related_name = '+')
 m2m2 = models.ManyToManyField(A, related_name = '+')
 }}}

 The attached patch will make the validator check f.rel.is_hidden() before
 doing any further validation of related field names.

-- 
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] #10088: for_share() as well as for_update() addition to Model.QuerySet

[Django]

#10088: for_share() as well as for_update() addition to Model.QuerySet
-+-
   Reporter: |  Owner:
  epandurski | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.0|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 anonymous:

 If you want to see a ticket moved on, there are ways to do it:

  * Bring it up on django-devs if it gets the 'DDN' status, bringing your
 arguments and asking for a decision - this is what the 'contributing to
 Django' docs tell you to do.
  * Implement a clean, tested, documented patch.

 Or even better, do both - come to django-devs with your nice patch,
 proving that you are serious and the feature has a sensible
 implementation.

 With neither of these done, it's difficult to take this complaint
 seriously, at least on this ticket. Are you really expecting someone else
 to do the work for this feature, either in terms of driving for a design
 decision, or implementing it? There are **many** worthy features that
 might be included in Django, and neither the core developers nor the rest
 of the community are making any promises to work on something just because
 it might be a good idea.

 Thanks,

 Luke

-- 
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] #15924: html5 forms input types, attributes

[Django]

#15924: html5 forms input types, attributes
---+--
   Reporter:  roman2k9@…   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Forms
Version:  1.3  |   Severity:  Normal
 Resolution:  invalid  |   Keywords:  forms, html5
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+--
Changes (by lukeplant):

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


Comment:

 This ticket is too broad, and it won't be possible to ever consider it
 fixed.

 Please open separate tickets for any feature you'd like to see. I can see
 a number of tickets here:

  * 'required' attribute
  * placeholder attribute
  * `EmailInput` widget
  * `UrlInput` widget etc.

 Please note that we have a strong backwards compatibility commitment, so
 we won't add new features (or at least have them enabled by default) if
 they break things for older browsers. This is another reason to split this
 ticket into multiple tickets, so the problems with one won't hold up the
 others being added.

 Can I also note that at least some of these are simple, easy new features
 (feel free to add the 'Easy pickings' flag to you new tickets), and such
 things are especially good candidates for **you** to implement. Core
 developers are going to spend their time doing things that other members
 of the community can't do, so nice patches with docs and tests will
 certainly be welcomed, but we are unlikely to write them :-)

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

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

Re: [Django] #15640: New initial digit in Spain phone numbers

[Django]

#15640: New initial digit in Spain phone numbers
+-
   Reporter:  fenikso   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.localflavor
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  phone digit
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+-
Changes (by claudep):

 * needs_better_patch:  1 => 0
 * version:  1.3-rc1 => SVN
 * needs_tests:  1 => 0
 * easy:   => 0


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

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

Re: [Django] #15354: Cookie with CSRF token not always available for AJAX Post requests

[Django]

#15354: Cookie with CSRF token not always available for AJAX Post requests
+--
   Reporter:  sayane|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:  1.3   |  Component:  contrib.csrf
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+--
Changes (by aaugustin):

 * easy:   => 0


Comment:

 #15925 was a duplicate.

-- 
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] #15925: CSRF AJAX section unclear

[Django]

#15925: CSRF AJAX section unclear
---+---
   Reporter:  morgan.harris@…  |  Owner:  nobody
   Type:  Bug  | Status:  closed
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:  duplicate|   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
---+---
Changes (by aaugustin):

 * status:  new => closed
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * resolution:   => duplicate
 * stage:  Unreviewed => Accepted


Comment:

 Pretty much the same issue was reported in #15354.

-- 
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] #15931: Patch for admin change form to dodge multi-db bug

[Django]

#15931: Patch for admin change form to dodge multi-db bug
---+---
 Reporter:  dchandek   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  contrib.admin
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
---+---
 A multi-db bug in django.contrib.contenttypes is triggered via the "View
 on site" link on the admin site change form when the model uses a
 different db from the contenttypes app (see discussion at
 https://groups.google.com/d/topic/django-users/Y50SimNd8zo/discussion and
 related ticket at #15610).  If I follow the logic correctly, there is no
 need to route the "View on site" link through
 django.contrib.contenttypes.views.shortcut b/c the admin view has already
 determined that the model has implemented get_absolute_url, and the
 shortcut view simply repeats the process -- i.e. by a convoluted method
 that gets the object and calls get_absolute_url -- except that it trips
 the aforementioned bug.  While this bug should obviously be fixed, the
 change form can be patched with the attached file.

-- 
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] #15930: middleware.common.py doesn't parse denied_user_agents

[Django]

#15930: middleware.common.py doesn't parse denied_user_agents
--+---
   Reporter:  rickeyski   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  HTTP handling
Version:  1.3 |   Severity:  Normal
 Resolution:  invalid |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---
Changes (by aaugustin):

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


Comment:

 The docs state that `settings.DISALLOWED_USER_AGENTS` must be a "list of
 compiled regular expression objects".

 See http://docs.djangoproject.com/en/dev/ref/settings/#disallowed-user-
 agents

 You have provided a list of strings instead.

 You should write `DISALLOWED_USER_AGENTS = (re.compile(), ...)`

-- 
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] #12595: Localflavor bad arguments handling

[Django]

#12595: Localflavor bad arguments handling
+-
   Reporter:  sayane|  Owner:
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.localflavor
Version:|   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  0
+-
Changes (by claudep):

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


Comment:

 I basically see what's the problem and what to do. Now there is a lot of
 similar changes to make, and I would like to know if I'm going in the
 right direction before giving more time to this.

 See my patch, and tell me if it's OK (and good practice) to pass
 max_length and min_length to super as args (vs kwargs).
 For tests, should I add field_kwargs to all tests, or add a second assert
 with field_kwargs to all tests, or simply add field_kwargs once per test
 case?

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

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

[Django] #15930: middleware.common.py doesn't parse denied_user_agents

[Django]

#15930: middleware.common.py doesn't parse denied_user_agents
---+---
 Reporter:  rickeyski  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  HTTP handling
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
---+---
 I tried to set denied user agents and django raised the error str does not
 have method .search for user_agent_regex.search.  Changing the declaration
 to re.search(user_agent_regex,request.META['user agent']) fixed the
 problem. The diff is attached

-- 
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] #12062: django.contrib.localflavor.cl.CLRutField isn't doing proper validation

[Django]

#12062: django.contrib.localflavor.cl.CLRutField isn't doing proper validation
-+-
   Reporter:  aotarola   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.localflavor
Version: |   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by claudep):

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


Comment:

 Fixed in changeset:15450 (ticket:15175)

-- 
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] #11825: Polish national flavour bugs

[Django]

#11825: Polish national flavour bugs
-+-
   Reporter: |  Owner:  Maksymus007
  Maksymus007| Status:  closed
   Type:  Bug|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  1.1|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by claudep):

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


Comment:

 Empty value validation issue has been fixed in changeset:14949, and I
 think the checksum validation is correct (even tested). Please reopen if
 you can give us a valid PESEL that does not validate.

-- 
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] #11577: PLNIPField validation error when empty

[Django]

#11577: PLNIPField validation error when empty
+-
   Reporter:  amz   |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  contrib.localflavor
Version:  1.0   |   Severity:  Normal
 Resolution:  fixed |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  0
+-
Changes (by claudep):

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


Comment:

 Apparently fixed by changeset:14949

-- 
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] #15610: Generic Foreign Keys break when used with multi-db.

[Django]

#15610: Generic Foreign Keys break when used with multi-db.
-+-
   Reporter:  legutierr  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:
Version:  SVN|  contrib.contenttypes
 Resolution: |   Severity:  Normal
   Triage Stage:  Design |   Keywords:
  decision needed|  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by ramiro):

 * needs_tests:  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] #15923: Validate that IntegerField is a valid Signed value for databases that don't do it themselves.

[Django]

#15923: Validate that IntegerField is a valid Signed value for databases that 
don't
do it themselves.
-+-
   Reporter: |  Owner:  nobody
  foxwhisper | Status:  reopened
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by foxwhisper):

 Usually, when the data you are inserting, isn't supported on the database
 (string truncation), it just issues a Warning exception.

 Personally, I think when this event is encountered, a warning should be
 raised (like the char fields), to say the number has been truncated to the
 highest available.

-- 
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] #15610: Generic Foreign Keys break when used with multi-db.

[Django]

#15610: Generic Foreign Keys break when used with multi-db.
-+-
   Reporter:  legutierr  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:
Version:  SVN|  contrib.contenttypes
 Resolution: |   Severity:  Normal
   Triage Stage:  Design |   Keywords:
  decision needed|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by natalie.stepina@…):

 * has_patch:  0 => 1


Comment:

 See attached django_contenttypes.patch. Worked for us on Django 1.2.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] #10088: for_share() as well as for_update() addition to Model.QuerySet

[Django]

#10088: for_share() as well as for_update() addition to Model.QuerySet
-+-
   Reporter: |  Owner:
  epandurski | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.0|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

 * easy:   => 0


Comment:

 Replying to [comment:2 mtredinnick]:
 > Removing the ''list'' of people in the assigned field.
 >
 > This is fairly orthogonal to `for_update()`. Django isn't meant to
 provide wrappers for every database feature under the sun, so we might not
 do this. Worth thinking about, however.

 I'm finding this to be systemic in the Django community that makes the
 whole use of Django, in my opinion, not worthwhile. I feel like this
 attitude is what draws people away. There's also such a thing as being so
 abstract that it's completely useless and as a result people end up having
 to write .raw() a lot more than often.

 Just a bit of a rant, but I'm really tired of seeing 4+ year old bugs or
 things that sit in the community only to see it get closed as "wontfix" or
 "let's debate about this really small change or issue for ever".

-- 
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] #15754: Сalling _media method many times while getting media value

[Django]

#15754: Сalling _media method many times while getting media value
-+-
   Reporter:  sakkada|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  media_property
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

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

[Changeset] r16125 - django/trunk/docs/topics/http

[noreply]

Author: jezdez
Date: 2011-04-29 08:11:24 -0700 (Fri, 29 Apr 2011)
New Revision: 16125

Modified:
   django/trunk/docs/topics/http/urls.txt
Log:
Fixed minor doc typo.

Modified: django/trunk/docs/topics/http/urls.txt
===
--- django/trunk/docs/topics/http/urls.txt  2011-04-29 15:11:17 UTC (rev 
16124)
+++ django/trunk/docs/topics/http/urls.txt  2011-04-29 15:11:24 UTC (rev 
16125)
@@ -835,7 +835,7 @@
 A lazily evaluated version of `reverse()`_.
 
 It is useful for when you need to use a URL reversal before your project's
-URLConf is loaded. Some common cases where this method is necessary are::
+URLConf is loaded. Some common cases where this method is necessary are:
 
 * providing a reversed URL as the ``url`` attribute of a generic class-based
   view.

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

[noreply]

Author: jezdez
Date: 2011-04-29 08:11:17 -0700 (Fri, 29 Apr 2011)
New Revision: 16124

Modified:
   django/trunk/django/conf/global_settings.py
   django/trunk/django/contrib/comments/feeds.py
   django/trunk/docs/releases/1.4.txt
Log:
Fixed #15920 -- Removed COMMENTS_BANNED_USERS_GROUP setting in favor of the 
established comments app customization. Thanks, Daniel Lindsley.

Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2011-04-29 15:11:08 UTC (rev 
16123)
+++ django/trunk/django/conf/global_settings.py 2011-04-29 15:11:17 UTC (rev 
16124)
@@ -453,10 +453,6 @@
 # 'hasNoProfanities' validator. All of these should be in lowercase.
 PROFANITIES_LIST = ()
 
-# The group ID that designates which users are banned.
-# Set to None if you're not using it.
-COMMENTS_BANNED_USERS_GROUP = None
-
 ##
 # AUTHENTICATION #
 ##

Modified: django/trunk/django/contrib/comments/feeds.py
===
--- django/trunk/django/contrib/comments/feeds.py   2011-04-29 15:11:08 UTC 
(rev 16123)
+++ django/trunk/django/contrib/comments/feeds.py   2011-04-29 15:11:17 UTC 
(rev 16124)
@@ -28,10 +28,6 @@
 is_public = True,
 is_removed = False,
 )
-if getattr(settings, 'COMMENTS_BANNED_USERS_GROUP', None):
-where = ['user_id NOT IN (SELECT user_id FROM auth_user_groups 
WHERE group_id = %s)']
-params = [settings.COMMENTS_BANNED_USERS_GROUP]
-qs = qs.extra(where=where, params=params)
 return qs.order_by('-submit_date')[:40]
 
 def item_pubdate(self, item):

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-04-29 15:11:08 UTC (rev 16123)
+++ django/trunk/docs/releases/1.4.txt  2011-04-29 15:11:17 UTC (rev 16124)
@@ -117,3 +117,45 @@
 immediately raise a 404. Additionally redirects returned by flatpages are now
 permanent (301 status code) to match the behaviour of the
 :class:`~django.middleware.common.CommonMiddleware`.
+
+`COMMENTS_BANNED_USERS_GROUP` setting
+~
+
+Django's :doc:`comments app ` has historically
+supported excluding the comments of a special user group but never documented
+the feature properly and didn't enforce the exclusion in other parts of the
+app, e.g. the template tags. To fix this problem the code was removed from
+the feed class.
+
+If you rely on the feature and want to restore the old behaviour, simply use
+a custom comment model manager to exclude the user group, e.g.::
+
+from django.conf import settings
+from django.contrib.comments.managers import CommentManager
+
+class BanningCommentManager(CommentManager):
+
+def get_query_set(self):
+qs = super(BanningCommentManager, self).get_query_set()
+if getattr(settings, 'COMMENTS_BANNED_USERS_GROUP', None):
+where = ['user_id NOT IN (SELECT user_id FROM auth_user_groups 
WHERE group_id = %s)']
+params = [settings.COMMENTS_BANNED_USERS_GROUP]
+qs = qs.extra(where=where, params=params)
+return qs
+
+Save this model manager in your custom comment app (e.g. in
+``my_comments_app/managers.py``) and add it your
+:ref:`custom comment app model `::
+
+from django.db import models
+from django.contrib.comments.models import Comment
+
+from my_comments_app.managers import BanningCommentManager
+
+class CommentWithTitle(Comment):
+title = models.CharField(max_length=300)
+
+objects = BanningCommentManager()
+
+For more details see the docs about
+:doc:`customizing the comments framework `.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15920: Feeds support 'COMMENTS_BANNED_USERS_GROUP' but the TT does not.

[Django]

#15920: Feeds support 'COMMENTS_BANNED_USERS_GROUP' but the TT does not.
-+-
   Reporter: |  Owner:  nobody
  daniellindsley | Status:  closed
   Type: |  Component:  contrib.comments
  Cleanup/optimization   |   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  1.3|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by jezdez):

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


Comment:

 In [16124]:
 {{{
 #!CommitTicketReference repository="" revision="16124"
 Fixed #15920 -- Removed COMMENTS_BANNED_USERS_GROUP setting in favor of
 the established comments app customization. Thanks, Daniel Lindsley.
 }}}

-- 
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] r16123 - django/trunk/django/conf

[noreply]

Author: jezdez
Date: 2011-04-29 08:11:08 -0700 (Fri, 29 Apr 2011)
New Revision: 16123

Modified:
   django/trunk/django/conf/global_settings.py
Log:
Removed superfluous settings that were forgotten when the comments app was 
refactored.

Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2011-04-29 12:03:02 UTC (rev 
16122)
+++ django/trunk/django/conf/global_settings.py 2011-04-29 15:11:08 UTC (rev 
16123)
@@ -457,18 +457,6 @@
 # Set to None if you're not using it.
 COMMENTS_BANNED_USERS_GROUP = None
 
-# The group ID that designates which users can moderate comments.
-# Set to None if you're not using it.
-COMMENTS_MODERATORS_GROUP = None
-
-# The group ID that designates the users whose comments should be emailed to 
MANAGERS.
-# Set to None if you're not using it.
-COMMENTS_SKETCHY_USERS_GROUP = None
-
-# The system will email MANAGERS the first COMMENTS_FIRST_FEW comments by each
-# user. Set this to 0 if you want to disable it.
-COMMENTS_FIRST_FEW = 0
-
 ##
 # AUTHENTICATION #
 ##

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

[Django]

#4481: Databrowse should use pagination
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * needs_tests:  0 => 1
 * easy:   => 0


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

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

Re: [Django] #5014: manage.py inspect db is not using the new DecimalField

[Django]

#5014: manage.py inspect db is not using the new DecimalField
-+-
   Reporter:  James  |  Owner:  nobody
| Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0


Comment:

 After some more research, I think that this might be due to historically
 reasons. MySQL used to store decimal fields as strings, and the length
 returned was also counting a place for the dot and the sign, hence the +
 2.
 I'm attaching a patch that fixes this peculiarity in MySQL introspection
 file.

-- 
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] #5349: Shouldn't the item_enclosure_url automatically prefixed with the current site?

[Django]

#5349: Shouldn't the item_enclosure_url automatically prefixed with the current
site?
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.syndication
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


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

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

Re: [Django] #5405: Support restructured text in model docstrings

[Django]

#5405: Support restructured text in model docstrings
---+---
   Reporter:  mattmcc  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  nfa-someday
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  0|  Easy pickings:  0
---+---
Changes (by julien):

 * needs_tests:  0 => 1
 * easy:   => 0


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

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

Re: [Django] #5419: Add a model fuzz testing method to the test framework

[Django]

#5419: Add a model fuzz testing method to the test framework
---+---
   Reporter:  adrian   |  Owner:  kkubasik
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Testing framework
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  feature
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  0|  Easy pickings:  0
---+---
Changes (by julien):

 * needs_tests:  0 => 1
 * easy:   => 0


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

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

Re: [Django] #5524: Cleaned form data should not be deleted if other data is invalid.

[Django]

#5524: Cleaned form data should not be deleted if other data is invalid.
---+-
   Reporter:  __hawkeye__  |  Owner:  __hawkeye__
   Type:  Bug  | Status:  assigned
  Milestone:   |  Component:  Forms
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
---+-
Changes (by julien):

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


Comment:

 The tests would need to be rewritten using unittests since this is now
 Django's preferred 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.

Re: [Django] #5568: DROP INDEX subcommand

[Django]

#5568: DROP INDEX subcommand
-+-
   Reporter:  p  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  management sql
   Triage Stage:  Accepted   |  indexes drop index
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by julien):

 * needs_tests:  0 => 1
 * easy:   => 0


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

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

Re: [Django] #5704: Admin popup windows won't close when using application/xhtml as default content type

[Django]

#5704: Admin popup windows won't close when using application/xhtml as default
content type
-+-
   Reporter:  Rob van|  Owner:  nobody
  der Linde| Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * easy:   => 0


Comment:

 #11684 is a dupe.

-- 
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] #11684: dismissAddAnotherPopup fails with XHTML

[Django]

#11684: dismissAddAnotherPopup fails with XHTML
-+---
   Reporter:  rlaager@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.admin
Version:  SVN|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+---
Changes (by julien):

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


Comment:

 This is actually a dupe of #5704.

-- 
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] #5711: serialize doesn't work with extra()

[Django]

#5711: serialize doesn't work with extra()
-+-
   Reporter: |  Owner:  nobody
  valankar@… | Status:  new
   Type:  Bug|  Component:  Core
  Milestone: |  (Serialization)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by julien):

 * needs_tests:  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] #5749: Add field_name as a key on the _html_output dict

[Django]

#5749: Add field_name as a key on the _html_output dict
---+
   Reporter:  SmileyChris  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Forms
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  0|  Easy pickings:  0
---+
Changes (by julien):

 * needs_tests:  0 => 1
 * easy:   => 0


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

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

Re: [Django] #15610: Generic Foreign Keys break when used with multi-db.

[Django]

#15610: Generic Foreign Keys break when used with multi-db.
-+-
   Reporter:  legutierr  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:
Version:  SVN|  contrib.contenttypes
 Resolution: |   Severity:  Normal
   Triage Stage:  Design |   Keywords:
  decision needed|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by django@…):

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


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

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

Re: [Django] #5831: Template Debug highlights wrong {% for %} tag

[Django]

#5831: Template Debug highlights wrong {% for %} tag
-+-
   Reporter:  Charmless  |  Owner:  charmless
   | Status:  reopened
   Type:  Bug|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  debug for toplevel
 Resolution: |  nesting
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by julien):

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


Comment:

 Confirming that this issue is still occurring. Needs tests to take this
 further. The patch also needs improvement as the `ForNode`'s code has
 changed since 4 years ago.

-- 
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] #5865: cycle template tag should accept a single argument

[Django]

#5865: cycle template tag should accept a single argument
-+-
   Reporter:  gwilson|  Owner:  munhitsu
   Type:  New| Status:  reopened
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * easy:   => 0
 * stage:  Accepted => Design decision needed


Comment:

 A design decision hasn't been reached yet.

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

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

[Django] #15929: test.client.RequestFactory keeps state

[Django]

#15929: test.client.RequestFactory keeps state
--+---
 Reporter:  m.vantellingen@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Testing framework
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
--+---
 See the attached testcase. When a unittest calls self.client.get() once
 all futher calls to RequestFactory.get() result in different request
 objects (the user and session are available).

-- 
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] #5931: __repr__ for db Fields

[Django]

#5931: __repr__ for db Fields
-+-
   Reporter:  Thomas |  Owner:  nobody
  Güttler  | Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  1  |
-+-
Changes (by julien):

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


Comment:

 This looks great but it'd be even better if the tests also covered the
 0.001% of use cases (i.e. when the field does not have a name)  :-)

-- 
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] #5968: Registering/Unregistering multiple models fails

[Django]

#5968: Registering/Unregistering multiple models fails
-+-
   Reporter:  anderso|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * needs_tests:  0 => 1
 * easy:   => 0


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

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

Re: [Django] #6011: manage.py flush command not working as advertised

[Django]

#6011: manage.py flush command not working as advertised
-+-
   Reporter:  Collin |  Owner:  nobody
  Grady| Status:  new
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by julien):

 * easy:   => 0


Comment:

 Simply replaced the help text with the one that's in 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] #5014: manage.py inspect db is not using the new DecimalField

[Django]

#5014: manage.py inspect db is not using the new DecimalField
-+-
   Reporter:  James  |  Owner:  nobody
| Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by claudep):

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


Comment:

 I added a patch which adds guessed max_digits and decimal_places for
 SQLite (with a notice) because decimal fields in SQLite are simply mapped
 as real (float) type. This way, the output of inspectdb is valid.

 The problem with the current patch is that it doesn't pass with MySQL.
 Strangely, my version of mysqldb (1.2.2-10+b1) is always returning the
 value + 2 in cursor.description[4] (precision). Is this a known mysqldb
 bug?

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

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

Re: [Django] #6170: Reverse urlresolver raises obscure exceptions on failure

[Django]

#6170: Reverse urlresolver raises obscure exceptions on failure
-+-
   Reporter: |  Owner:  nobody
  abrahamson.j@… | Status:  new
   Type:  Bug|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  reverse urls
 Resolution: |  exception 'unbalanced parenthesis'
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by julien):

 * needs_tests:  0 => 1
 * easy:   => 0


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

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

Re: [Django] #6173: Cache middleware should cache HEAD requests

[Django]

#6173: Cache middleware should cache HEAD requests
-+-
   Reporter: |  Owner:  arien
  eratothene | Status:  closed
   Type:  New|  Component:  Core (Cache system)
  feature|   Severity:  Normal
  Milestone: |   Keywords:  http
Version:  SVN|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 3 years later, this is no longer relevant as `CacheMiddleware` does not
 discriminate between request methods any more.

-- 
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] #15917: Logging dictionary config works wrong at least with SMTPHandler

[Django]

#15917: Logging dictionary config works wrong at least with SMTPHandler
--+--
   Reporter:  albenik |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  Core (Other)
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+--
Changes (by albenik):

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


Comment:

 test.py (in attachment) fails with next configuration

 {{{#!python
 LOGGING = {
 'version': 1,
 'disable_existing_loggers' : True,

 'handlers': {
 'mail': {
 'level': 'DEBUG',
 'class':'logging.handlers.SMTPHandler',
 'mailhost': ('mailhost.test', 321),
 'fromaddr': 'testu...@domain.com',
 'toaddrs': ['testu...@domain.com',],
 'subject': 'Test email',
 'credentials': ('testuser1', 'testpassword1',),
 },
 },

 'loggers': {
 'test.logger': {
 'level': 'DEBUG',
 'handlers': ['mail',],
 'propagate': False,
 },

 },
 }
 }}}

-- 
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] #15856: Add a localflavor for Macedonia

[Django]

#15856: Add a localflavor for Macedonia
-+-
   Reporter: |  Owner:  nobody
  vasiliyeah | Status:  new
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-

Comment (by vasiliyeah):

 OK, got it. I removed the prefix and updated the code and docs
 accordingly. The reason they were prefixed is that the codes are HASC
 codes and those are hierarchical and prefixed wit the country code. But, I
 can't see a scenario where a conflict could arise if they are not.

-- 
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] #6543: serving files/iterated content with setting.USE_ETAGS = True

[Django]

#6543: serving files/iterated content with setting.USE_ETAGS = True
-+-
   Reporter:  pcicman|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  USE_ETAGS etag file
   Triage Stage:  Accepted   |  zip md5 iterator
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by julien):

 * easy:   => 0
 * severity:   => Normal
 * needs_tests:  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] #6580: Default argument to `getlist` on QueryDict

[Django]

#6580: Default argument to `getlist` on QueryDict
---+---
   Reporter:  dcramer  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  HTTP handling
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  1
---+---
Changes (by julien):

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


Comment:

 This looks great but it'd be even better if all the doctests in
 `MultiValueDict` were rewritten using unittests as it's now Django's
 preferred 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.

Re: [Django] #13648: '%s' escaping support for sqlite3

[Django]

#13648: '%s' escaping support for sqlite3
-+-
   Reporter:  master |  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  sqlite escape
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  1  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * easy:   => 0


Comment:

 #15927 was a duplicate.

-- 
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] #15928: RegexField and regexp flags

[Django]

#15928: RegexField and regexp flags
-+-
   Reporter:  Sergey N.  |  Owner:  nobody
  Belinsky   | Status:  closed
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  RegexField unicode
Version:  1.3|  re.compile
 Resolution:  wontfix|  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

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


Comment:

 Yes, you are right! I agree with you. Your examples are better. The extra
 parameter isn't need. Thank you!
 I will close the ticket.

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

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

Re: [Django] #15927: FORMAT_QMARK_REGEX in sqlite backend does not work as expected

[Django]

#15927: FORMAT_QMARK_REGEX in sqlite backend does not work as expected
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.3-rc1|  (models, ORM)
 Resolution:  duplicate  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by aaugustin):

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


Comment:

 It's actually a duplicate of #15155 and #13648.

-- 
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] #15768: The setUp() method FileStorageTests in tests/regressiontests/file_storage/tests.py uses tempfile.mktemp()

[Django]

#15768: The setUp() method FileStorageTests in
tests/regressiontests/file_storage/tests.py uses tempfile.mktemp()
-+-
   Reporter:  d1b|  Owner:  elbarto
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Uncategorized
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by elbarto):

 * owner:  nobody => elbarto
 * needs_docs:   => 0
 * needs_tests:   => 0
 * easy:   => 0
 * needs_better_patch:   => 0


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

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

Re: [Django] #15927: FORMAT_QMARK_REGEX in sqlite backend does not work as expected

[Django]

#15927: FORMAT_QMARK_REGEX in sqlite backend does not work as expected
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3-rc1|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by aaugustin):

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


Comment:

 Indeed, the current regex `r'(?![^%])%s'` is equivalent to `r'%s'`. The
 first part `r'(?![^%])'` will match if and only if it is not followed by
 `r'[^%]'`, which is equivalent to being followed by `%`. This is always
 true since `%` is the next character in the regex.

 This is much clearer with an example; I'm attaching a failing test case.

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

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

Re: [Django] #15926: Option to not load initial fixtures during syncdb

[Django]

#15926: Option to not load initial fixtures during syncdb
-+-
   Reporter: |  Owner:  msiedlarek
  msiedlarek | Status:  new
   Type:  New|  Component:  Core (Management
  feature|  commands)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  management syncdb
 Resolution: |  options fixtures
   Triage Stage: |  Has patch:  1
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by msiedlarek):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * 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] #15928: RegexField and regexp flags

[Django]

#15928: RegexField and regexp flags
-+-
   Reporter:  Sergey N.  |  Owner:  nobody
  Belinsky   | Status:  new
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  RegexField unicode
Version:  1.3|  re.compile
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

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


Comment:

 Based on the docs, `RegexField.regex` is a "regular expression specified
 either as a string or a compiled regular expression object.".

 Your example could be written like this:
 {{{
 login = RegexField(re.compile(r'^\w+', flags=re.UNICODE|re.IGNORE))
 }}}
 And also like this—it's slightly shorter but less readable:
 {{{
 login = RegexField(r'(?ui)^\w+')
 }}}

 IMO this is sufficient and it's not necessary to add a `flags` parameter
 to `RegexField`, but others may feel differently. I'll mark the ticket as
 DDN.

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

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

Re: [Django] #5925: Unable to use urlresolvers (url, reverse ) feature in redirect argument of decorator user_passes_test

[Django]

#5925: Unable to use urlresolvers (url,reverse ) feature in redirect argument of
decorator user_passes_test
-+-
   Reporter:  anonymous  |  Owner:  SmileyChris
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone:  1.3|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  
urlresolver,reverse,decorator,url,permalink
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by jezdez):

 In [16122]:
 {{{
 #!CommitTicketReference repository="" revision="16122"
 Added file forgotten in r16121. Refs #5925. Thanks, 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.

[Changeset] r16122 - django/trunk/tests/regressiontests/urlpatterns_reverse

[noreply]

Author: jezdez
Date: 2011-04-29 05:03:02 -0700 (Fri, 29 Apr 2011)
New Revision: 16122

Added:
   django/trunk/tests/regressiontests/urlpatterns_reverse/reverse_lazy_urls.py
Log:
Added file forgotten in r16121. Refs #5925. Thanks, Julien.

Added: 
django/trunk/tests/regressiontests/urlpatterns_reverse/reverse_lazy_urls.py
===
--- django/trunk/tests/regressiontests/urlpatterns_reverse/reverse_lazy_urls.py 
(rev 0)
+++ django/trunk/tests/regressiontests/urlpatterns_reverse/reverse_lazy_urls.py 
2011-04-29 12:03:02 UTC (rev 16122)
@@ -0,0 +1,10 @@
+from django.conf.urls.defaults import *
+
+from views import empty_view, LazyRedictView, login_required_view
+
+urlpatterns = patterns('',
+url(r'^redirected_to/$', empty_view, name='named-lazy-url-redirected-to'),
+url(r'^login/$', empty_view, name='some-login-page'),
+url(r'^login_required_view/$', login_required_view),
+url(r'^redirect/$', LazyRedictView.as_view()),
+)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16121 - in django/trunk: django/core docs/releases docs/topics/http tests/regressiontests/urlpatterns_reverse

[noreply]

Author: jezdez
Date: 2011-04-29 04:49:59 -0700 (Fri, 29 Apr 2011)
New Revision: 16121

Modified:
   django/trunk/django/core/urlresolvers.py
   django/trunk/docs/releases/1.4.txt
   django/trunk/docs/topics/http/urls.txt
   django/trunk/tests/regressiontests/urlpatterns_reverse/tests.py
   django/trunk/tests/regressiontests/urlpatterns_reverse/views.py
Log:
Fixed #5925 -- Added new lazily evaluated version of 
django.core.urlresolvers.reverse. Thanks, SmileyChris, Preston Timmons and 
Julien Phalip.

Modified: django/trunk/django/core/urlresolvers.py
===
--- django/trunk/django/core/urlresolvers.py2011-04-28 14:54:09 UTC (rev 
16120)
+++ django/trunk/django/core/urlresolvers.py2011-04-29 11:49:59 UTC (rev 
16121)
@@ -15,7 +15,7 @@
 from django.core.exceptions import ImproperlyConfigured, ViewDoesNotExist
 from django.utils.datastructures import MultiValueDict
 from django.utils.encoding import iri_to_uri, force_unicode, smart_str
-from django.utils.functional import memoize
+from django.utils.functional import memoize, lazy
 from django.utils.importlib import import_module
 from django.utils.regex_helper import normalize
 
@@ -390,6 +390,8 @@
 return iri_to_uri(u'%s%s' % (prefix, resolver.reverse(view,
 *args, **kwargs)))
 
+reverse_lazy = lazy(reverse, str)
+
 def clear_url_caches():
 global _resolver_cache
 global _callable_cache

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-04-28 14:54:09 UTC (rev 16120)
+++ django/trunk/docs/releases/1.4.txt  2011-04-29 11:49:59 UTC (rev 16121)
@@ -37,6 +37,12 @@
 features you need in admin pages without having to lose HTML validity or
 override the provided templates to change the doctype.
 
+``reverse_lazy``
+
+
+A lazily evaluated version of :func:`django.core.urlresolvers.reverse` was
+added to allow using URL reversals before the project's URLConf gets loaded.
+
 .. _backwards-incompatible-changes-1.4:
 
 Backwards incompatible changes in 1.4

Modified: django/trunk/docs/topics/http/urls.txt
===
--- django/trunk/docs/topics/http/urls.txt  2011-04-28 14:54:09 UTC (rev 
16120)
+++ django/trunk/docs/topics/http/urls.txt  2011-04-29 11:49:59 UTC (rev 
16121)
@@ -827,6 +827,26 @@
 ``urllib.quote``) to the ouput of :meth:`~django.core.urlresolvers.reverse`
 may produce undesirable results.
 
+reverse_lazy()
+--
+
+.. versionadded:: 1.4
+
+A lazily evaluated version of `reverse()`_.
+
+It is useful for when you need to use a URL reversal before your project's
+URLConf is loaded. Some common cases where this method is necessary are::
+
+* providing a reversed URL as the ``url`` attribute of a generic class-based
+  view.
+
+* providing a reversed URL to a decorator (such as the ``login_url`` argument
+  for the :func:`django.contrib.auth.decorators.permission_required`
+  decorator).
+
+* providing a reversed URL as a default value for a parameter in a function's
+  signature.
+
 resolve()
 -
 

Modified: django/trunk/tests/regressiontests/urlpatterns_reverse/tests.py
===
--- django/trunk/tests/regressiontests/urlpatterns_reverse/tests.py 
2011-04-28 14:54:09 UTC (rev 16120)
+++ django/trunk/tests/regressiontests/urlpatterns_reverse/tests.py 
2011-04-29 11:49:59 UTC (rev 16121)
@@ -10,6 +10,7 @@
 from django.shortcuts import redirect
 from django.test import TestCase
 from django.utils import unittest
+from django.contrib.auth.models import User
 
 import urlconf_outer
 import urlconf_inner
@@ -218,6 +219,21 @@
 else:
 self.assertEqual(t.name, e['name'], 'Wrong URL 
name.  Expected "%s", got "%s".' % (e['name'], t.name))
 
+class ReverseLazyTest(TestCase):
+urls = 'regressiontests.urlpatterns_reverse.reverse_lazy_urls'
+
+def test_redirect_with_lazy_reverse(self):
+response = self.client.get('/redirect/')
+self.assertRedirects(response, "/redirected_to/", status_code=301)
+
+def test_user_permission_with_lazy_reverse(self):
+user = User.objects.create_user('alfred', 'alf...@example.com', 
password='testpw')
+response = self.client.get('/login_required_view/')
+self.assertRedirects(response, "/login/?next=/login_required_view/", 
status_code=302)
+self.client.login(username='alfred', password='testpw')
+response = self.client.get('/login_required_view/')
+self.assertEqual(response.status_code, 200)
+
 class ReverseShortcutTests(TestCase):
 urls = 'regressiontests.urlpatterns_reverse.urls'
 

Modified: django/trunk/tests/regressiontests/urlpatterns_reverse/views.py
===
--- django/trunk/tests/

Re: [Django] #5925: Unable to use urlresolvers (url, reverse ) feature in redirect argument of decorator user_passes_test

[Django]

#5925: Unable to use urlresolvers (url,reverse ) feature in redirect argument of
decorator user_passes_test
-+-
   Reporter:  anonymous  |  Owner:  SmileyChris
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone:  1.3|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  
urlresolver,reverse,decorator,url,permalink
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by jezdez):

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


Comment:

 In [16121]:
 {{{
 #!CommitTicketReference repository="" revision="16121"
 Fixed #5925 -- Added new lazily evaluated version of
 django.core.urlresolvers.reverse. Thanks, SmileyChris, Preston Timmons and
 Julien Phalip.
 }}}

-- 
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] #15928: RegexField and regexp flags

[Django]

#15928: RegexField and regexp flags
-+
 Reporter:  Sergey N. Belinsky   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:  1.4  |  Component:  Forms
  Version:  1.3  |   Severity:  Normal
 Keywords:  RegexField unicode re.compile|   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+
 The syntax of re.compile function is:

 regexp = re.compile(pattern[, flags])

 but this function in RegexField used without flags. I suggest to use the
 next syntax for RegexField:

 login = RegexField(r'^\w+', flags=re.UNICODE|re.IGNORE)

 I guess it will be useful. Thank you!

-- 
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] #15927: FORMAT_QMARK_REGEX in sqlite backend does not work as expected

[Django]

#15927: FORMAT_QMARK_REGEX in sqlite backend does not work as expected
---+--
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Database layer (models, ORM)
  Version:  1.3-rc1|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+--
 FORMAT_QMARK_REGEX is not correct (in django/db/backends/sqlite3/base.py).

 It uses a lookahead assertion trying to not match if the char before the
 "%s" is not "%" but lookahead assertion can't be used to do that (it is
 for looking ahead not behind).

 Example:

 {{{
 In the regex '(?!..)b' applied on 'abc' the '..' will match 'bc' so:
  - re.search(r'(?!a)b','abc') => match 'b'
  - re.search(r'(?!b)b','abc') => no match
 }}}

 I don't think this regex could be writen with lookhead assertions.

 A possible solution could be:
 {{{
 re.compile(r'(^|[^%])%s').sub(r'\1?','%s %%s %s')
 }}}

-- 
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] #15693: Support broken for custom widgets in inlines Jquery based Add new

[Django]

#15693: Support broken for custom widgets in inlines Jquery based Add new 
--+---
   Reporter:  brillgen|  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.admin
Version:  1.2 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---
Changes (by brillgen):

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


Comment:

 I'll work on extracting the code so that it can be presented here but I
 think the issue has been described pretty clearly to someone familiar with
 the Admin and/or its internals.

 This got broken in Django 1.1/1.2 when the new functionality of adding
 inlines on-the-fly with javascript was introduced.

 We have a custom widget we use to populate FK fields which works perfectly
 well with the Django Admin inlines when they have been created by the
 'extra' parameter in the admin.
 The widget does not work because its javascript event is not mapped to the
 new inline that has been created with javascript.

 The bug is that the javascript add new inline functionality should support
 custom widgets as well...if it does, it's not obvious and not documented
 (AFAIK).

-- 
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] #15924: html5 forms input types, attributes

[Django]

#15924: html5 forms input types, attributes
---+--
   Reporter:  roman2k9@…   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Forms
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:  forms, html5
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+--
Changes (by jonash):

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


Comment:

 `placeholder` would definitely be a very useful addition.

-- 
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] #5925: Unable to use urlresolvers (url, reverse ) feature in redirect argument of decorator user_passes_test

[Django]

#5925: Unable to use urlresolvers (url,reverse ) feature in redirect argument of
decorator user_passes_test
-+-
   Reporter:  anonymous  |  Owner:  SmileyChris
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone:  1.3|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  
urlresolver,reverse,decorator,url,permalink
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by julien):

 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 I agree with SmileyChris that ``reverse_lazy()`` is the right approach as
 it is more explicit, thus marking this ticket as accepted. I've updated
 the patch with tests using class-based views instead of the deprecated
 "simple" ones, also tweaked the doc to reflect that, and added release
 notes. I'm hoping this gets checked in as it would help tickets like
 #15294 move forward. Not marking RFC yet as I'd like to have another pair
 of eyes review this 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.

[Django] #15926: Option to not load initial fixtures during syncdb

[Django]

#15926: Option to not load initial fixtures during syncdb
-+-
 Reporter:  msiedlarek   |  Owner:  msiedlarek
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Core (Management
  Version:  1.3  |  commands)
 Keywords:  management syncdb|   Severity:  Normal
  options fixtures   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+-
 There are some situation in which you may want to prevent automatic
 loading of initial fixtures by `syncdb` management command. One example is
 when you want to create a database schema and fill it with data from the
 other database. If there were initial fixtures loaded in both databases
 there probably would be some primary key conflicts raised.

 There is a stealth option for that, called `load_initial_data`, and used
 by testing setup, by I believe it's not fair to take away from user such a
 useful 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] #15766: select_related() changes type of DecimalField

[Django]

#15766: select_related() changes type of DecimalField
-+-
   Reporter:  CarstenF   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
  worksforme |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by CarstenF):

 lukeplant, you are right:
 I had to start my project with a legacy Oracle database, and used
 `manage.py inspectdb` to create the initial `models.py`, and never
 realized that it had a mix of database fields of type `FLOAT` and `NUMBER`
 that in `models.py` were both addressed with `DecimalField(...)`.

 Changing the database to use type `NUMBER` instead of `FLOAT` fixes my
 problem (even though the Oracle docs seem to indicate that `FLOAT` is
 "equivalent" to `NUMBER`...).

 Please forgive me the false alarm, I'm very sorry for the trouble.
 Many thanks for your patience and help!

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

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

Re: [Django] #15922: prepopulated_fields for DecimalField generates js error

[Django]

#15922: prepopulated_fields for DecimalField generates js error
-+-
   Reporter:  lev|  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  prepopulated_fields
   Triage Stage:  Accepted   |  Decimal default_if_none
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 lev, we can't see your code, so we need some context to understand the
 problem you're reporting. See the instructions here for how to write a
 good bug report:
 http://docs.djangoproject.com/en/dev/internals/contributing/#reporting-
 bugs

 I could eventually reproduce the problem, here is a minimal test case that
 works:
 {{{
 # models.py

 from django.db import models

 class Book(models.Model):
 starting_price = models.DecimalField(decimal_places=2, max_digits=10)
 price = models.DecimalField(decimal_places=2, max_digits=10)

 # admin.py

 from django.contrib import admin
 import models

 class BookAdmin(admin.ModelAdmin):
 prepopulated_fields = {
 'price': ['starting_price'],
 }

 admin.site.register(models.Book, BookAdmin)
 }}}

 With this code, trying to add a new book with the admin results in the
 javascript error described in the initial bug report. This error is in
 dynamically generated javascript in the HTML.

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