Re: [Django] #15103: Django 1.2.4 breaks limit_choices_to for raw_id_fields

[Django]

#15103: Django 1.2.4 breaks limit_choices_to for raw_id_fields
---+
  Reporter:  natrius   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  django.contrib.admin  |   Version:  1.2
   
Resolution:|  Keywords:  blocker regression 
send_mail email
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 lookup_internal was quite deliberately undocumented so that it wouldn't be
 official API, giving us the flexibility to change it if required. This was
 because #5833 (and at the time, #3400) is still lingering, and we didn't
 want to back ourself into a corner.

 It's unfortunate that people are externally documenting the "fix" for the
 security problem to be "remove the security", but there's not much we can
 do beyond documenting the change.

 That said, I'm not completely convinced a change in signature is required.
 The patch you provide certainly works, and the broad thrust seems correct
 to me. However, the original security issue was about allowing completely
 arbitrary join combinations -- the absence of any security checks meant
 you could set up a query to retrieve password details, or anything else of
 interest in the database.

 If you're defining limit_choices_to = {'leader__name="palin"'} , you're
 pretty much saying that it's ok to inspect the name field of the leader
 relation. Ok; this would allow you to find out the name of any leader in
 the system, but only by a process of elimination, and you would only find
 the leader's name, and only if you already had access to the admin.

-- 
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] #9826: timesince/timeuntil output should include seconds

[Django]

#9826: timesince/timeuntil output should include seconds
--+-
  Reporter:  clay | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Template system  |   Version:  1.0   
Resolution:  wontfix  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 To paraphrase Einstein: A minute is a long time if your hand is in a fire.
 It's a very short time if you're talking to a pretty girl. It's all
 relative :-)

 This isn't an area where we need a proliferation of template tags. To me,
 minute level granularity seems an appropriate level of precision for a
 wide range of applications, and the fact that this is the first (to my
 memory) request for this to be changed supports that assertion.

 It's not a case of "everyone" needs to roll their own -- only people who
 want second-level granularity have to roll their own. I'm happy to put
 this in the basket of things requiring local customization.

-- 
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] #15123: models Meta's db_table and ManyToManyField

[Django]

#15123: models Meta's db_table  and ManyToManyField
--+-
  Reporter:  ctao | Owner:   
Status:  closed   | Milestone:  1.3  
 Component:  ORM aggregation  |   Version:  1.3-alpha
Resolution:  invalid  |  Keywords:   
 Stage:  Unreviewed   | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 This can be achieved by defining a custom m2m-through model, and defining
 the db_column attribute on the FK fields.

-- 
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] #15141: Falcon engine for mysql is dead it was scrapped along with MySQL 6.0 branch.

[Django]

#15141: Falcon engine for mysql is dead it was scrapped along with MySQL 6.0
branch.
+---
  Reporter:  mariuz   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 We should probably avoid mentioning any specific engines at all, given
 that they don't have a great history of actually being completed.

-- 
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] #15145: __in is ignored by an excluded query if foo__in is set to an empty iterable

[Django]

#15145: __in is ignored by an excluded query if foo__in is set to an empty 
iterable
---+
  Reporter:  melinath  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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] #15144: Max age set in cache control no longer obeys timeout set with @cache_page decorator

[Django]

#15144: Max age set in cache control no longer obeys timeout set with 
@cache_page
decorator
---+
  Reporter:  jsdalton  | Owner:  nobody 
Status:  new   | Milestone:  1.3
 Component:  Cache system  |   Version:  SVN
Resolution:|  Keywords:  blocker, regression
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * keywords:  => blocker, regression
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I'm a little uncertain as to the exact use case where you are seeing this
 problem. Yes, the code has been changed to set self.cache_timeout =
 self.cache.default_timeout, but that default timeout should be the value
 that has been passed into the cache backend.

 Can you reduce this to a relatively simple test case that demonstrates
 when the wrong value is being used?

 Marking as a blocker, regression because if true, this is something that
 needs to be fixed before release; however, we need more detail before we
 can confirm.

-- 
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] #15142: Contrib tests throwing errors on bare project when cache middleware enabled and cache specified

[Django]

#15142: Contrib tests throwing errors on bare project when cache middleware 
enabled
and cache specified
---+
  Reporter:  jsdalton  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 To clarify -- this only appears to be a problem for the memcache backend;
 locmem doesn't seem to cause any issues.

 I'm not completely convinced that @never_cache is the right solution here.
 Unit tests shouldn't require any special preparation to enable them to be
 test isolated -- the testing environment should provide those guarantees.
 However, any test involving caching will cause data to be put into a cache
 that can be easily lost.

 Django's test framework clears the database at the end of every test for
 exactly this reason; there is an argument that the cache should be flushed
 in the same way. However, I can see two problemw with this:

  1) Accidentially flushing a cache that contains other useful data (e.g.,
 the production cache)
  2) The cost of cache flushing when there is no cache used during a test.

-- 
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] #15146: Reverse relations for unsaved objects include objects with NULL foreign key

[Django]

#15146: Reverse relations for unsaved objects include objects with NULL foreign 
key
---+
  Reporter:  treyh | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 This is an edge case that exists when an object has been created, but not
 saved; at that point, the primary key of the object is NULL, so the
 reverse query does a lookup with that value.

 The fix here will be to prevent related object lookups when pk=None.

-- 
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] #7145: 'NoneType' object has no attribute 'year' in admin change list when using date_hierarchy with a date field with null values

[Django]

#7145: 'NoneType' object has no attribute 'year' in admin change list when using
date_hierarchy with a date field with null values
--+-
  Reporter:  Eric Walstad   | Owner:  
nobody
Status:  reopened | Milestone:  1.3 
  
 Component:  django.contrib.admin |   Version:  SVN 
  
Resolution:   |  Keywords:  
  
 Stage:  Unreviewed   | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by daniellindsley):

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

Comment:

 I uploaded both a 1.2 & 1.3 version of the patch. However, the 1.3 is
 tests-only, as the same bug doesn't seem to be present in 1.3.

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

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

Re: [Django] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

[Django]

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by natrius):

 I agree with each of the possible solutions you've suggested as well as
 the timeline.

-- 
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] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

[Django]

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by carljm):

 Replying to [comment:20 natrius]:
 > Having `CACHE_MIDDLEWARE_ANONYMOUS_ONLY` at all will give users an
 incorrect mental model of how caching in general works. Anonymity is
 irrelevant. `Vary` headers are the right place for users to be looking, so
 an appropriately named option that performs the correct behavior will have
 positive educational side-effects in addition to the small performance
 benefits.

 I agree; the question is just how much deprecation churn that benefit is
 worth. I may start a django-developers thread to discuss this at some
 point, or if you want to it'd be helpful to get other developers'
 thoughts.

 Making UpdateCacheMiddleware more easily extensible is potentially
 interesting; I'm not sure I want to start proliferating subclasses of it
 in Django, though, so I'm still more inclined towards a setting
 (CACHE_MIDDLEWARE_SKIP_VARY_COOKIE?). I think it's also possible that we
 could just make the behavior change you're suggesting (cache non-Vary-
 Cookie only, regardless of anonymity), and leave the slightly-misleading
 setting name, with a documentation note about the name, to reduce
 deprecation churn.

 In any case, this needs to be split into two changes at this point.
 Pre-1.3, I'd like to fix the most pressing issue, which is adding Vary:
 Cookie when it shouldn't be there. That's a bugfix. The rest of this is
 more in feature territory; now that we're post-beta for 1.3 I don't think
 we can deprecate the current setting, add a new one, or make additional
 behavior changes, so that's a discussion for the 1.4 timeframe.

-- 
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] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

[Django]

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by natrius):

 My patch still caches responses that vary by cookie for anonymous users,
 which is probably undesirable for users who would want to set this in the
 first place. A setting that skips any response that varies by cookie is a
 cleaner and more effective way to do it. (My local patch makes altering
 the caching conditions in `UpdateCacheMiddleware` subclasses much easier
 and provides a `SkipVaryCookieUpdateCacheMiddleware` instead of a setting,
 which is a more extensible solution.)

 Having `CACHE_MIDDLEWARE_ANONYMOUS_ONLY` at all will give users an
 incorrect mental model of how caching in general works. Anonymity is
 irrelevant. `Vary` headers are the right place for users to be looking, so
 an appropriately named option that performs the correct behavior will have
 positive educational side-effects in addition to the small performance
 benefits.

-- 
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] #15146: Reverse relations for unsaved objects include objects with NULL foreign key

[Django]

#15146: Reverse relations for unsaved objects include objects with NULL foreign 
key
+---
  Reporter:  treyh  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by treyh):

  * summary:  Reverse relations include objects with NULL foreign key =>
  Reverse relations for unsaved objects include
  objects with NULL foreign key

-- 
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] #15146: Reverse relations include objects with NULL foreign key

[Django]

