[Django] #13350: Documentation on autoescape should mention endautoescape

[Django]

#13350: Documentation on autoescape should mention endautoescape
+---
 Reporter:  mountainp...@gmail.com  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Documentation   | Version:  1.1   
 Keywords:  autoescape  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 The page on the
 [http://docs.djangoproject.com/en/dev/ref/templates/builtins/#autoescape]
 autoescape tag should mention that it has to be closed with an
 {% endautoescape %)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #11675: [patch] Support new memcached wrapper pylibmc

[Django]

#11675: [patch] Support new memcached wrapper pylibmc
--+-
  Reporter:  pipp...@yahoo.co.jp  | Owner:  otherjacob  
  
Status:  assigned | Milestone:  1.3 
  
 Component:  Cache system |   Version:  SVN 
  
Resolution:   |  Keywords:  cache pylibmc 
memcached.py
 Stage:  Accepted | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Comment (by gabrielhurley):

 Replying to [comment:12 mmalone]:
 > pylibmc raises pylibmc.NotFound if you incr/decr a key that doesn't
 exist while the other Python clients raise ValueError. I'm pretty sure
 this will break the Django memcache backend for incr/decr operations.

 If necessary, it should be easy enough to catch that and then re-raise a
 ValueError to be consistent. Django certainly does that to maintain
 consistency in other places (such as for errors raised by different db
 backends).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13334: Importing template tags from an egg fails

[Django]

#13334: Importing template tags from an egg fails
--+-
  Reporter:  joerg86  | Owner:  nobody
Status:  new  | Milestone:  1.2   
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  1 
Needs_better_patch:  0|  
--+-
Comment (by kmtracey):

 One last thing -- the earlier patch took the approach of trying the import
 first, and only if that failed did it attempt to ascertain if the module
 even had the requested submodule. That may be a better approach than the
 way that seemed more natural to me: figure out if the module has the
 requested submodule, and only if it does try the import. The reason I
 think the try-the-import first approach might be better is that the
 function to figure out if the module has the submodule may be fragile.
 I've tested it with eggs and and regular modules, but if there are other
 loaders out there that do not exactly match what the zipimporter one does,
 then that routine may not come up with the right answer. If we try the
 import first and only check for the submodule if that fails, the effect of
 getting a wrong answer on whether the submodule exists is limited to an
 error-handling path. With the reverse we stand a chance of refusing to try
 to import something that may import just fine, simply because we couldn't
 properly figure out if the submodule exists in the module.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13334: Importing template tags from an egg fails

[Django]

#13334: Importing template tags from an egg fails
--+-
  Reporter:  joerg86  | Owner:  nobody
Status:  new  | Milestone:  1.2   
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  1 
Needs_better_patch:  0|  
--+-
Comment (by kmtracey):

 Attached a patch with tests that uses the utility function from the patch
 on #13348.

 While the earlier patch works to load valid tags from eggs, the case where
 it does not work is where there is an egg with a templatetags module, but
 attempting to import it raises an !ImportError. With the earlier patch
 this case gets reported indicating that the tag library could not be found
 ("'broken_egg' is not a valid tag library: Template library broken_egg not
 found, tried
 django.templatetags.broken_egg,tagsegg.templatetags.broken_egg") instead
 of properly indicating what the real problem is ("'broken_egg' is not a
 valid tag library: !ImportError raised loading
 tagsegg.templatetags.broken_egg: cannot import name Xtemplate").

 This patch also changes from raising a bare !ImportError to
 !TemplateSyntaxError. That makes the debug page include a the snippet from
 the template that has caused the problem, and restores much of the text
 that used to be in the error message for this case (minus the misleading
 identification of where the templatetags module was supposedly located.
 The text of the message could maybe be improved but I'm too tired for that
 just now.)

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

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

[Django]

#13119: Can't pickle queryset
---+
  Reporter:  anentropic| Owner:  nobody 

Status:  closed| Milestone: 

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

Resolution:  worksforme|  Keywords:  querySet 
pickle
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 I can't reproduce the problem reported by @ashchristopher on r12974. I
 used the following test in the queryset_pickle regression test:
 {{{
 def test_related_field_by_query(self):
 Group.objects.create(name="Ponies Who Own Maybachs")
 g = Group.objects.all()[0]
 self.assert_pickles(Event.objects.filter(group=g))
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 #13343 reported the same problem, but with an effect in m2m relations.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13343: Wrong behavior of ManyToMany relationship while using 'trough' in ManyToManyField and 'db_column' and 'to_field' properties in intermediate model

[Django]

#13343: Wrong behavior of ManyToMany relationship while using 'trough' in
ManyToManyField  and 'db_column' and 'to_field' properties in intermediate
model
---+
  Reporter:  twil  | Owner:  nobody  
Status:  closed| Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta
Resolution:  duplicate |  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 Confirmed; exists in 1.1. On closer inspection, appears to be a duplicate
 of #11319. Thanks to Ramiro for doing the leg work.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13348: After r12950, load_app does not return models modules from eggs

[Django]

#13348: After r12950, load_app does not return models modules from eggs
---+
  Reporter:  kmtracey  | Owner:  nobody
Status:  new   | Milestone:  1.2   
 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):

  * 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #10809: mod_wsgi authentication handler

[Django]

#10809: mod_wsgi authentication handler
-+--
  Reporter:  baumer1122  | Owner:  davidfischer
Status:  assigned| Milestone:  
 Component:  Authentication  |   Version:  SVN 
Resolution:  |  Keywords:  mod_wsgi
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by grahamd):

 Relevant to this is a recent discussion on mod_wsgi mailing list. See:

 http://groups.google.com/group/modwsgi/browse_frm/thread/42e2d356d4eac415

 This actually talks about authorization as distinct from authentication.

 The original mod_python handler actually mixed the two when it shouldn't
 have.

 In mod_wsgi one can properly separate the two and better integrate with
 Apache authentication mechanism and location based requirements on group
 membership.

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

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

[Django]

#373: Add support for multiple-column primary keys
---+
  Reporter:  jacob | Owner:  dcramer 
Status:  assigned  | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  
Resolution:|  Keywords:  database
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by spaceriqui):

 * cc: spaceriqui (added)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12421: Foreign Key on Non-Primary Field fails due to lack of Index on Related Field w/ MySQL

[Django]

#12421: Foreign Key on Non-Primary Field fails due to lack of Index on Related
Field w/ MySQL
---+
  Reporter:  anonymous | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  worksforme|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 I tset this (using a `t12421` app) and MySQL 5.0 by creating only the
 `Relation` model, the sqlall output shows the index is correctly being
 created:

 {{{
 r...@host:~/src/dtest08$ PYTHONPATH=~/django/trunk ./manage.py sqlall t12421
 BEGIN;
 CREATE TABLE `relation_codes` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `code` varchar(2) NOT NULL
 )
 ;
 CREATE INDEX `relation_codes_code` ON `relation_codes` (`code`);
 COMMIT;
 }}}

 The index is being created.

 I suspect you might have added the `db_index=True` to the `code` field of
 `Relation` after the `relation_codes` table was created. Remember `syncdb`
 works with a model-level granularity to create tables; if you need you
 will need to devise or use a third-party schema migration tool.

 Another probable (although a weird one )reason for the index not being
 present is if MySQL isn't creating it even if is is being told to do so.
 But we 'd need more details about the setup.

 Closing this as worksforme. Please reopen if you can provide more details
 and a a detailed sequence to reproduce this, or if I missed something.

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

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

[noreply]

Author: kmtracey
Date: 2010-04-14 16:27:21 -0500 (Wed, 14 Apr 2010)
New Revision: 12975

Modified:
   django/branches/releases/1.1.X/
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/bar.py
Log:
[1.1.X] Fixed Python 2.4 incompatibility introduced in r12973.

r12947 from trunk.



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11729,11732,11734,11739-11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12171,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12398,12405,12408-12411,12419-12420,12423,12425-12426,12429,12434,12436,12439-12442,12447-12448,12457,12461-12464,12467,12471,12473,12475,12484,12489-12490,12492,12497-12498,12502,12505,12513,12515-12516,12518,12523,12525-12526,12528,12533,12535,12537,12539,12541,12548,12551,12553,12556,12558-12560,12562,12567,12569-12570,12573,12576,12579,12581,12584,12598-12599,12602,12605,12614,12616,12621-12622,12627,12630-12631,12635,12637,12639,12641,12644,12646,12648,12650,12652,12654,12657,12659,12661,12663,12665,12667,12669,12671,12673,12676,12679,12681,12683,12686,12688,12694,12696,12698,12700,12704-12705,12710-12712,12719,12721,12723,12725-12726,12728,12733-12734,12737,12739,12741,12743,12757,12759,12764,12766,12768,12771,12774,12778,12780,12782,12788,12795,12798,12800,12806,12808,12811,12813,12817,12819,12821,12823,12825,12828,12830,12832,12834,12836,12838,12840,12842,12846,12848,12850,12852,12854,12858,12860,12862,12868,12878,12880,12883,12885,12891,12893,12896,12898,12901,12905,12908,12910,12912,12916,12918,12920,12924,12926,12928,12930,12932,12934,12941,12948,12950,12956,12972
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11729,11732,11734,11739-11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12171,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12398,12405,12408-12411,12419-12420,12423,12425-12426,12429,12434,12436,12439-12442,12447-12448,12457,12461-12464,12467,12471,12473,12475,12484,12489-12490,12492,12497-12498,12502,12505,12513,12515-12516,12518,12523,12525-12526,12528,12533,12535,12537,12539,12541,12548,12551,12553,12556,12558-12560,12562,12567,12569-12570,12573,12576,12579,12581,12584,12598-12599,12602,12605,12614,12616,12621-12622,12627,12630-12631,12635,12637,12639,12641,12644,12646,12648,12650,12652,12654,12657,12659,12661,12663,12665,12667,12669,12671,12673,12676,12679,12681,12683,12686,12688,12694,12696,12698,12700,12704-12705,12710-12712,12719,12721,12723,12725-12726,12728,12733-12734,12737,12739,12741,12743,12757,12759,12764,12766,12768,12771,12774,12778,12780,12782,12788,12795,12798,12800,12806,12808,12811,12813,12817,12819,12821,12823,12825,12828,12830,12832,12834,12836,12838,12840,12842,12846,12848,12850,12852,12854,12858,12860,12862,12868,12878,12880,12883,12885,12891,12893,12896,12898,12901,12905,12908,12910,12912,12916,12918,12920,12924,12926,12928,12930,12932,12934,12941,12948,12950,12956,12972,12974

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/bar.py
===
--- 
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/bar.py
2010-04-14 21:23:43 UTC (rev 12974)
+++ 
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/bar.py
2010-04-14 21:27:21 UTC (rev 12975)
@@ -1,6 +1,6 @@
 from django.db import models
 
-fro

[Changeset] r12974 - django/trunk/tests/regressiontests/admin_scripts/complex_app/models

[noreply]

Author: kmtracey
Date: 2010-04-14 16:23:43 -0500 (Wed, 14 Apr 2010)
New Revision: 12974

Modified:
   django/trunk/tests/regressiontests/admin_scripts/complex_app/models/bar.py
Log:
Fixed Python 2.4 incompatibility introduced in r12972.


Modified: 
django/trunk/tests/regressiontests/admin_scripts/complex_app/models/bar.py
===
--- django/trunk/tests/regressiontests/admin_scripts/complex_app/models/bar.py  
2010-04-14 19:14:23 UTC (rev 12973)
+++ django/trunk/tests/regressiontests/admin_scripts/complex_app/models/bar.py  
2010-04-14 21:23:43 UTC (rev 12974)
@@ -1,6 +1,6 @@
 from django.db import models
 
-from ..admin import foo
+from admin_scripts.complex_app.admin import foo
 class Bar(models.Model):
 name = models.CharField(max_length=5)
 class Meta:

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13334: Importing template tags from an egg fails

[Django]

#13334: Importing template tags from an egg fails
--+-
  Reporter:  joerg86  | Owner:  nobody
Status:  new  | Milestone:  1.2   
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  1 
Needs_better_patch:  0|  
--+-
Comment (by kmtracey):

 Does the attached patch really work for the template tag case? In trying
 the approach from that 3rd patch on #9427 for #13348, I could not get it
 to work. `sys.path_importer_cache` appears to contain stuff under keys
 slightly different from what is expected there. For example if I load an
 app from an egg:

 {{{
 >>> import sys
 >>> from django.utils.importlib import import_module
 >>> mod = import_module('app_with_models')
 >>> mod
 
 >>> mod.__file__
 '/home/kmt/software/web/playground/modelapp.egg/app_with_models/__init__.py'
 >>> mod.__path__
 ['/home/kmt/software/web/playground/modelapp.egg/app_with_models']
 }}}

 `mod.__path__[0]` contains both the egg file name and then the package
 name. This is not found in `sys.path_importer_cache`:

 {{{
 >>> sys.path_importer_cache[mod.__path__[0]]
 Traceback (most recent call last):
   File "", line 1, in 
 KeyError: '/home/kmt/software/web/playground/modelapp.egg/app_with_models'
 }}}

 Instead the key you need to use is one with just the full path of the egg:

 {{{
 >>>
 sys.path_importer_cache['/home/kmt/software/web/playground/modelapp.egg']
 
 }}}

 Which seems to be more easily found via `mod.__loader__`:

 {{{
 >>> mod.__loader__
 
 }}}

 Then, once you have that thing, its `find_module` is not quite equivalent
 to `imp.find_module`. It (at least the zipimport one) has differences
 deeper than whether it raises an !ImportError or returns None on failure
 to find the requested submodule.

 [http://docs.python.org/library/imp.html#imp.find_module The imp version]
 does not handle hierarchical (dotted) names in its first argument -- so we
 pass in 'models', for example, as the 1st arg and the module's path list
 as the 2nd arg and 'models' is found by `imp.find_module`.

 
[http://docs.python.org/library/zipimport.html#zipimport.zipimporter.find_module
 The zipimport version] on the other hand requires a heirarchical path in
 its first arg, and ignores its 2nd arg. It claims it wants dotted path
 names in the first arg but the only thing that seems to actually work is
 `os.sep`:

 {{{
 >>> mod.__loader__.find_module('models')
 >>> mod.__loader__.find_module('app_with_models.models')
 >>> mod.__loader__.find_module('app_with_models/models')
 
 }}}

 (On Windows that last would not work, what would work would be
 `mod.__loader__.find_module('app_with_models\\models')`.)

 Given that behavior, I'm having a hard time believing that the approach in
 the patch here really works? But I could be missing something...?

 I put a patch on #13348 that attempts to create a general utility function
 for answering the question of whether a loaded module has a named
 submodule. At any rate it works in my testing for finding (or not) models
 modules in apps loaded from eggs.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13343: Wrong behavior of ManyToMany relationship while using 'trough' in ManyToManyField and 'db_column' and 'to_field' properties in intermediate model

[Django]

#13343: Wrong behavior of ManyToMany relationship while using 'trough' in
ManyToManyField  and 'db_column' and 'to_field' properties in intermediate
model
---+
  Reporter:  twil  | Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 I see this in 1.1 too.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13349: Raw Queries with backends that don't support chunked reads aren't done correctly

[Django]

#13349: Raw Queries with backends that don't support chunked reads aren't done
correctly
---+
  Reporter:  Alex  | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13349: Raw Queries with backends that don't support chunked reads aren't done correctly

[Django]

#13349: Raw Queries with backends that don't support chunked reads aren't done
correctly
--+-
 Reporter:  Alex  |   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 If a backend doesn't support chunked reads the cursor should be exhausted
 immediately.  This leads to bugs in PyPy, and probably other non-cpython
 systems.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13348: After r12950, load_app does not return models modules from eggs

[Django]

#13348: After r12950, load_app does not return models modules from eggs
---+
  Reporter:  kmtracey  | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 The eggs are supposed to be in the diff but they're not. They're supposed
 to go under tests/regressiontests/app_loading/eggs.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13348: After r12950, load_app does not return models modules from eggs

[Django]

#13348: After r12950, load_app does not return models modules from eggs
--+-
 Reporter:  kmtracey  |   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 #13334 points out a problem loading template tags from eggs. Since the
 change (to use `imp.find_module`) that introduced that problem was the
 inspiration for r12950, the r12950 code has the same problem, only for
 r12950 the problem involves loading models modules from apps in eggs.
 Ramiro pointed to a patch on #9427 that attempts to find modules loaded by
 eggs, but I could not quite get that code to work. I'll attach a patch
 that I did get to work, with tests. This patch introduces a utility
 function to answer the question: does this loaded module have a submodule
 named x? This seems to be something we could use in a few places.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13343: Wrong behavior of ManyToMany relationship while using 'trough' in ManyToManyField and 'db_column' and 'to_field' properties in intermediate model

[Django]

#13343: Wrong behavior of ManyToMany relationship while using 'trough' in
ManyToManyField  and 'db_column' and 'to_field' properties in intermediate
model
---+
  Reporter:  twil  | Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by twil):

 New, stripped down and abstract version of models:
 {{{
 #!python
 from django.db import models

 class Item(models.Model):
 unique_field = models.IntegerField(unique = True)
 title = models.CharField(max_length = 10)

 class Group(models.Model):
 title = models.CharField(max_length = 10)
 members = models.ManyToManyField('Item', through = 'GroupItem')

 class GroupItem(models.Model):
 item = models.ForeignKey('Item', to_field = 'unique_field')
 group = models.ForeignKey('Group')
 title = models.CharField(max_length = 10)
 }}}

 and shell test sequence of commands:
 {{{
 #!text
 Python 2.5.2 (r252:60911, Jan  4 2009, 17:40:26)
 [GCC 4.3.2] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from testm2m.m2m.models import *
 >>> item1 = Item.objects.create(unique_field = 100, title = 'Item')
 >>> group1 = Group.objects.create(title = 'Group')
 >>> membership = GroupItem.objects.create(item = item1, group = group1,
 title = 'Membership')
 >>> membership.save()
 >>> group1.members.all()
 []
 >>> from django.db import connection
 >>> connection.queries
 [{'time': '0.002', 'sql': u'INSERT INTO "m2m_item" ("unique_field",
 "title") VALUES (100, Item)'}, {'time': '0.001', 'sql': u'INSERT INTO
 "m2m_group" ("title") VALUES (Group)'}, {'time': '0.001', 'sql': u'INSERT
 INTO "m2m_groupitem" ("item_id", "group_id", "title") VALUES (100, 1,
 Membership)'}, {'time': '0.000', 'sql': u'SELECT (1) AS "a",
 "m2m_groupitem"."id", "m2m_groupitem"."item_id",
 "m2m_groupitem"."group_id", "m2m_groupitem"."title" FROM "m2m_groupitem"
 WHERE "m2m_groupitem"."id" = 1  LIMIT 1'}, {'time': '0.001', 'sql':
 u'UPDATE "m2m_groupitem" SET "item_id" = 100, "group_id" = 1, "title" =
 Membership WHERE "m2m_groupitem"."id" = 1 '}, {'time': '0.000', 'sql':
 u'SELECT "m2m_item"."id", "m2m_item"."unique_field", "m2m_item"."title"
 FROM "m2m_item" INNER JOIN "m2m_groupitem" ON ("m2m_item"."id" =
 "m2m_groupitem"."item_id") WHERE "m2m_groupitem"."group_id" = 1  LIMIT
 21'}]
 }}}

 PS: I've tried to make patch but couldn't find right place in django code
 :( I'll try tomorrow again.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13327: FileField/ImageField accessor methods throw unnecessary exceptions when they are blank or null.

[Django]

#13327: FileField/ImageField accessor methods throw unnecessary exceptions when
they are blank or null.
---+
  Reporter:  kevin.hower...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Uncategorized |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Apreche):

 I completely agree that this needs to change.

 If you set an Image or File Field to blank/null, then it is expected that
 there will often be no actual file in the file system. Obviously if there
 is an operation that requires reading the file from the file system, such
 as checking the size of the file, then it is obvious that there would be
 IO errors or file not found exceptions. However, for operations such as
 getting the path or url, there is no reason to check the file system at
 all. If the field is null, then these operations should simply return
 None.

 As the submitter has pointed out, the current system requires that you put
 conditionals around every image field in every template in order to avoid
 errors that prevent the entire page from loading just because one image is
 missing. With the suggested change, the pages would load without error,
 and maybe a few relatively harmless broken images.

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

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

[noreply]

Author: kmtracey
Date: 2010-04-14 14:14:23 -0500 (Wed, 14 Apr 2010)
New Revision: 12973

Added:
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/admin/
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/admin/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/admin/foo.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/bar.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/foo.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/simple_app/
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/simple_app/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/simple_app/models.py
Removed:
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/admin/
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/admin/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/admin/foo.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/bar.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/complex_app/models/foo.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/simple_app/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/simple_app/models.py
Modified:
   django/branches/releases/1.1.X/
   django/branches/releases/1.1.X/django/db/models/loading.py
   django/branches/releases/1.1.X/tests/regressiontests/admin_scripts/tests.py
Log:
[1.1.X] Fixed #13335: Adjusted the r12950 fix to properly handle import errors 
resulting from nested calls to load_app. 



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11729,11732,11734,11739-11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12171,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12398,12405,12408-12411,12419-12420,12423,12425-12426,12429,12434,12436,12439-12442,12447-12448,12457,12461-12464,12467,12471,12473,12475,12484,12489-12490,12492,12497-12498,12502,12505,12513,12515-12516,12518,12523,12525-12526,12528,12533,12535,12537,12539,12541,12548,12551,12553,12556,12558-12560,12562,12567,12569-12570,12573,12576,12579,12581,12584,12598-12599,12602,12605,12614,12616,12621-12622,12627,12630-12631,12635,12637,12639,12641,12644,12646,12648,12650,12652,12654,12657,12659,12661,12663,12665,12667,12669,12671,12673,12676,12679,12681,12683,12686,12688,12694,12696,12698,12700,12704-12705,12710-12712,12719,12721,12723,12725-12726,12728,12733-12734,12737,12739,12741,12743,12757,12759,12764,12766,12768,12771,12774,12778,12780,12782,12788,12795,12798,12800,12806,12808,12811,12813,12817,12819,12821,12823,12825,12828,12830,12832,12834,12836,12838,12840,12842,12846,12848,12850,12852,12854,12858,12860,12862,12868,12878,12880,12883,12885,12891,12893,12896,12898,12901,12905,12908,12910,12912,12916,12918,12920,12924,12926,12928,12930,12932,12934,12941,12948,12950,12956
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11729,11732,11734,11739-11740,11748,11751,11753,11756,1

Re: [Django] #10809: mod_wsgi authentication handler

[Django]

#10809: mod_wsgi authentication handler
-+--
  Reporter:  baumer1122  | Owner:  davidfischer
Status:  assigned| Milestone:  
 Component:  Authentication  |   Version:  SVN 
Resolution:  |  Keywords:  mod_wsgi
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by ericholscher):

 Just set this up for myself and it's rather useful. Put me down for
 whatever is needed to get it into 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] r12972 - in django/trunk: django/db/models tests/regressiontests/admin_scripts tests/regressiontests/admin_scripts/complex_app tests/regressiontests/admin_scripts/complex_app/admin tests/r

[noreply]

Author: kmtracey
Date: 2010-04-14 14:10:27 -0500 (Wed, 14 Apr 2010)
New Revision: 12972

Added:
   django/trunk/tests/regressiontests/admin_scripts/complex_app/
   django/trunk/tests/regressiontests/admin_scripts/complex_app/__init__.py
   django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/
   
django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/__init__.py
   django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/foo.py
   django/trunk/tests/regressiontests/admin_scripts/complex_app/models/
   
django/trunk/tests/regressiontests/admin_scripts/complex_app/models/__init__.py
   django/trunk/tests/regressiontests/admin_scripts/complex_app/models/bar.py
   django/trunk/tests/regressiontests/admin_scripts/complex_app/models/foo.py
   django/trunk/tests/regressiontests/admin_scripts/simple_app/
   django/trunk/tests/regressiontests/admin_scripts/simple_app/__init__.py
   django/trunk/tests/regressiontests/admin_scripts/simple_app/models.py
Modified:
   django/trunk/django/db/models/loading.py
   django/trunk/tests/regressiontests/admin_scripts/tests.py
Log:
Fixed #13335: Adjusted the r12950 fix to properly handle import errors 
resulting from nested calls to load_app.


Modified: django/trunk/django/db/models/loading.py
===
--- django/trunk/django/db/models/loading.py2010-04-14 18:17:44 UTC (rev 
12971)
+++ django/trunk/django/db/models/loading.py2010-04-14 19:10:27 UTC (rev 
12972)
@@ -75,16 +75,23 @@
 app_module = import_module(app_name)
 try:
 imp.find_module('models', app_module.__path__)
+except ImportError: 
+self.nesting_level -= 1
+# App has no models module, that's not a problem.
+return None
+try:
+models = import_module('.models', app_name)
 except ImportError:
 self.nesting_level -= 1
 if can_postpone:
-# Either the app has no models, or the package is still being
+# Either the app has an error, or the package is still being
 # imported by Python and the model module isn't available yet.
 # We will check again once all the recursion has finished (in
 # populate).
 self.postponed.append(app_name)
-return None
-models = import_module('.models', app_name)
+return None
+else:
+raise
 self.nesting_level -= 1
 if models not in self.app_store:
 self.app_store[models] = len(self.app_store)

Added: django/trunk/tests/regressiontests/admin_scripts/complex_app/__init__.py
===


Property changes on: 
django/trunk/tests/regressiontests/admin_scripts/complex_app/__init__.py
___
Name: svn:eol-style
   + native

Added: 
django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/__init__.py
===


Property changes on: 
django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/__init__.py
___
Name: svn:eol-style
   + native

Added: django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/foo.py
===
--- django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/foo.py   
(rev 0)
+++ django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/foo.py   
2010-04-14 19:10:27 UTC (rev 12972)
@@ -0,0 +1,3 @@
+from django.contrib import admin
+from admin_scripts.complex_app.models.foo import Foo
+admin.site.register(Foo)


Property changes on: 
django/trunk/tests/regressiontests/admin_scripts/complex_app/admin/foo.py
___
Name: svn:eol-style
   + native

Added: 
django/trunk/tests/regressiontests/admin_scripts/complex_app/models/__init__.py
===
--- 
django/trunk/tests/regressiontests/admin_scripts/complex_app/models/__init__.py 
(rev 0)
+++ 
django/trunk/tests/regressiontests/admin_scripts/complex_app/models/__init__.py 
2010-04-14 19:10:27 UTC (rev 12972)
@@ -0,0 +1,4 @@
+from admin_scripts.complex_app.models.bar import Bar
+from admin_scripts.complex_app.models.foo import Foo
+
+__all__ = ['Foo', 'Bar']


Property changes on: 
django/trunk/tests/regressiontests/admin_scripts/complex_app/models/__init__.py
___
Name: svn:eol-style
   + native

Added: 
django/trunk/tests/regressiontests/admin_scripts/complex_app/models/bar.py
===
--- django/trunk/t

Re: [Django] #11675: [patch] Support new memcached wrapper pylibmc

[Django]

#11675: [patch] Support new memcached wrapper pylibmc
--+-
  Reporter:  pipp...@yahoo.co.jp  | Owner:  otherjacob  
  
Status:  assigned | Milestone:  1.3 
  
 Component:  Cache system |   Version:  SVN 
  
Resolution:   |  Keywords:  cache pylibmc 
memcached.py
 Stage:  Accepted | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Comment (by mmalone):

 Hey guys, just a quick comment from my experiences switching to pylibmc on
 a (non-django) project I'm working on. The transition was pretty smooth,
 the only thing I noticed that was slightly different in terms of
 implementation is that pylibmc raises pylibmc.NotFound if you incr/decr a
 key that doesn't exist while the other Python clients raise ValueError.
 I'm pretty sure this will break the Django memcache backend for incr/decr
 operations.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13335: Revision 12950 crashes complex interdependent models in directory

[Django]

#13335: Revision 12950 crashes complex interdependent models in directory
---+
  Reporter:  haras | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 OK, this last problem is straightforward circular import bug in the app
 that was mistakenly hidden by the pre-r12950 behavior of blindly
 swallowing import errors on an attempt to load an app's models. The right
 fix for that is to remove the circular import in the app, which from the
 comments above I gather has been done successfully.

 While removing all the ..admin imports from models modules may have also
 resolved the original problem described in this ticket, the report did
 bring to light that the r12950 code does not correctly handle import
 errors resulting from nested calls to load_app, so the fix in the patch is
 still necessary. Just need to add a test first

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

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

[noreply]

Author: kmtracey
Date: 2010-04-14 13:17:44 -0500 (Wed, 14 Apr 2010)
New Revision: 12971

Modified:
   django/trunk/tests/runtests.py
Log:
Fixed #13345: Don't attempt to load the locale regressiontests subdirectory as 
a Django app. Thanks ramiro.


Modified: django/trunk/tests/runtests.py
===
--- django/trunk/tests/runtests.py  2010-04-13 15:18:10 UTC (rev 12970)
+++ django/trunk/tests/runtests.py  2010-04-14 18:17:44 UTC (rev 12971)
@@ -21,6 +21,8 @@
 MODEL_TEST_DIR = os.path.join(os.path.dirname(__file__), MODEL_TESTS_DIR_NAME)
 REGRESSION_TEST_DIR = os.path.join(os.path.dirname(__file__), 
REGRESSION_TESTS_DIR_NAME)
 
+REGRESSION_SUBDIRS_TO_SKIP = ['locale']
+
 ALWAYS_INSTALLED_APPS = [
 'django.contrib.contenttypes',
 'django.contrib.auth',
@@ -37,7 +39,9 @@
 models = []
 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'):
+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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #3304: [patch] Support "httponly"-attribute in session cookie.

[Django]

#3304: [patch] Support "httponly"-attribute in session cookie.
+---
  Reporter:  arvin  | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Contrib apps   |   Version:  SVN 
Resolution: |  Keywords:  session security
 Stage:  Someday/Maybe  | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  1   
Needs_better_patch:  0  |  
+---
Changes (by Ciantic):

 * cc: Ciantic (added)

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

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

[Django]

#13347: XSS Attack prevention using HttpOnly
-+--
  Reporter:  Ciantic | Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Authentication  |   Version:  1.1 
Resolution:  duplicate   |  Keywords:  security xss
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by Ciantic):

 You know, it is. I searched using "HttpOnly" from above search bar... Now
 I noticed the search bar does not search from tickets... Sorries.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12241: Admin forgets URL used for prefilling forms when hitting Save and add another

[Django]

#12241: Admin forgets URL used for prefilling forms when hitting Save and add
another
---+
  Reporter:  velmont   | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Ready for checkin | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * milestone:  1.2 =>

Comment:

 Sorry, but 1.2 milestone is only for release-critical bugs at this point
 and this does not qualify.

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

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

[Django]

#13347: XSS Attack prevention using HttpOnly
-+--
  Reporter:  Ciantic | Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Authentication  |   Version:  1.1 
Resolution:  duplicate   |  Keywords:  security xss
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

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

Comment:

 Isn't this #3304?

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

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

[Django]

#13347: XSS Attack prevention using HttpOnly
+---
 Reporter:  Ciantic |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Authentication  | Version:  1.1   
 Keywords:  security xss|   Stage:  Unreviewed
Has_patch:  0   |  
+---
 I've just read about [http://www.codinghorror.com/blog/2008/08/protecting-
 your-cookies-httponly.html Cookie setting called "HttpOnly"], to me it
 seems like Django authentication and sessionid's should use that.

 Currently Django logs in like this (Live HTTP Headers):

 {{{
 Set-Cookie: sessionid=???; expires=Wed, 28-Apr-2010 17:48:38 GMT; Max-
 Age=1209600; Path=/
 }}}

 After that hardening it would work like this:

 {{{
 Set-Cookie: sessionid=???; expires=Wed, 28-Apr-2010 17:48:38 GMT; Max-
 Age=1209600; Path=/; HttpOnly
 }}}

 It could be option if someone ''really needs the session id'' in the
 javascript, maybe 99.9% of cases one never retrieves sessionid cookie by
 javascript so it would be wise to make this ''HttpOnly'' as 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13346: Paper help

[Django]

#13346: Paper help
---+
 Reporter:  GORDONFREE |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords:  Help   |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 You can check some [http://custom-essay-writing-service.org/custom-
 research-papers.php paper help] pages on
 [http://cvresumewritingservices.org/professional-resume.php professional
 resume] sites as well.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12241: Admin forgets URL used for prefilling forms when hitting Save and add another

[Django]

#12241: Admin forgets URL used for prefilling forms when hitting Save and add
another
---+
  Reporter:  velmont   | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Ready for checkin | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by batiste):

  * version:  1.1 => SVN
  * milestone:  => 1.2

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13340: patch for updating postgis template script for ubuntu 10.04

[Django]

#13340: patch for updating postgis template script for ubuntu 10.04
+---
  Reporter:  nesk...@gmail.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Comment (by nesk...@gmail.com):

 Perhaps there could be two scripts:

 `create_template_postgis-debian.sh` for Debian stable
 `create_template_postgis-debian-unstable.sh` for Debian unstable

 I wonder if the package maintainers would consider putting this script in
 itself, and they would maintain it, because they know exactly where those
 files are going to be, because they have the README and change it when
 necessary.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13345: error message when runing test suite after [12950]

[Django]

#13345: error message when runing test suite after [12950]
+---
  Reporter:  ramiro | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * needs_better_patch:  => 0
  * summary:  eorro message when runing test suite after [12950] => error
  message when runing test suite after [12950]
  * 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13345: eorro message when runing test suite after [12950]