#15146: Reverse relations include objects with NULL foreign key
+---
  Reporter:  treyh  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by treyh):

  * needs_better_patch:  => 0
  * summary:  Reverse relations include unsaved objects (NULL id) =>
  Reverse relations include objects with NULL
  foreign key
  * 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] #15146: Reverse relations include unsaved objects (NULL id)

[Django]

#15146: Reverse relations include unsaved objects (NULL id)
---+
 Reporter:  treyh  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Model with '''parent''' relation and '''children''' reverse relation:

 {{{
 class TestModel(models.Model):
 parent = models.ForeignKey('self', blank=True, null=True,
 related_name='children')
 }}}



 Bug found while using model:


 {{{
 t = TestModel()
 t.save()
 u = TestModel()
 u.children.all() # Incorrectly returns: []
 u.save()
 u.children.all() # Correctly returns: []
 }}}

-- 
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] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

[Django]

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by carljm):

 Replying to [comment:18 natrius]:
 > This seems like a problem that should be ameliorated somehow for Django
 1.3.

 I'm planning to get back to your pull request and commit some form of it
 before Django 1.3 -- just haven't gotten there yet.

 > If we want users to be able to save memory by not caching user-specific
 pages, I have a patch to do that with a separate setting, but
 `CACHE_MIDDLEWARE_ANONYMOUS_ONLY` must die soon. My patch provides a
 reasonable transition behavior for existing users of the setting before it
 goes away completely.

 What do you see as inadequate about your pull request mentioned above, as
 a way to preserve CACHE_MIDDLEWARE_ANONYMOUS_ONLY? Why do you think it
 needs to go away completely, and/or be replaced by another setting?

 I understand that simply caching all requests is often fine, since the
 caching will vary by cookie anyway and won't result in the wrong content
 being shown to a user. But in some cases it's still useful to be able to
 easily turn off caching for all user-variable pages, since for some sites
 they may be the pages with the most dynamic content (and caching with
 Vary: Cookie eats up cache memory a lot faster).

-- 
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] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

[Django]

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by natrius):

 This seems like a problem that should be ameliorated somehow for Django
 1.3. The setting seems to have been added before `CacheMiddleware`
 respected `Vary` headers in order to prevent user-specific pages from
 being cached and shown to other users. That is no longer possible, so the
 setting should be removed. At the minimum, the setting should be marked as
 deprecated in the documentation instead of touted as a useful feature so
 people don't keep using a broken, unnecessary setting. If we want users to
 be able to save memory by not caching user-specific pages, I have a patch
 to do that with a separate setting, but `CACHE_MIDDLEWARE_ANONYMOUS_ONLY`
 must die soon. My patch provides a reasonable transition behavior for
 existing users of the setting before it goes away completely.

-- 
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] #14924: I18N looks for translations in the reverse order of the apps

[Django]

#14924: I18N looks for translations in the reverse order of the apps
---+
  Reporter:  vanschelven   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * has_patch:  0 => 1

Comment:

 The 14924.1.diff patch implements the modifcations discussed here and in
 the [http://groups.google.com/group/django-
 developers/browse_thread/thread/6c098e16da4c49ae?hl=en  mailing list
 thread]. Namely, to modify the precedence of loading of translations from
 compiled message files from the current situation (from higher to lesser):

   * The translation found in locale/ subdir of the the project dir.
   * The translations found in the apps listed in settings.INSTALLED_APPS
 with the latter ones having higher precedence.
   * The translations found in the paths listed in settings.LOCALE_PATHS
 with the latter ones having higher precedence.
   * The translations shipped with Django.

 To (also from higher to lesser precedence):

   * The translations found in the paths listed in settings.LOCALE_PATHS
 with the ones located first having higher precedence.
   * The translation found in locale/ subdir of the the project dir.
   * The translations found in the apps listed in settings.INSTALLED_APPS
 with the ones located first having higher precedence.
   * The translations shipped with Django.

 As proposed by vanschelven.

 Tests and docs were modified accordingly. Some of these tests/docs mods
 are tweaks that can be extracted and applied even if this ticket isn't
 accepted or committing of the patch is deferred.

-- 
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] #15103: Django 1.2.4 breaks limit_choices_to for raw_id_fields

[Django]

#15103: Django 1.2.4 breaks limit_choices_to for raw_id_fields
---+
  Reporter:  natrius   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  django.contrib.admin  |   Version:  1.2
   
Resolution:|  Keywords:  blocker regression 
send_mail email
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by carljm):

 Replying to [comment:4 lukeplant]:
 > I have attached a patch which fixes the issue, for another pair of eyes
 to review. For the reason given above, I have implemented it so that only
 the exact lookup specified in the limit_choices_to is allowed. The only
 problem is that this involves passing the value to the
 `ModelAdmin.lookup_allowed` method, thus changing its signature. Due to
 the breakage in 1.2.4, people are already using the lookup_allowed method
 (e.g. http://www.hoboes.com/Mimsy/hacks/fixing-django-124s-
 suspiciousoperation-filtering/ ), so we need to think what to do about
 that.

 I realize people are overriding this method because 1.2.4 already broke
 their code once, but nonetheless: if we can't change the signature of
 undocumented internal methods, we're really up a creek fixing anything in
 a sane way. Seems reasonable to me to go ahead and make this fix with a
 warning in the release notes for 1.2.5.

 Overall, fix looks reasonable to me.

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

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

Re: [Django] #14880: raw_id_fields in admin does not work when limit_choices_to dictionary has value=False

[Django]

#14880: raw_id_fields in admin does not work when limit_choices_to dictionary 
has
value=False
---+
  Reporter:  smallm...@gmail.com   | Owner:  lukeplant
Status:  assigned  | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:|  Keywords:   
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by lukeplant):

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

Comment:

 I will look at this, as it is related to the fix in #15103

-- 
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] #11319: ForeignKey filters use the wrong field to prepare values for database

[Django]

#11319: ForeignKey filters use the wrong field to prepare values for database
---+
  Reporter:  russellm  | Owner:  carljm
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by carljm):

 Discussed this with Alex Gaynor on IRC. Using this Category class as an
 example, we're both agreed that the first fix results in more intuitive
 usage:

 {{{
 class Category(models.Model):
 name = models.CharField(max_length=10)
 parent = models.ForeignKey("self", to_field="name",
 related_name="children")
 }}}

 With either fix, you can query it this way in the forward direction:
 `Category.objects.filter(parent="Kittehs")` and can query it using a full
 Category object in either direction.

 Currently, and if we make the second fix, you have to query in the reverse
 direction using the PK: `Category.objects.filter(children=1)`

 Whereas if we make the first fix, you could query like this:
 `Category.objects.filter(children="Noms")`

 Seems clear that the latter is more intuitive. And it requires the less-
 invasive fix (which I've pushed to
 https://github.com/carljm/django/compare/master...t11319-simpler for
 comparison).

 I'd be in favor of making this fix; my only remaining question is whether
 the backwards-incompatible change is a concern. It's a very rare edge case
 of an edge case: I think we can safely call it part of a bugfix.

-- 
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] #11319: ForeignKey filters use the wrong field to prepare values for database

[Django]

#11319: ForeignKey filters use the wrong field to prepare values for database
---+
  Reporter:  russellm  | Owner:  carljm
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by carljm):

 The change in query.py may indeed be wrong, but if so it's not because it
 needs to be broader; rather because it (arguably?) shouldn't be there at
 all.

 The "to_field" argument to a ForeignKey generally only applies to the
 target model of that FK, obviously: if you're traversing that same
 relationship in the reverse direction, the lookup should just use the
 primary key of the model on which the FK is defined.

 The problem is that the same RelatedField (ForeignKey or OneToOneField)
 object is asked to "get_prep_lookup" the lookup value in either case,
 regardless of whether the lookup is taking place in a forwards or reverse
 direction across that RelatedField. And currently, it's asked to do so
 without ever being informed which type of lookup is happening!

 I guard the to_field lookup in RelatedField._pk_trace with an isinstance
 check, to make sure the value is actually an instance of the model the FK
 points to (or a subclass of it). In most cases, this is enough to prevent
 use of to_field on a reverse FK traversal, because normally the two sides
 of an FK are two different model classes. But in the case of a recursive
 FK that uses to_field, both sides of the FK are the same model class, so
 the isinstance check passes either way, and to_field is used on the
 reverse lookup too.

 The change I'd made in query.py worked around this specific case by also
 using the to_field column name rather than the PK column name in the
 recursive reverse lookup case. Then it's ok that _pk_trace doesn't know
 the difference and preps the to_field value in either case.

 If you expect recursive FKs to work just like other FKs, this is the wrong
 fix; the to_field should only be used for lookups in the forwards
 direction. If you expect to_field to be used for lookups in both
 directions on a recursive FK (only), because in that specific case it can,
 it might be the right fix. I'm not actually sure how to choose between
 those - either one should result in a correct query.

 I've now updated my branch with the alternative fix, which requires
 significantly more invasive changes, because the knowledge of whether it's
 a forward or reverse lookup currently exists only in Query.setup_joins(),
 and has to be passed through the Constraint object in order to get to
 RelatedField.get_prep_lookup(). It also requires adding a new
 get_prep_lookup_reverse() method to Fields, in order to avoid requiring
 all custom Field classes to update their get_prep_lookup() methods with a
 new parameter.

 I've run this fix through the same tests as above (full test suite on
 SQLite and Postgres, "queries" and "delete_regress" on MySQL, ISAM and
 InnoDB), and everything passes this way as well.

 I think a case can be made for either version of the fix.

 The case for the first fix is that it's much less invasive, and it's not
 unreasonable to apply to_field in lookups both directions on a recursive
 FK; with the same model on each end, there's no reason to_field can't work
 just fine both directions.

 The case for the second fix is twofold: 1) That it really seems like
 RelatedField _ought_ to know whether it's prepping a value for a forward
 or reverse lookup, so perhaps the invasiveness is justified, and 2) That
 the behavior of ForeignKey.to_field shouldn't change just because its a
 recursive FK.

 There is one concrete difference between the two fixes. It changes whether
 you need to use the PK value or the to_field value if specifying the value
 directly in the lookup, rather than providing an object. In that sense,
 the first (less-invasive) fix is backwards-incompatible for anyone
 currently working around this bug on a recursive FK by providing using
 "=obj.pk" instead of "=obj" in their lookup; they'd have to switch to
 "=obj.to_field_name" (or just switch to "=obj").

 Sorry for the novel - thoughts on this?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this 