[Django]

#13345: eorro message when runing test suite after [12950]
---+
 Reporter:  ramiro |   Owner:  nobody
   Status:  new|   Milestone:  1.2   
Component:  Testing framework  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 The django test suite has, besides all the regression tests, a
 `tests/regressiontests/locale` data directory used in tests that exercise
 the ability to override apps translations with project translations (this
 was added for 1.2).

 When running the site, the app loader generates a non-fatal error after
 r12950 similar to the one if generates when if finds leftover dirs in a
 SVN WC containing `.pyc` after test shuffling in the repo:

 {{{
 Error while importing locale:  File "./runtests.py", line 135, in
 django_tests
 mod = load_app(model_label)
   File "/home/r/django/trunk/django/db/models/loading.py", line 75, in
 load_app
 app_module = import_module(app_name)
   File "/home/r/django/trunk/django/utils/importlib.py", line 35, in
 import_module
 __import__(name)
 ImportError: No module named locale
 }}}

 This can also be seen in the buildbot output.

 The patch fixes this my simply skipping the directory when looping over
 the `regressiontests/` dir.

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

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

[Django]

#13119: Can't pickle queryset
---+
  Reporter:  anentropic| Owner:  nobody 

Status:  reopened  | Milestone: 

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

Resolution:|  Keywords:  querySet 
pickle
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by ashchristopher):

 Fail.

 *sigh*

 This isn't really a solution to the problem, or if it is a solution to the
 problem then the documentation on Query Sets is incomplete. Either way, I
 don't believe this is solved.

 {{{
 the_region = TripRegion.objects.all()[0]
 guides = DestinationGuide.objects.active().filter(region=the_region)
 }}}

 This statement is valid, but will not work when pickled

 {{{
 pickle.dumps(guides)

 TypeError::can't pickle function objects
 }}}

 In order to get it to work, you need to change it to:

 {{{
 the_region = TripRegion.objects.all()[0]
 guides =
 DestinationGuide.objects.active().filter(region__pk=the_region.pk)
 }}}

 I specifically get this problem when trying to cache query set results.

 It seems weird that I would have to change the way I do a lookup depending
 on whether I needed to cache the results or not.

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

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

[Django]

#13119: Can't pickle queryset
---+
  Reporter:  anentropic| Owner:  nobody 

Status:  reopened  | Milestone: 

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

Resolution:|  Keywords:  querySet 
pickle
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 PLEASE use preview (and WikiFormatting). Most of the code posted in the
 previous few updates is completely indecipherable.

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

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

[Django]

#13119: Can't pickle queryset
---+
  Reporter:  anentropic| Owner:  nobody 

Status:  reopened  | Milestone: 

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

Resolution:|  Keywords:  querySet 
pickle
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 This isn't really a solution to the problem, or if it is a solution to the
 problem then the documentation on QuerySets is wrong. Either way, I don't
 believe this is solved.


 According to documentation, this it valid:

 the_region = TripRegion.objects.all()[0]
 guides = DestinationGuide.objects.active().filter(region=the_region)

 And sure, it is a valid way to perform a QuerySet lookup, however in order
 to make use of say caching which needs to pickle the query set we
 shouldn't have to change the QS lookup to:

 guides = estinationGuide.objects.active().filter(region__pk=the_region.pk)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12241: Admin forgets URL used for prefilling forms when hitting Save and add another

[Django]

#12241: Admin forgets URL used for prefilling forms when hitting Save and add
another
---+
  Reporter:  velmont   | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Ready for checkin | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by batiste):

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