[Django] #15145: __in is ignored by an excluded query if foo__in is set to an empty iterable

[Django]

#15145: __in is ignored by an excluded query if foo__in is set to an empty 
iterable
--+-
 Reporter:  melinath  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Please note that the arguments may be ignored by a filtered query. I
 haven't tested that.

 Assume the following model setup:
 {{{
 #!python
 from django.db import models
 from django.contrib.contenttypes.models import ContentType


 class TestModel1(models.Model):
 content_type = models.ForeignKey(ContentType)
 integer = models.PositiveIntegerField()
 }}}

 Now run the following code:
 {{{
 #!python
 >>> from test.models import TestModel1 # or wherever you're keeping it.
 >>> from django.contrib.contenttypes.models import ContentType
 >>> integer = 1
 >>> ct = ContentType.objects.all()[0]
 >>> TestModel1.objects.create(integer=integer, content_type=ct)
 
 >>> TestModel1.objects.all()
 []
 >>> # This is where it starts getting interesting.
 >>> TestModel1.objects.exclude(content_type=ct, integer__in=[])
 []
 }}}
 According to the documentation, this kind of exclude should exclude all
 rows where the content type is ct AND integer is in the list. Now since
 the list is empty, there should be no rows matching the exclusion, so all
 rows should be returned. Instead, I get an empty queryset.

 Here's a look at the sql being generated by various queries (Line breaks
 added for readability):

 

 {{{TestModel1.objects.all() or TestModel1.objects.exclude(integer__in=[])
 or TestModel1.objects.exclude(content_type__in=[])}}}
 {{{
 #!sql
 SELECT "test_testmodel1"."id", "test_testmodel1"."content_type_id",
 "test_testmodel1"."integer" FROM "test_testmodel1"
 }}}

 

 {{{TestModel1.objects.exclude(integer__in=[2])}}}
 {{{
 #!sql
 SELECT "test_testmodel1"."id", "test_testmodel1"."content_type_id",
 "test_testmodel1"."integer"
 FROM "test_testmodel1" WHERE NOT ("test_testmodel1"."integer" IN (2))
 }}}

 

 {{{TestModel1.objects.exclude(integer__in=[], content_type=ct) or
 TestModel1.objects.exclude(content_type=ct)}}}
 {{{
 #!sql
 SELECT "test_testmodel1"."id", "test_testmodel1"."content_type_id",
 "test_testmodel1"."integer"
 FROM "test_testmodel1" WHERE NOT ("test_testmodel1"."content_type_id" = 1
 )
 }}}

 ---

 {{{TestModel1.objects.exclude(content_type__in=[], integer=1) or
 TestModel1.objects.exclude(integer=1)}}}
 {{{
 #!sql
 SELECT "test_testmodel1"."id", "test_testmodel1"."content_type_id",
 "test_testmodel1"."integer"
 FROM "test_testmodel1" WHERE NOT ("test_testmodel1"."integer" = 1 )

 ---

 As you can see, the __in kwarg is being completely ignored. Unfortunately,
 I can't for the life of me figure out where the bug is happening, or I
 would try to write a patch. In case it's relevant, I'm using a sqlite3
 database.

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

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

Re: [Django] #15104: Django 1.2.4 removes support for lookups that span relationships in limit_choices_to

[Django]

#15104: Django 1.2.4 removes support for lookups that span relationships in
limit_choices_to
+---
  Reporter:  natrius| Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  worksforme |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by natrius):

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

Comment:

 You're correct. Thanks.

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

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

[Changeset] r15279 - django/trunk/django/core/management/commands

[noreply]

Author: ramiro
Date: 2011-01-21 15:00:39 -0600 (Fri, 21 Jan 2011)
New Revision: 15279

Modified:
   django/trunk/django/core/management/commands/makemessages.py
Log:
Converted makemessages management command to a NoArgsCommand.

Modified: django/trunk/django/core/management/commands/makemessages.py
===
--- django/trunk/django/core/management/commands/makemessages.py
2011-01-21 20:47:56 UTC (rev 15278)
+++ django/trunk/django/core/management/commands/makemessages.py
2011-01-21 21:00:39 UTC (rev 15279)
@@ -7,7 +7,7 @@
 from optparse import make_option
 from subprocess import PIPE, Popen
 
-from django.core.management.base import CommandError, BaseCommand
+from django.core.management.base import CommandError, NoArgsCommand
 from django.utils.text import get_text_list
 
 pythonize_re = re.compile(r'(?:^|\n)\s*//')
@@ -298,8 +298,8 @@
 raise CommandError("errors happened while running 
msgattrib\n%s" % errors)
 
 
-class Command(BaseCommand):
-option_list = BaseCommand.option_list + (
+class Command(NoArgsCommand):
+option_list = NoArgsCommand.option_list + (
 make_option('--locale', '-l', default=None, dest='locale',
 help='Creates or updates the message files only for the given 
locale (e.g. pt_BR).'),
 make_option('--domain', '-d', default='django', dest='domain',
@@ -325,10 +325,7 @@
 requires_model_validation = False
 can_import_settings = False
 
-def handle(self, *args, **options):
-if len(args) != 0:
-raise CommandError("Command doesn't accept any arguments")
-
+def handle_noargs(self, *args, **options):
 locale = options.get('locale')
 domain = options.get('domain')
 verbosity = int(options.get('verbosity'))

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

[noreply]

Author: jezdez
Date: 2011-01-21 14:47:56 -0600 (Fri, 21 Jan 2011)
New Revision: 15278

Modified:
   django/trunk/MANIFEST.in
Log:
Added app translation files to the package manifest template.

Modified: django/trunk/MANIFEST.in
===
--- django/trunk/MANIFEST.in2011-01-21 20:16:38 UTC (rev 15277)
+++ django/trunk/MANIFEST.in2011-01-21 20:47:56 UTC (rev 15278)
@@ -12,6 +12,7 @@
 recursive-include extras *
 recursive-include tests *
 recursive-include django/conf/locale *
+recursive-include django/contrib/*/locale *
 recursive-include django/contrib/admin/templates *
 recursive-include django/contrib/admin/media *
 recursive-include django/contrib/admindocs/templates *

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

[Django]

#15143: Add precisions about setting the language for the test client
+---
  Reporter:  claudep| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ramiro):

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

Comment:

 BTW, the `activate/deactivate` functions from `django.utils.translation`
 aren't documented either.

-- 
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] #7145: 'NoneType' object has no attribute 'year' in admin change list when using date_hierarchy with a date field with null values

[Django]

#7145: 'NoneType' object has no attribute 'year' in admin change list when using
date_hierarchy with a date field with null values
--+-
  Reporter:  Eric Walstad   | Owner:  
nobody
Status:  reopened | Milestone:  1.3 
  
 Component:  django.contrib.admin |   Version:  SVN 
  
Resolution:   |  Keywords:  
  
 Stage:  Unreviewed   | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  1   
  
Needs_better_patch:  0|  
--+-
Changes (by daniellindsley):

  * status:  closed => reopened
  * resolution:  duplicate =>
  * needs_tests:  0 => 1
  * milestone:  => 1.3

Comment:

 Sorry, but this was not a duplicate of #7147. It is still a bug as of
 Django 1.2.X.

 Fixing it to omit null dates is easy but creating a test for it is proving
 difficult. I'll try to upload a patch shortly.

-- 
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] r15277 - django/trunk/docs/topics

[noreply]

Author: Alex
Date: 2011-01-21 14:16:38 -0600 (Fri, 21 Jan 2011)
New Revision: 15277

Modified:
   django/trunk/docs/topics/generic-views-migration.txt
Log:
Fixed a typo in the docs, thanks to sunoano for the report.

Modified: django/trunk/docs/topics/generic-views-migration.txt
===
--- django/trunk/docs/topics/generic-views-migration.txt2011-01-21 
19:42:52 UTC (rev 15276)
+++ django/trunk/docs/topics/generic-views-migration.txt2011-01-21 
20:16:38 UTC (rev 15277)
@@ -51,7 +51,7 @@
 -
 
 The ``template`` argument to the ``direct_to_template`` view has been renamed
-``template_name``. This has ben done to maintain consistency with other views.
+``template_name``. This has been done to maintain consistency with other views.
 
 ``object_id`` argument to detail views
 --

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

[Django]

#9988: Make it possible to handle translation contexts
---+
  Reporter:  stephaner | Owner:  nobody   
Status:  reopened  | Milestone:  1.3  
 Component:  Internationalization  |   Version:  SVN  
Resolution:|  Keywords:  french i18n-nofix
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by claudep):

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

Comment:

 I'm reopening the ticket, because the latest patch which fixes the main
 issue of the original ticket is still not committed.

-- 
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] #15144: Max age set in cache control no longer obeys timeout set with @cache_page decorator

[Django]

#15144: Max age set in cache control no longer obeys timeout set with 
@cache_page
decorator
--+-
 Reporter:  jsdalton  |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Cache system  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Per the documentation, I would expect the max-age value set in the Cache
 Control to obey the timeout value passed to `@cache_page` when that
 decorator is used in a view. However, at present the max_age ignores that
 setting and instead uses the default timeout from the cache. (As a matter
 of fact, it even ignores the CACHE_MIDDLEWARE_SECONDS  settings.)

 I believe this is a regression, which from what I can tell, appears to
 have arisen in [15021]. This changeset introduced the following changes:

 The following line, which originally set the value of `self.cache_timeout`
 at the start of  `CacheMiddleware.__init__` to `cache_timeout`, was
 removed:

 {{{
 self.cache_timeout = cache_timeout
 }}}

 The following line was added to `CacheMiddleware.__init__`:

 {{{
 self.cache_timeout = self.cache.default_timeout
 }}}

 The result is that max_age is set to the value of whatever the cache
 timeout setting of the cache used, rather than the value of
 `cache_timeout` passed into `__init__()`as it did formerly.

 I wasn't able to find any background on this changeset so I couldn't
 determine whether this was a purposeful change in behavior for some other
 reason. For now, though, I can only conclude that this is a bug, since I
 would expect max-age to match the value of the timeout passed to
 cache_page.

-- 
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] #15112: runserver shows wrong IPv6 notation as address if started with -6 option, without giving a specific address to bind to

[Django]

#15112: runserver shows wrong IPv6 notation as address if started with -6 
option,
without giving a specific address to bind to
+---
  Reporter:  oxy| Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  django-admin.py runserver  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by claudep):

  * stage:  Accepted => Ready for checkin

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

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

[Django] #15143: Add precisions about setting the language for the test client

[Django]

#15143: Add precisions about setting the language for the test client
---+
 Reporter:  claudep|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I suggest to add a note in the documentation about how to set the language
 for the test client.

 Without the LocaleMiddleware, it's possible to set it with the
 activate/deactivate functions from django.utils.translation.

 When LocaleMiddleware is activated, another method has to be used,
 otherwise the settings.LANGUAGE_CODE is always used. I've been able to set
 the language by passing HTTP_ACCEPT_LANGUAGE='de' to the get/post method,
 or by loading a cookie
 (client.cookies.load({settings.LANGUAGE_COOKIE_NAME:'de'})).

-- 
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] r15275 - django/trunk/docs/internals

[noreply]

Author: jezdez
Date: 2011-01-21 13:37:16 -0600 (Fri, 21 Jan 2011)
New Revision: 15275

Modified:
   django/trunk/docs/internals/contributing.txt
Log:
Update contributing documentation for changed translation policy.

Modified: django/trunk/docs/internals/contributing.txt
===
--- django/trunk/docs/internals/contributing.txt2011-01-21 19:36:57 UTC 
(rev 15274)
+++ django/trunk/docs/internals/contributing.txt2011-01-21 19:37:16 UTC 
(rev 15275)
@@ -411,34 +411,45 @@
 
 * Make sure you read the notes about :ref:`specialties-of-django-i18n`.
 
-* Create translations using the methods described in the
-  :doc:`localization documentation `. For this
-  you will use the ``django-admin.py makemessages`` tool. In this
-  particular case it should be run from the top-level ``django`` directory
-  of the Django source tree.
+* Signup at `Transifex`_ and visit the `Django project page`_.
 
-  The script runs over the entire Django source tree and pulls out all
-  strings marked for translation. It creates (or updates) a message file in
-  the directory ``conf/locale`` (for example for ``pt_BR``, the file will 
be
-  ``conf/locale/pt_BR/LC_MESSAGES/django.po``).
+* On the "`Translation Teams`_" page, choose the language team you want
+  to work with, **or** -- in case the language team doesn't exist yet --
+  request a new team by clicking on the "Request a new team" button
+  and select the appropriate language.
 
-* Make sure that ``django-admin.py compilemessages -l `` runs without
-  producing any warnings.
+* Then, click the "Join this Team" button to become a member of this team.
+  Every team has at least one coordinator who is responsible to review
+  your membership request. You can of course also contact the team
+  coordinator to clarify procedual problems and handle the actual
+  translation process.
 
-* Repeat the last two steps for the ``djangojs`` domain (by appending the
-  ``-d djangojs`` command line option to the ``django-admin.py``
-  invocations).
+* Once you are a member of a team choose the translation resource you
+  want update on the team page. For example the "core" resource refers
+  to the translation catalogue that contains all non-app translations.
+  Each of the contrib apps also have a resource -- prefixed with 
"contrib-".
 
+  .. note::
+ For more information about how to use Transifex, see the
+ `Transifex Help`_
+
 * Optionally, review and update the ``conf/locale//formats.py``
-  file to describe the date, time and numbers formatting particularities of
-  your locale. See :ref:`format-localization` for details.
+  file to describe the date, time and numbers formatting particularities
+  of your locale. These files aren't covered by the use of Transifex and
+  require a patch against the Django source tree, just as a code change
+  would:
 
-* Create a diff against the current Subversion trunk.
+  * Create a diff against the current Subversion trunk.
 
-* Open a ticket in Django's ticket system, set its ``Component`` field to
-  ``Translations``, and attach the patch to it.
+  * Open a ticket in Django's ticket system, set its ``Component`` field
+to ``Translations``, and attach the patch to it. See
+:ref:`format-localization` for details.
 
 .. _Django i18n mailing list: http://groups.google.com/group/django-i18n/
+.. _Transifex: http://www.transifex.net/
+.. _Django project page: http://www.transifex.net/projects/p/django/
+.. _translation teams: http://www.transifex.net/projects/p/django/teams/
+.. _Transifex Help: http://help.transifex.net/
 
 Submitting javascript patches
 =

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

[noreply]

Author: jezdez
Date: 2011-01-21 13:36:57 -0600 (Fri, 21 Jan 2011)
New Revision: 15274

Added:
   django/trunk/.tx/
   django/trunk/.tx/config
Log:
Added the configuration file for Transifex.

Added: django/trunk/.tx/config
===
--- django/trunk/.tx/config (rev 0)
+++ django/trunk/.tx/config 2011-01-21 19:36:57 UTC (rev 15274)
@@ -0,0 +1,82 @@
+[main]
+host = https://www.transifex.net
+
+[django.core]
+file_filter = django/conf/locale//LC_MESSAGES/django.po
+source_file = django/conf/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-admin]
+file_filter = django/contrib/admin/locale//LC_MESSAGES/django.po
+source_file = django/contrib/admin/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-admin-js]
+file_filter = django/contrib/admin/locale//LC_MESSAGES/djangojs.po
+source_file = django/contrib/admin/locale/en/LC_MESSAGES/djangojs.po
+source_lang = en
+
+[django.contrib-admindocs]
+file_filter = django/contrib/admindocs/locale//LC_MESSAGES/django.po
+source_file = django/contrib/admindocs/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-auth]
+file_filter = django/contrib/auth/locale//LC_MESSAGES/django.po
+source_file = django/contrib/auth/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-comments]
+file_filter = django/contrib/comments/locale//LC_MESSAGES/django.po
+source_file = django/contrib/comments/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-contenttypes]
+file_filter = django/contrib/contenttypes/locale//LC_MESSAGES/django.po
+source_file = django/contrib/contenttypes/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-flatpages]
+file_filter = django/contrib/flatpages/locale//LC_MESSAGES/django.po
+source_file = django/contrib/flatpages/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-formtools]
+file_filter = django/contrib/formtools/locale//LC_MESSAGES/django.po
+source_file = django/contrib/formtools/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-gis]
+file_filter = django/contrib/gis/locale//LC_MESSAGES/django.po
+source_file = django/contrib/gis/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-humanize]
+file_filter = django/contrib/humanize/locale//LC_MESSAGES/django.po
+source_file = django/contrib/humanize/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-localflavor]
+file_filter = django/contrib/localflavor/locale//LC_MESSAGES/django.po
+source_file = django/contrib/localflavor/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-messages]
+file_filter = django/contrib/messages/locale//LC_MESSAGES/django.po
+source_file = django/contrib/messages/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-redirects]
+file_filter = django/contrib/redirects/locale//LC_MESSAGES/django.po
+source_file = django/contrib/redirects/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-sessions]
+file_filter = django/contrib/sessions/locale//LC_MESSAGES/django.po
+source_file = django/contrib/sessions/locale/en/LC_MESSAGES/django.po
+source_lang = en
+
+[django.contrib-sites]
+file_filter = django/contrib/sites/locale//LC_MESSAGES/django.po
+source_file = django/contrib/sites/locale/en/LC_MESSAGES/django.po
+source_lang = en

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r15273 - in django/trunk: django/contrib/admin tests/regressiontests/i18n tests/regressiontests/i18n/other/locale/de/LC_MESSAGES tests/regressiontests/templates

[noreply]

Author: jezdez
Date: 2011-01-21 13:36:26 -0600 (Fri, 21 Jan 2011)
New Revision: 15273

Modified:
   django/trunk/django/contrib/admin/sites.py
   django/trunk/tests/regressiontests/i18n/other/locale/de/LC_MESSAGES/django.mo
   django/trunk/tests/regressiontests/i18n/other/locale/de/LC_MESSAGES/django.po
   django/trunk/tests/regressiontests/i18n/tests.py
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Fixed a few translation related tests:

  * Extended the admin i18n view to also take the admin translation catalogues 
into account.
  * Use a translation string from the core translations to test LOCALE_PATHS.
  * Fixed Russian translation of singular forms.

Modified: django/trunk/django/contrib/admin/sites.py
===
--- django/trunk/django/contrib/admin/sites.py  2011-01-21 19:35:41 UTC (rev 
15272)
+++ django/trunk/django/contrib/admin/sites.py  2011-01-21 19:36:26 UTC (rev 
15273)
@@ -284,7 +284,7 @@
 from django.views.i18n import javascript_catalog
 else:
 from django.views.i18n import null_javascript_catalog as 
javascript_catalog
-return javascript_catalog(request, packages='django.conf')
+return javascript_catalog(request, packages=['django.conf', 
'django.contrib.admin'])
 
 @never_cache
 def logout(self, request, extra_context=None):

Modified: 
django/trunk/tests/regressiontests/i18n/other/locale/de/LC_MESSAGES/django.mo
===
--- 
django/trunk/tests/regressiontests/i18n/other/locale/de/LC_MESSAGES/django.mo   
2011-01-21 19:35:41 UTC (rev 15272)
+++ 
django/trunk/tests/regressiontests/i18n/other/locale/de/LC_MESSAGES/django.mo   
2011-01-21 19:36:26 UTC (rev 15273)
@@ -1,11 +1,11 @@
-Þ  •D   l   ˆ ‰   “   ¢   ¾   _   Ç
   '   A   E   ^Date/time month 
name May search %d result %d results verb May Project-Id-Version: PACKAGE 
VERSION
+Þ  •D   l   ˆ   ‰   Ž   ¹   _   Â  
 "   6   :   STime month name May 
search %d result %d results verb May Project-Id-Version: django tests
 Report-Msgid-Bugs-To: 
 POT-Creation-Date: 2010-02-14 17:33+0100
-PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE
-Last-Translator: FULL NAME 
-Language-Team: LANGUAGE 
+PO-Revision-Date: 2011-01-16 17:14+0100
+Last-Translator: Jannis Leidel 
+Language-Team: de 
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 Plural-Forms: nplurals=2; plural=(n != 1)
- Datum/Zeit (LOCALE_PATHS) Mai %d Resultat %d Resultate Kann 
\ No newline at end of file
+ Time (LOCALE_PATHS) Mai %d Resultat %d Resultate Kann 
\ No newline at end of file

Modified: 
django/trunk/tests/regressiontests/i18n/other/locale/de/LC_MESSAGES/django.po
===
--- 
django/trunk/tests/regressiontests/i18n/other/locale/de/LC_MESSAGES/django.po   
2011-01-21 19:35:41 UTC (rev 15272)
+++ 
django/trunk/tests/regressiontests/i18n/other/locale/de/LC_MESSAGES/django.po   
2011-01-21 19:36:26 UTC (rev 15273)
@@ -3,23 +3,22 @@
 # This file is distributed under the same license as the PACKAGE package.
 # FIRST AUTHOR , YEAR.
 #
-#, fuzzy
 msgid ""
 msgstr ""
-"Project-Id-Version: PACKAGE VERSION\n"
+"Project-Id-Version: django tests\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2010-02-14 17:33+0100\n"
-"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
-"Last-Translator: FULL NAME \n"
-"Language-Team: LANGUAGE \n"
+"PO-Revision-Date: 2011-01-16 17:14+0100\n"
+"Last-Translator: Jannis Leidel \n"
+"Language-Team: de \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1)\n"
 
 #: models.py:3
-msgid "Date/time"
-msgstr "Datum/Zeit (LOCALE_PATHS)"
+msgid "Time"
+msgstr "Time (LOCALE_PATHS)"
 
 #: models.py:5
 msgctxt "month name"
@@ -37,3 +36,4 @@
 msgid_plural "%d results"
 msgstr[0] "%d Resultat"
 msgstr[1] "%d Resultate"
+

Modified: django/trunk/tests/regressiontests/i18n/tests.py
===
--- django/trunk/tests/regressiontests/i18n/tests.py2011-01-21 19:35:41 UTC 
(rev 15272)
+++ django/trunk/tests/regressiontests/i18n/tests.py2011-01-21 19:36:26 UTC 
(rev 15273)
@@ -689,7 +689,7 @@
 super(LocalePathsResolutionOrderI18NTests, self).tearDown()
 
 def test_locale_paths_translation(self):
-self.assertUgettext('Date/time', 'LOCALE_PATHS')
+self.assertUgettext('Time', 'LOCALE_PATHS')
 
 class ProjectResolutionOrderI18NTests(ResolutionOrderI18NTests):
 

Modified: 

Re: [Django] #13717: unique_for_* errors out when date field is left empty

[Django]

#13717: unique_for_* errors out when date field is left empty
---+
  Reporter:  silviogutierrez   | Owner:  suzaku
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by natrius):

 I was still getting non-producible errors after this bug was closed, but
 the fix for bug #14951 should definitely fix it.

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

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

Re: [Django] #15142: Contrib tests throwing errors on bare project when cache middleware enabled and cache specified

[Django]

#15142: Contrib tests throwing errors on bare project when cache middleware 
enabled
and cache specified
---+
  Reporter:  jsdalton  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jsdalton):

 Oops, please ignore the first patch
 `cleanup_session_records_after_invalid_key_test.diff` and use
 `dont_cache_test_views.diff`. I accidentally uploaded the wrong patch, and
 I'm not sure how to delete it from trac.

-- 
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] #15142: Contrib tests throwing errors on bare project when cache middleware enabled and cache specified

[Django]

#15142: Contrib tests throwing errors on bare project when cache middleware 
enabled
and cache specified
---+
  Reporter:  jsdalton  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jsdalton):

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

Comment:

 I have traced the cause of these errors to some of the views that are
 created by contrib.auth and contrib.messages, in the urls.py file of each.
 These views are created for the purposes of running tests against them.

 The problem is that some of the these views are hit multiple times in a
 test run. When a view is hit a second time, the cache is returned to the
 test client (it would appear). In any case, the `context` attribute, which
 is normally set by the test client in the 'response` is not set (i.e. it
 is `None`) when a cache page is retrieved.. As a result, the tests cause
 an error like the one in the description of the ticket.

 My proposed solution to the problem is to affix the `@never_cache`
 decorator to the views created by the contrib apps for testing. These
 views are only used in testing, and no aspect of the caching system is
 tested during those test runs. In fact, the desired behavior of the views,
 per the test code, *is* to get a fresh response, with context.

 A patch with this solution is attached. Applying this patch and then re-
 running the tests with the setup described in the ticket description will
 result in a clean test run (no errors or failures).

-- 
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] #15142: Contrib tests throwing errors on bare project when cache middleware enabled and cache specified

[Django]

#15142: Contrib tests throwing errors on bare project when cache middleware 
enabled
and cache specified
--+-
 Reporter:  jsdalton  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Contrib apps  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I ran into an issue recently where the contrib tests were throwing
 multiple errors during a test run when cache middleware was enabled and a
 cache was specified.

 This is exactly the behavior described in this Stack Overflow question:
 http://stackoverflow.com/questions/3219668/using-django-cache-middleware-
 causes-contrib-auth-unit-tests-to-fail

 Here is a description of the setup and the steps to reproduce the problem
 (taken from that question):

 My Middleware:

 {{{
 MIDDLEWARE_CLASSES = (
 'django.middleware.cache.UpdateCacheMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.cache.FetchFromCacheMiddleware',
 )
 }}}

 All my test failures look like the one below:

 {{{
 ==
 Error: test_last_login
 (django.contrib.auth.tests.remote_user.RemoteUserTest)
 --
 Traceback (most recent call last):
   File "C:\Python26\lib\site-
 packages\django\contrib\auth\tests\remote_user.py",
  line 87, in test_last_login
 self.assertNotEqual(default_login,
 response.context['user'].last_login)
 TypeError: 'NoneType' object is unsubscriptable
 }}}

 Steps to Reproduce:

  1. Start a new django project (django-admin.py startproject myproject)
 and configure settings.py
  2. Add CACHE_BACKEND to settings.py and add the two Cache Middlewares
 from Django
  3. Run python manage.py test

 I have an idea as to the cause and a proposed patch to resolve this, but I
 will add it with a separate comment to keep the description of the issue
 clean here.

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

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

[Changeset] r15258 - django/trunk/django/core/management/commands

[noreply]

Author: jezdez
Date: 2011-01-21 11:30:35 -0600 (Fri, 21 Jan 2011)
New Revision: 15258

Modified:
   django/trunk/django/core/management/commands/makemessages.py
Log:
Added contrib apps to ignore list when running makemessages in the Djagno 
source tree and added a --no-obsolete option in preparation of moving app 
translations out of core.

Modified: django/trunk/django/core/management/commands/makemessages.py
===
--- django/trunk/django/core/management/commands/makemessages.py
2011-01-21 15:55:27 UTC (rev 15257)
+++ django/trunk/django/core/management/commands/makemessages.py
2011-01-21 17:30:35 UTC (rev 15258)
@@ -115,7 +115,8 @@
 
 
 def make_messages(locale=None, domain='django', verbosity='1', all=False,
-extensions=None, symlinks=False, ignore_patterns=[], no_wrap=False):
+extensions=None, symlinks=False, ignore_patterns=[], no_wrap=False,
+no_obsolete=False):
 """
 Uses the locale directory from the Django SVN tree or an application/
 project to process all
@@ -133,6 +134,8 @@
 if os.path.isdir(os.path.join('conf', 'locale')):
 localedir = os.path.abspath(os.path.join('conf', 'locale'))
 invoked_for_django = True
+# Ignoring all contrib apps
+ignore_patterns += ['contrib/*']
 elif os.path.isdir('locale'):
 localedir = os.path.abspath('locale')
 else:
@@ -288,6 +291,11 @@
 finally:
 f.close()
 os.unlink(potfile)
+if no_obsolete:
+msgs, errors = _popen('msgattrib %s -o "%s" --no-obsolete 
"%s"' %
+  (wrap, pofile, pofile))
+if errors:
+raise CommandError("errors happened while running 
msgattrib\n%s" % errors)
 
 
 class Command(BaseCommand):
@@ -309,6 +317,8 @@
 default=True, help="Don't ignore the common glob-style patterns 
'CVS', '.*' and '*~'."),
 make_option('--no-wrap', action='store_true', dest='no_wrap',
 default=False, help="Don't break long message lines into several 
lines"),
+make_option('--no-obsolete', action='store_true', dest='no_obsolete',
+default=False, help="Remove obsolete message strings"),
 )
 help = "Runs over the entire source tree of the current directory and 
pulls out all strings marked for translation. It creates (or updates) a message 
file in the conf/locale (in the django tree) or locale (for project and 
application) directory."
 
@@ -330,7 +340,7 @@
 ignore_patterns += ['CVS', '.*', '*~']
 ignore_patterns = list(set(ignore_patterns))
 no_wrap = options.get('no_wrap')
-
+no_obsolete = options.get('no_obsolete')
 if domain == 'djangojs':
 extensions = handle_extensions(extensions or ['js'])
 else:
@@ -340,4 +350,4 @@
 sys.stdout.write('examining files with the extensions: %s\n'
  % get_text_list(list(extensions), 'and'))
 
-make_messages(locale, domain, verbosity, process_all, extensions, 
symlinks, ignore_patterns, no_wrap)
+make_messages(locale, domain, verbosity, process_all, extensions, 
symlinks, ignore_patterns, no_wrap, no_obsolete)

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

[Django]

#15103: Django 1.2.4 breaks limit_choices_to for raw_id_fields
---+
  Reporter:  natrius   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  django.contrib.admin  |   Version:  1.2
   
Resolution:|  Keywords:  blocker regression 
send_mail email
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by lukeplant):

 I have attached a patch which fixes the issue, for another pair of eyes to
 review. For the reason given above, I have implemented it so that only the
 exact lookup specified in the limit_choices_to is allowed. The only
 problem is that this involves passing the value to the
 `ModelAdmin.lookup_allowed` method, thus changing its signature. Due to
 the breakage in 1.2.4, people are already using the lookup_allowed method
 (e.g. http://www.hoboes.com/Mimsy/hacks/fixing-django-124s-
 suspiciousoperation-filtering/ ), so we need to think what to do about
 that.

 Just using a keyword argument won't make it compatible with the example
 linked, although it would reduce comeback - we can say that you should
 always use `**kwargs` when overriding a method that isn't documented.
 Technically `lookup_allowed` it isn't documented, so we are allowed to
 change the signature. But we should at least put a note in the release
 notes, so that people don't get yet more breakage with this. Alternatively
 we could add another method like `lookup_allowed_value`, or move the added
 code to the calling method.

 I did not yet fix #14880, but I'm pretty sure that the newly extracted
 'url_params_from_lookup_dict' function is the place to do it. I did take
 the opportunity to fix various unicode bugs in the existing code (it
 produced !UnicodeDecodeError on template render if `limit_choices_to`
 contained non-ASCII chars, for example).

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

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

Re: [Django] #9532: min_num on formsets

[Django]

#9532: min_num on formsets
-+--
  Reporter:  gsf | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by charliebubblegum):

 double +1. This was very hard for me to work around, and would be a very
 logical 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] #15067: base36_to_int returns a long in certain situations

[Django]

#15067: base36_to_int returns a long in certain situations
-+--
  Reporter:  Garthex | Owner:  nobody 
Status:  new | Milestone:  1.3
 Component:  Core framework  |   Version:  1.2
Resolution:  |  Keywords:  blocker
 Stage:  Accepted| Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by ramiro):

  * keywords:  => blocker
  * milestone:  => 1.3

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

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

[Changeset] r15257 - django/trunk/tests

[noreply]

Author: ramiro
Date: 2011-01-21 09:55:27 -0600 (Fri, 21 Jan 2011)
New Revision: 15257

Modified:
   django/trunk/tests/runtests.py
Log:
Changed name given to test applications in Django own test suite running tool 
from 'model' to 'module' or 'application'.

Modified: django/trunk/tests/runtests.py
===
--- django/trunk/tests/runtests.py  2011-01-21 02:15:13 UTC (rev 15256)
+++ django/trunk/tests/runtests.py  2011-01-21 15:55:27 UTC (rev 15257)
@@ -1,5 +1,5 @@
 #!/usr/bin/env python
-import os, subprocess, sys, traceback
+import os, subprocess, sys
 
 import django.contrib as contrib
 from django.utils import unittest
@@ -36,31 +36,31 @@
if db_dict['ENGINE'].startswith('django.contrib.gis')]
 return len(spatial_dbs) == len(settings.DATABASES)
 
-def get_test_models():
-models = []
+def get_test_modules():
+modules = []
 for loc, dirpath in (MODEL_TESTS_DIR_NAME, MODEL_TEST_DIR), 
(REGRESSION_TESTS_DIR_NAME, REGRESSION_TEST_DIR), (CONTRIB_DIR_NAME, 
CONTRIB_DIR):
 for f in os.listdir(dirpath):
 if f.startswith('__init__') or f.startswith('.') or \
f.startswith('sql') or f.startswith('invalid') or \
os.path.basename(f) in REGRESSION_SUBDIRS_TO_SKIP:
 continue
-models.append((loc, f))
-return models
+modules.append((loc, f))
+return modules
 
-def get_invalid_models():
-models = []
+def get_invalid_modules():
+modules = []
 for loc, dirpath in (MODEL_TESTS_DIR_NAME, MODEL_TEST_DIR), 
(REGRESSION_TESTS_DIR_NAME, REGRESSION_TEST_DIR), (CONTRIB_DIR_NAME, 
CONTRIB_DIR):
 for f in os.listdir(dirpath):
 if f.startswith('__init__') or f.startswith('.') or 
f.startswith('sql'):
 continue
 if f.startswith('invalid'):
-models.append((loc, f))
-return models
+modules.append((loc, f))
+return modules
 
 class InvalidModelTestCase(unittest.TestCase):
-def __init__(self, model_label):
+def __init__(self, module_label):
 unittest.TestCase.__init__(self)
-self.model_label = model_label
+self.module_label = module_label
 
 def runTest(self):
 from django.core.management.validation import get_validation_errors
@@ -68,7 +68,7 @@
 from cStringIO import StringIO
 
 try:
-module = load_app(self.model_label)
+module = load_app(self.module_label)
 except Exception, e:
 self.fail('Unable to load invalid model module')
 
@@ -130,26 +130,26 @@
 
 # Load all the test model apps.
 test_labels_set = set([label.split('.')[0] for label in test_labels])
-test_models = get_test_models()
+test_modules = get_test_modules()
 
 # If GeoDjango, then we'll want to add in the test applications
 # that are a part of its test suite.
 if geodjango(settings):
 from django.contrib.gis.tests import geo_apps
-test_models.extend(geo_apps(runtests=True))
+test_modules.extend(geo_apps(runtests=True))
 
-for model_dir, model_name in test_models:
-model_label = '.'.join([model_dir, model_name])
-# if the model was named on the command line, or
-# no models were named (i.e., run all), import
-# this model and add it to the list to test.
-if not test_labels or model_name in test_labels_set:
+for module_dir, module_name in test_modules:
+module_label = '.'.join([module_dir, module_name])
+# if the module was named on the command line, or
+# no modules were named (i.e., run all), import
+# this module and add it to the list to test.
+if not test_labels or module_name in test_labels_set:
 if verbosity >= 2:
-print "Importing model %s" % model_name
-mod = load_app(model_label)
+print "Importing application %s" % module_name
+mod = load_app(module_label)
 if mod:
-if model_label not in settings.INSTALLED_APPS:
-settings.INSTALLED_APPS.append(model_label)
+if module_label not in settings.INSTALLED_APPS:
+settings.INSTALLED_APPS.append(module_label)
 
 return state
 
@@ -163,16 +163,16 @@
 from django.conf import settings
 state = setup(verbosity, test_labels)
 
-# Add tests for invalid models.
+# Add tests for invalid models apps.
 extra_tests = []
-for model_dir, model_name in get_invalid_models():
-model_label = '.'.join([model_dir, model_name])
-if not test_labels or model_name in test_labels:
-extra_tests.append(InvalidModelTestCase(model_label))
+for module_dir, module_name in get_invalid_modules():
+module_label = '.'.join([module_dir, module_name])
+if not test_labels or module_name in 

[Django] #15141: Falcon engine for mysql is dead it was scrapped along with MySQL 6.0 branch.

[Django]

#15141: Falcon engine for mysql is dead it was scrapped along with MySQL 6.0
branch.
---+
 Reporter:  mariuz   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 On the db supported http://docs.djangoproject.com/en/1.2/ref/databases/

 "Other storage engines, including SolidDB and Falcon, are on the horizon.
 For now, InnoDB is probably your best choice."
 Should be replaced with
 "Other storage engines are on the horizon (including SolidDB) For now,
 InnoDB is probably your best choice."

-- 
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] #15126: Misleading error in ModelForm

[Django]

#15126: Misleading error in ModelForm
--+-
  Reporter:  i...@orgizm.net  | Owner:  nobody  
 
Status:  new  | Milestone:  
 
 Component:  Forms|   Version:  1.2 
 
Resolution:   |  Keywords:  modelform fields 
attributeerror widget subset
 Stage:  Accepted | Has_patch:  0   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 The "single-item tuple" bug is a frequent cause of trouble, especially for
 newcomers to Python; however, in this case, we are in a position to raise
 an error.

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

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

Re: [Django] #14820: Use `TextField` instead of `PositiveIntegerField` in docs and examples for generic relations.

[Django]

#14820: Use `TextField` instead of `PositiveIntegerField` in docs and examples 
for
generic relations.
+---
  Reporter:  mrmachine  | Owner:
   
Status:  new| Milestone:  1.3   
   
 Component:  Documentation  |   Version:  SVN   
   
Resolution: |  Keywords:  generic relation 
genericforeignkey object_id type textfield sprintdec2010
 Stage:  Accepted   | Has_patch:  1 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Comment (by claudep):

 I suggest also to add a note about adding an index to object_id. I just
 realized that slow queries in my app were related to the fact that this
 column was not indexed. I'm sure that most applications will benefit from
 this column being indexed.

-- 
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] #15128: Generic view paginator: read paginate_by from GET

[Django]

#15128: Generic view paginator: read paginate_by from GET
--+-
  Reporter:  themax...@gmail.com  | Owner:  nobody  
  
Status:  closed   | Milestone:  
  
 Component:  Generic views|   Version:  1.2 
  
Resolution:  wontfix  |  Keywords:  generic view 
paginator
 Stage:  Unreviewed   | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 I'm not convinced this is something important enough that it should be
 baked into the core API.

 The current page is indisputably an issue of access -- I need the third
 page of results. Choosing 10 items per page rather than 15 or 100 is a
 matter of design, and shouldn't be (by default) exposed to the end-user.

 If you want to enable this functionality, you can implement a
 get_paginate_by() method that calls on self.request.GET.get('paginate_by).
 That means that what you describe is possible, just not baked in by
 default.

-- 
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] #15131: pg_service.conf support

[Django]

#15131: pg_service.conf support
---+
  Reporter:  valczir.darkv...@gmail.com| Owner:  nobody 

Status:  closed| Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  1.2

Resolution:  wontfix   |  Keywords:  
postgresql, pg_service, pg_service.conf
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I'm not sure I see the benefit here. It's certainly nice that Postgres
 provides a way to perform the abstraction that you describe, but I'm not
 sure I see the advantage that is gained by having Django support it. It
 would be a configuration scheme that only works for Postgres -- no other
 backend (that I'm aware of) has an analogous configuration scheme. This
 means that the cross-database nature of Django would be somewhat
 compromised -- we would have a DATABASES setting that only works for
 Postgres.

 Closing wontfix; please start a discussion on django-dev if you feel
 strongly about this.

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

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

Re: [Django] #15132: The runserver command is missing --verbosity and --traceback

[Django]

#15132: The runserver command is missing --verbosity and --traceback
+---
  Reporter:  cardonbj   | Owner:  nobody
Status:  closed | Milestone:
 Component:  django-admin.py runserver  |   Version:  1.2   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 Marking wontfix because I'm having difficulty thinking of what either
 option would actually do.

 I can't think of a change we could make that would increase the verbosity
 of the development server -- it already reports every request that hits
 it.

 As for tracebacks -- server errors are caught and returned as 500s, but
 that's at a layer of abstraction deeper than the runserver command.

 I'm happy to entertain the general principle of "more debug is better",
 but in this case, I would need to see the specific change that is being
 proposed.

-- 
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] #15133: :ref: directive in docs where :doc: directive should be used

[Django]

#15133: :ref: directive in docs where :doc: directive should be used
+---
  Reporter:  Aryeh Leib Taurog   | Owner:  
nobody
Status:  new| Milestone:

 Component:  Documentation  |   Version:  
SVN   
Resolution: |  Keywords:

 Stage:  Accepted   | Has_patch:  0 

Needs_docs:  0  |   Needs_tests:  0 

Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 Confirmed; this appears to be a recent change, because Sphinx 1.0.7
 reports the error, but Sphinx 1.0.5 didn't.

-- 
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] #15134: modelforms documentation appears twice in doctree

[Django]

#15134: modelforms documentation appears twice in doctree
+---
  Reporter:  Aryeh Leib Taurog   | Owner:  
nobody
Status:  new| Milestone:

 Component:  Documentation  |   Version:  
1.2   
Resolution: |  Keywords:

 Stage:  Ready for checkin  | Has_patch:  0 

Needs_docs:  0  |   Needs_tests:  0 

Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Ready for checkin

Comment:

 Marking RFC because the fix is a trivial 1 line deletion.

-- 
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] #15138: Error in documentation simple_tag decorator.

[Django]

#15138: Error in documentation simple_tag decorator.
+---
  Reporter:  elbarto| Owner:  elbarto
Status:  new| Milestone: 
 Component:  Documentation  |   Version: 
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  1  |  
+---
Changes (by russellm):

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

Comment:

 Accepted that the example is at least slightly ambiguous; however, the
 ambiguity should be fixed by using the argument, not by removing it. The
 point of the example is to demonstrate that "context" must be the first
 argument, not to say that you can't have other arguments.

-- 
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] #15139: Admin delete_view don't use per object permissions backends

[Django]

#15139: Admin delete_view don't use per object permissions backends
---+
  Reporter:  msaelices | Owner:  msaelices
Status:  new   | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:|  Keywords:   
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  1
Needs_better_patch:  1 |  
---+
Changes (by russellm):

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

Comment:

 The admin needs to undergo a broad permission audit; I'm not convinced
 that per-object permissions are being honored everywhere that they should
 be. This is one example of the problem.

-- 
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] #15140: Allow redefining object to delete collector in Django admin

[Django]

#15140: Allow redefining object to delete collector in Django admin
---+
  Reporter:  msaelices | Owner:  msaelices
Status:  closed| Milestone:   
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:  wontfix   |  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I'm with Alex - I don't see the use case here. THe list of objects to be
 deleted isn't a matter of debate or control; it's a direct consequence of
 the delete cascading rules.

 If you want to advocate for this change, please start a discussion on
 django-dev.

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

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

Re: [Django] #15130: Model.validate_unique method doesn't take in account multi-db

[Django]

#15130: Model.validate_unique method doesn't take in account multi-db
--+-
  Reporter:  t2y  | Owner:  
Status:  closed   | Milestone:  1.3 
 Component:  ORM aggregation  |   Version:  1.2 
Resolution:  worksforme   |  Keywords:  multi-db
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  1   
Needs_better_patch:  0|  
--+-
Changes (by ramiro):

  * status:  new => closed
  * resolution:  => worksforme
  * summary:  Model.validate_unique method is not considered with multi-db
  => Model.validate_unique method doesn't take in
  account multi-db

Comment:

 I've added tests (against trunk) that exercise the `unique` and
 `unique_for_(date,month,year)` field options plus the
 `Meta.unique_together` option by saving identical model instances to
 different databases. Saving is successful so I can't reproduce this at the
 ORM level.

 I'm going to close this ticket as ''works for me''. If you can describe
 better your use case (bonus points if they are a modification to the
 attached tests) your scenario, please reopen. I suspect this might be a
 problem in another part of the stack (admin app?) instead, or maybe I
 forgot to test some condition?.

-- 
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] #15140: Allow redefining object to delete collector in Django admin

[Django]

#15140: Allow redefining object to delete collector in Django admin
---+
  Reporter:  msaelices | Owner:  msaelices
Status:  new   | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 Why?  What's the usecase here.

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

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

Re: [Django] #15130: Model.validate_unique method is not considered with multi-db

[Django]

#15130: Model.validate_unique method is not considered with multi-db
--+-
  Reporter:  t2y  | Owner:  
Status:  new  | Milestone:  1.3 
 Component:  ORM aggregation  |   Version:  1.2 
Resolution:   |  Keywords:  multi-db
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  1   
Needs_better_patch:  0|  
--+-
Changes (by ramiro):

  * stage:  Unreviewed => Accepted

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

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

Re: [Django] #15140: Allow redefining object to delete collector in Django admin

[Django]

#15140: Allow redefining object to delete collector in Django admin
---+
  Reporter:  msaelices | Owner:  msaelices
Status:  new   | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by msaelices):

  * owner:  nobody => msaelices

-- 
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] #15140: Allow redefining object to delete collector in Django admin

[Django]

#15140: Allow redefining object to delete collector in Django admin
---+
  Reporter:  msaelices | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by msaelices):

 Note that the only lines I've changed in patch was this:
 {{{
 #!python
 def get_deleted_objects(objs, opts, user, admin_site, using):
 """ ... """
 collector = NestedObjects(using=using)
 }}}

 To this:
 {{{
 #!python

 def get_deleted_objects(objs, opts, user, admin_site, using,
 collector_class=NestedObjects):
 """ ... """
 collector = collector_class(using=using)
 }}}

 The other changes (marked in green and red in patch) are due because I
 have to move up the {{{NestedObjects}}} implementation to be accesible by
 the {{{get_deleted_objects}}} function.

-- 
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] #13609: Using a non existent template in admin.Inlines produce error when posting the form

[Django]

#13609: Using a non existent template in admin.Inlines produce error when 
posting
the form
---+
  Reporter:  kunitoki  | Owner:  ojii   

Status:  new   | Milestone:  1.3

 Component:  django.contrib.admin  |   Version:  1.2-beta   

Resolution:|  Keywords:  Inline custom 
template ValidationError ManagementForm data missing tampered
 Stage:  Ready for checkin | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by jezdez):

  * 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] #15140: Allow redefining object to delete collector in Django admin

[Django]

#15140: Allow redefining object to delete collector in Django admin
---+
  Reporter:  msaelices | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by msaelices):

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

Comment:

 With this patch you can do something like this:
 {{{
 #!python

 class FooModelAdmin(admin.ModelAdmin):
 # ...
 def delete_view(self, request, object_id, extra_context=None):
 # ...

 (deleted_objects, perms_needed, protected) = get_deleted_objects(
 [obj], opts, request.user, self.admin_site, using,
 collector_class=CustomNestedObjects)

 # ...
 }}}

-- 
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] #12306: Checkbox (label, field) ordering

[Django]

#12306: Checkbox (label, field) ordering
-+--
  Reporter:  EoghanM | Owner:  nobody   
  
Status:  new | Milestone:   
  
 Component:  Forms   |   Version:  1.1  
  
Resolution:  |  Keywords:  label checkbox 
BooleanField
 Stage:  Design decision needed  | Has_patch:  0
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by poswald):

 You might want to look into this Django library which allows you to
 override the html of any form field: https://github.com/brutasse/django-
 floppyforms

 More generally, it might make sense to incorporate that library into
 Django itself to allow users to apply their own markup preferences. It
 uses the django templating system to define the html and substitutes the
 field values in. The application creates html5-typed input elements but it
 could easily be used to output html in the current html 4 style by
 default. Can someone on the core team can make a call as to if this
 approach is acceptable?

-- 
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] #15140: Allow redefining object to delete collector in Django admin

[Django]

#15140: Allow redefining object to delete collector in Django admin
--+-
 Reporter:  msaelices |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 {{{ModelAdmin}}} should be able to redefining easily the objects to delete
 collector.

-- 
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] #15139: Admin delete_view don't use per object permissions backends

[Django]

#15139: Admin delete_view don't use per object permissions backends
---+
  Reporter:  msaelices | Owner:  msaelices
Status:  new   | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by msaelices):

  * needs_better_patch:  => 0
  * component:  Uncategorized => django.contrib.admin
  * 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] #15139: Admin delete_view don't use per object permissions backends

[Django]

#15139: Admin delete_view don't use per object permissions backends
---+
 Reporter:  msaelices  |   Owner:  msaelices 
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The admin delete confirmation view should use permissions per objects.
 Only uses the object model to check if user has or not permissions to
 delete the object.

-- 
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] #11559: urlresolvers.reverse do not work with namespaced urls and captured parameters in parent urlconf

[Django]

#11559: urlresolvers.reverse do not work with namespaced urls and captured
parameters in parent urlconf
+---
  Reporter:  kmik...@gmail.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  Core framework |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Someday/Maybe  | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Comment (by chipx86):

 Curious if there's been any further discussion with this change. I've been
 trying to deploy an instance of the admin UI with a dynamic prefix
 (basically, hosting instances of a webapp grouped by some identifier), and
 have a custom subclass of AdminSite that can take the parameters and do
 the right thing.

 Now, this works, except that reversing admin URLs fails because of the way
 namespaces and captured arguments in the prefix of the URL works. This
 behavior has actually delayed our launch by about a week, so I'm eager to
 find a solution of some sort. I think where things seem confusing is that
 namespaced URLs just do not work the way standard URLs do.

 I played around with a couple patch ideas. One thing off the top of my
 head would be to have the namespaces dictionary build up the possible
 matches in place of the raw prefix. In a sense, it'd act like
 reverse_dict, except keyed off by namespace. Then the right possibilities
 could be received based on namespace.

 The trick at that point would be to pass that information to
 RegexURLResolver.reverse. Maybe the namespace could be passed to it, or
 the list of possibilities to use instead of those in reverse_dict.

 Or I may be on totally the wrong path. However, from the CC list and my
 own experiences, it doesn't seem that the current design is really
 sufficient for more advanced use, and I'd be happy to work on this but
 want to make sure I'm not about to waste any time by going in a direction
 you guys don't want to go in.

-- 
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] #15106: label[for] attributes aren't updated when dynamically creating new inlines

[Django]

#15106: label[for] attributes aren't updated when dynamically creating new 
inlines
---+
  Reporter:  mk| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by mk):

 Both problems affect the inline javascript code, but the issues are
 different.

 As I understand it, #14830 covers the problem that
 input[type=radio] elements are inserted too early into the DOM (before all
 IDs and NAMEs are changed). This ticket covers the problem that not all
 attributes which should be unique are updated properly, in this case the
 FOR attribute of label tags.

 Maybe both bugs should be resolved at the same time, but that's not for me
 to decide.

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