Comment:

 The bug #6903 is quite a different beast. This one just keep the query
 string when you push the "Save and continue" button in the admin. As
 simple as that. No session needed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13343: Wrong behavior of ManyToMany relationship while using 'trough' in ManyToManyField and 'db_column' and 'to_field' properties in intermediate model

[Django]

#13343: Wrong behavior of ManyToMany relationship while using 'trough' in
ManyToManyField  and 'db_column' and 'to_field' properties in intermediate
model
---+
  Reporter:  twil  | Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta
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:

 It would be great if you could reduce this to a *minimal* test case --
 that is, the simplest set of models that demonstrate the problem. I have
 no difficulty imagining that the m2m refactor changes have caused problems
 with complex m2m-through queries, but dumping the entire internals of
 Nagios doesn't help us track down the specific 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13344: Name collision for "next" template variable between contrib.comments and views.generic.list_detail

[Django]

#13344: Name collision for "next" template variable between contrib.comments and
views.generic.list_detail
-+--
  Reporter:  erik| Owner:  nobody  
Status:  new | Milestone:  
 Component:  Contrib apps|   Version:  1.2-beta
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Design decision needed
  * 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12286: Table for Model that has been proxied may not be created

[Django]

#12286: Table for Model that has been proxied may not be created
--+-
  Reporter:  telenieko| Owner:  nobody
Status:  reopened | Milestone:  1.2   
 Component:  django-admin.py  |   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by jcassee):

 Running the `proxy_model_inheritance` test passes after cleaning out the
 `INSTALLED_APPS` list. Isolating a reduced test case will take some time,
 as the package that contains the proxy models depends on a number of apps.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #11058: list_display_links doesn't allow callables not defined in the model

[Django]

#11058: list_display_links doesn't allow callables not defined in the model
---+
  Reporter:  dvine | Owner:  cmbeelby  
Status:  assigned  | Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:  list_display_links
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by cmbeelby):

  * has_patch:  0 => 1

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #11058: list_display_links doesn't allow callables not defined in the model

[Django]

#11058: list_display_links doesn't allow callables not defined in the model
---+
  Reporter:  dvine | Owner:  cmbeelby  
Status:  assigned  | Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:  list_display_links
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by cmbeelby):

  * has_patch:  1 => 0

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13334: Importing template tags from an egg fails

[Django]

#13334: Importing template tags from an egg fails
--+-
  Reporter:  joerg86  | Owner:  nobody
Status:  new  | Milestone:  1.2   
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  1 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13339: Date(Time)Field.to_python() fails to parse localized month names

[Django]

#13339: Date(Time)Field.to_python() fails to parse localized month names
---+
  Reporter:  UloPe | Owner:  nobody   
Status:  reopened  | Milestone:  1.2  
 Component:  Forms |   Version:  1.1  
Resolution:|  Keywords:  i18n l10n
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 Ok - This is closely related to #12986, but it appears to be a separate
 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13334: Importing template tags from an egg fails

[Django]

#13334: Importing template tags from an egg fails
--+-
  Reporter:  joerg86  | Owner:  nobody
Status:  new  | Milestone:  1.2   
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  1 
Needs_better_patch:  0|  
--+-
Changes (by ramiro):

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

Comment:

 We need to work on regression test for loading a module from an egg (this
 issue) and #13311 / [12944].

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13339: Date(Time)Field.to_python() fails to parse localized month names

[Django]

#13339: Date(Time)Field.to_python() fails to parse localized month names
-+--
  Reporter:  UloPe   | Owner:  nobody   
Status:  reopened| Milestone:  1.2  
 Component:  Forms   |   Version:  1.1  
Resolution:  |  Keywords:  i18n l10n
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * status:  closed => reopened
  * resolution:  invalid =>
  * milestone:  => 1.2

Comment:

 For my next trick, I will attempt to put my entire lower leg into my
 mouth.

 My apologies - there is a to_python() method in trunk; I was checking
 against v1.1 source code.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13339: Date(Time)Field.to_python() fails to parse localized month names

[Django]

#13339: Date(Time)Field.to_python() fails to parse localized month names
-+--
  Reporter:  UloPe   | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Forms   |   Version:  1.1  
Resolution:  invalid |  Keywords:  i18n l10n
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by kmtracey):

 Replying to [comment:3 russellm]:
 > Well, then there is a *big* misunderstanding - because forms.DateField
 doesn't have a to_python() method.

 ??? Yes, it does:
 http://code.djangoproject.com/browser/django/trunk/django/forms/fields.py#L320

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13339: Date(Time)Field.to_python() fails to parse localized month names

[Django]

#13339: Date(Time)Field.to_python() fails to parse localized month names
-+--
  Reporter:  UloPe   | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Forms   |   Version:  1.1  
Resolution:  invalid |  Keywords:  i18n l10n
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * status:  reopened => closed
  * resolution:  => invalid
  * milestone:  1.2 =>

Comment:

 Well, then there is a *big* misunderstanding - because forms.DateField
 doesn't have a to_python() method.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13339: Date(Time)Field.to_python() fails to parse localized month names

[Django]

#13339: Date(Time)Field.to_python() fails to parse localized month names
-+--
  Reporter:  UloPe   | Owner:  nobody   
Status:  reopened| Milestone:  1.2  
 Component:  Forms   |   Version:  1.1  
Resolution:  |  Keywords:  i18n l10n
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by UloPe):

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

Comment:

 I guess there's a missunderstanding here.

 What I'm talking about *is* forms.fields.DateField

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12286: Table for Model that has been proxied may not be created

[Django]

#12286: Table for Model that has been proxied may not be created
--+-
  Reporter:  telenieko| Owner:  nobody
Status:  reopened | Milestone:  1.2   
 Component:  django-admin.py  |   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by jcassee):

 Replying to [comment:13 ramiro]:
 > Isolation of a reduced test case that shows the problem you are
 experiencing and posting it here would be very helpful.

 I would, but the test runner calls `syncdb` and the exception is thrown.
 So it would have to be somthing with a reduced `INSTALLED_APPLICATIONS`
 list. I may try the above snippets, but I have a suspicion that it will
 pass the test. I will try anyway and report back.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12286: Table for Model that has been proxied may not be created

[Django]

#12286: Table for Model that has been proxied may not be created
--+-
  Reporter:  telenieko| Owner:  nobody
Status:  reopened | Milestone:  1.2   
 Component:  django-admin.py  |   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by ramiro):

 Replying to [comment:11 jcassee]:
 > We encounter this problem during `syncdb` (and by extension `test`) of
 our project using Django trunk (r12970); the project has become unusable
 with Postgresql. The latest patch by ramiro (`12286-r12948.diff`) does not
 fix it for us. If there is anything we can do to help debugging the
 problem, please let up know.

 Isolation of a reduced test case that shows the problem you are
 experiencing and posting it here would be very helpful.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13344: Name collision for "next" template variable between contrib.comments and views.generic.list_detail

[Django]

#13344: Name collision for "next" template variable between contrib.comments and
views.generic.list_detail
--+-
 Reporter:  erik  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Contrib apps  | Version:  1.2-beta  
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Both the comment system (in `post_comment` and it's accompagnying forms)
 and the generic views system (in `views.generic.list_detail`'s legacy
 template context stuff) use a template variabled named "next". The comment
 app's templates `approve.html`, `delete.html`, `flag.html` and
 `preview.html` render a hidden form field if `next` is not empty.

 If you use for example the `list_detail` view with a template which
 renders a comment form for each list item, the comment form wrongly uses
 the `next`-value from the `list_details` view (the next page number). On
 posting the comment the user get's an 404 error, because the
 `post_comment` view now tries to redirect to a wrong URL containing the
 next page number.

 Maybe it's generally a bad idea to use very simple context variable names
 like `next` in prepackaged apps.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12286: Table for Model that has been proxied may not be created

[Django]

#12286: Table for Model that has been proxied may not be created
--+-
  Reporter:  telenieko| Owner:  nobody
Status:  reopened | Milestone:  1.2   
 Component:  django-admin.py  |   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Changes (by russellm):

  * needs_better_patch:  0 => 1
  * milestone:  => 1.2

Comment:

 If there is a still a regressing behavior, that needs to be addressed
 before 1.2

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13343: Wrong behavior of ManyToMany relationship while using 'trough' in ManyToManyField and 'db_column' and 'to_field' properties in intermediate model

[Django]

#13343: Wrong behavior of ManyToMany relationship while using 'trough' in
ManyToManyField  and 'db_column' and 'to_field' properties in intermediate
model
--+-
 Reporter:  twil  |   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Database layer (models, ORM)  | Version:  1.2-beta  
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 = Models =
 {{{
 #!python
 # coding: utf-8

 from django.db import models

 class NagiosHosts(models.Model):
 class Meta:
 db_table = 'nagios_hosts'
 managed = False

 host_id = models.IntegerField(primary_key = True)
 host_object_id = models.IntegerField()
 alias = models.CharField(max_length = 255)
 display_name = models.CharField(max_length = 255)
 address = models.CharField(max_length = 128)

 class NagiosHostStatus(models.Model):
 class Meta:
 db_table = 'nagios_hoststatus'
 managed = False

 hoststatus_id = models.IntegerField(primary_key = True)
 host_object_id = models.IntegerField()
 hosts = models.ForeignKey('NagiosHosts', db_column = 'host_object_id',
 to_field = 'host_object_id')
 last_check = models.DateTimeField()
 current_state = models.IntegerField()
 output = models.CharField(max_length = 255)

 class NagiosHostGroups(models.Model):
 class Meta:
 db_table = 'nagios_hostgroups'
 managed = False

 hostgroup_id = models.IntegerField(primary_key = True)
 hostgroup_object_id = models.IntegerField()
 alias = models.CharField(max_length = 255)
 members = models.ManyToManyField('NagiosHosts', through =
 'NagiosHostGroupMembers')

 class NagiosHostGroupMembers(models.Model):
 class Meta:
 db_table = 'nagios_hostgroup_members'
 managed = False

 hostgroup_member_id = models.IntegerField(primary_key = True)
 hostgroup_id = models.IntegerField()
 host_object_id = models.IntegerField()
 group = models.ForeignKey('NagiosHostGroups', db_column =
 'hostgroup_id', to_field = 'hostgroup_id')
 host = models.ForeignKey('NagiosHosts', db_column = 'host_object_id',
 to_field = 'host_object_id')

 }}}

 = Wrong Behavior (a.k.a Querying DB) =
 {{{
 #!text

 Python 2.5.2 (r252:60911, Jan  4 2009, 17:40:26)
 [GCC 4.3.2] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from djnag.ndo2dj.models import *
 >>> from django.db import connection
 >>> g1 = NagiosHostGroups.objects.all()[0]
 >>> print g1.alias
 Switches
 >>> g1.members.all()
 []
 >>> connection.queries
 [{'time': '0.001', 'sql': u'SELECT `nagios_hosts`.`host_id`,
 `nagios_hosts`.`host_object_id`, `nagios_hosts`.`alias`,
 `nagios_hosts`.`display_name`, `nagios_hosts`.`address` FROM
 `nagios_hosts` INNER JOIN `nagios_hostgroup_members` ON
 (`nagios_hosts`.`host_id` = `nagios_hostgroup_members`.`host_object_id`)
 WHERE `nagios_hostgroup_members`.`hostgroup_id` = 53  LIMIT 21'}]
 }}}

 == Resulting (Wrong!!!) SQL query ==
 {{{
 #!sql
 SELECT `nagios_hosts`.`host_id`, `nagios_hosts`.`host_object_id`,
 `nagios_hosts`.`alias`, `nagios_hosts`.`display_name`,
 `nagios_hosts`.`address`
 FROM `nagios_hosts`
 INNER JOIN `nagios_hostgroup_members` ON (`nagios_hosts`.`host_id` =
 `nagios_hostgroup_members`.`host_object_id`)
 WHERE `nagios_hostgroup_members`.`hostgroup_id` = 53
 LIMIT 21
 }}}

 Here Django relies on primary key of NagiosHosts
 (nagios_hosts.'''host_id''' = nagios_hostgroup_members.host_object_id)
 rather than on to_field = '''host_object_id''' set in intermediate model.
 And I think this behavior is wrong. It should use to_field setting.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13327: FileField/ImageField accessor methods throw unnecessary exceptions when they are blank or null.

[Django]

#13327: FileField/ImageField accessor methods throw unnecessary exceptions when
they are blank or null.
---+
  Reporter:  kevin.hower...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Uncategorized |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Design decision needed

Comment:

 This has the potential to be a fairly major change in behavior, so it may
 not be possible to make this change. However, I can see the point you are
 making. Determining the right way forward will require some 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13339: Date(Time)Field.to_python() fails to parse localized month names

[Django]

#13339: Date(Time)Field.to_python() fails to parse localized month names
-+--
  Reporter:  UloPe   | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Forms   |   Version:  1.1  
Resolution:  wontfix |  Keywords:  i18n l10n
 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
  * needs_tests:  => 0
  * milestone:  1.2 =>
  * needs_docs:  => 0
  * resolution:  => wontfix

Comment:

 It isn't clear to me that Date(Time)Field *should* be using localization
 in to_python(). L10N belongs in the forms framework because that is the
 user-facing interface that should be used to gather data. The to_python()
 method accepts strings for historical purposes, and to support
 serialization; neither of these uses support the idea of using
 localization.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13331: Strange behavior of lists of objects with overriden changelist_view in admin after re-login.

[Django]

#13331: Strange behavior of lists of objects with overriden changelist_view in
admin after re-login.
---+
  Reporter:  minder| Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by erob):

 Replying to [comment:4 gabrielhurley]:
 > I'm gonna third the "please don't do this." The bug you're seeing is the
 inevitable consequence of doing something that's not thread-safe. It's not
 meant to be done.
 >
 > Re-closing as invalid as per kmtracey above.

 Using function methods as middlewares in a subclass such as ModelAdmin has
 nothing to do with thread-safety, sorry. Its fully supported by Django to
 use
 classes methods as generic views. So this sounds more like yet another
 Django weird admin-policy-design-issue thing, rather than a limitation in
 the framework
 itself.

 Good luck! ;)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13342: MultiValueField - incorrectly use 'required' attribute of MultiValueField for child field validation

[Django]

#13342: MultiValueField - incorrectly use 'required' attribute of 
MultiValueField
for child field validation
-+--
  Reporter:  krejcik | Owner:  nobody   
  
Status:  closed  | Milestone:   
  
 Component:  Forms   |   Version:  SVN  
  
Resolution:  wontfix |  Keywords:  fields required 
MultiValueField
 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
  * needs_tests:  => 0
  * milestone:  1.2 =>
  * needs_docs:  => 0
  * resolution:  => wontfix

Old description:

> MultiValueField is composed from several child fields
> Validation logic in it's clean method should be:
> - if MultiValueField is required, at least one of the child values must
> be non-empty (ok)
> - if a child field is required, it's value must be non-empty (bug in
> implementation, MultiValueField.required is used instead of
> child.required to check condition)
> - clean decompressed values by each child fields and compress together
> (ok)

New description:

 MultiValueField is composed from several child fields
 Validation logic in it's clean method should be:
  - if MultiValueField is required, at least one of the child values must
 be non-empty (ok)
  - if a child field is required, it's value must be non-empty (bug in
 implementation, MultiValueField.required is used instead of child.required
 to check condition)
  - clean decompressed values by each child fields and compress together
 (ok)

Comment:

 The proposed behavior strikes me as a fairly major change to the existing
 behavior, but it isn't clear to me that the existing behaviour is wrong,
 or that the proposed behavior is more correct.

 The report and patch doesn't give any test cases to validate why the
 proposed change would be correct, so I'm closing wontfix. If you want to
 argue your case, please bring it up on Django-developers.

 Regardless of the decision, the ticket isn't 1.2 critical.

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

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

[Django]

#13341: RegexValidator documentation minor problems
+---
  Reporter:  DrMeers| Owner:  nobody   
Status:  new| Milestone:  1.3  
 Component:  Documentation  |   Version:  SVN  
Resolution: |  Keywords:  validators,regexvalidator
 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12241: Admin forgets URL used for prefilling forms when hitting Save and add another

[Django]

#12241: Admin forgets URL used for prefilling forms when hitting Save and add
another
---+
  Reporter:  velmont   | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 See also #6903 that also proposes preserving the query string in another
 admin use case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
-+--
  Reporter:  jarrow  | Owner: 
Status:  new | Milestone: 
 Component:  django.contrib.admin|   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by ramiro):

 See also #12241 that also proposes preserving the query string in another
 admin use case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13260: urlresolvers.reverse() generates invalid URLs when an argument contains % character

[Django]

#13260: urlresolvers.reverse() generates invalid URLs when an argument contains 
%
character
-+--
  Reporter:  semenov | Owner:  stumbles
Status:  assigned| Milestone:  
 Component:  Core framework  |   Version:  1.1 
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by semenov):

 I believe this patch is not complete. The existing behavior replaces ' '
 with '%20'. As you added an explicit call to urlquote(), that logic
 supposedly got redundant and had to be removed, but I don't see that in
 the patch.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12286: Table for Model that has been proxied may not be created

[Django]

#12286: Table for Model that has been proxied may not be created
--+-
  Reporter:  telenieko| Owner:  nobody
Status:  reopened | Milestone:
 Component:  django-admin.py  |   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by jcassee):

 We encounter this problem during `syncdb` (and by extension `test`) of our
 project using Django trunk (r12970); the project has become unusable with
 Postgresql. The latest patch by ramiro (`12286-r12948.diff`) does not fix
 it for us. If there is anything we can do to help debugging the problem,
 please let up know.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13342: MultiValueField - incorrectly use 'required' attribute of MultiValueField for child field validation

[Django]

#13342: MultiValueField - incorrectly use 'required' attribute of 
MultiValueField
for child field validation
-+--
 Reporter:  krejcik  |   Owner:  nobody
   Status:  new  |   Milestone:  1.2   
Component:  Forms| Version:  SVN   
 Keywords:  fields required MultiValueField  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 MultiValueField is composed from several child fields
 Validation logic in it's clean method should be:
 - if MultiValueField is required, at least one of the child values must be
 non-empty (ok)
 - if a child field is required, it's value must be non-empty (bug in
 implementation, MultiValueField.required is used instead of child.required
 to check condition)
 - clean decompressed values by each child fields and compress together
 (ok)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #12286: Table for Model that has been proxied may not be created

[Django]

#12286: Table for Model that has been proxied may not be created
--+-
  Reporter:  telenieko| Owner:  nobody
Status:  reopened | Milestone:
 Component:  django-admin.py  |   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by rvdrijst):

 * cc: rvdrijst (added)

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

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

[Django]

#13341: RegexValidator documentation minor problems
---+
 Reporter:  DrMeers|   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  SVN   
 Keywords:  validators,regexvalidator  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In 'RegexValidator' section of documentation
 
(http://code.djangoproject.com/browser/django/trunk/docs/ref/validators.txt#L59)
 there seem to be several minor problems:

  * Default value stated as {{{None}}} in method signature, but
 {{{'invalid'}}} in details
  * Order of parameters in details differs to method signature (confusing)
  * Insufficient explanation of the purpose of the {{{code}}} parameter

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

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

[Django]

#13337: multiple installations in wsgi_embedded mode
+---
  Reporter:  canburak   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  SVN   
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:

 I'm going to wontfix this, on the grounds that Django's documentation
 isn't the place to describe mod_wsgi configuration. We provide a basic
 description, but if you've got a complex use case, you should be
 consulting mod_wsgi's documentation.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13340: patch for updating postgis template script for ubuntu 10.04

[Django]

#13340: patch for updating postgis template script for ubuntu 10.04
+---
  Reporter:  nesk...@gmail.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Changes (by russellm):

  * 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-upda...@googlegroups.com.
To unsubscribe from this group, 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] #13336: Document example for setting HttpResponse headers is misleading because it users wrong cache header

[Django]

#13336: Document example for setting HttpResponse headers is misleading because 
it
users wrong cache header
+---
  Reporter:  dnjuls | Owner:  nobody   
Status:  new| Milestone:  1.2  
 Component:  Documentation  |   Version:  SVN  
Resolution: |  Keywords:  cache reponse headers
 Stage:  Accepted   | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

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

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