Re: [Django] #10808: Multiple inheritance (model-based) broken for __init__ of common fields in diamond inheritance

[Django]

#10808: Multiple inheritance (model-based) broken for __init__ of common fields 
in
diamond inheritance
---+
  Reporter:  mikemintz | Owner:  jianhuang
Status:  assigned  | Milestone:   
 Component:  Database layer (models, ORM)  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Ready for checkin | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by shauncutts):

 Note that this problem doesn't just come up in "diamond inheritance" ...
 it seems to be a problem anywhere there is field shadowing. If you inherit
 from A and B, they will both have "id" -- see #12002, also. This patch
 works for me, but I think a more thorough solution would be to change
 Options to collect only one copy of each field.

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

-- 
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] #13789: related manager does not limit correctly on a proxy model

[Django]

#13789: related manager does not limit correctly on a proxy model
---+
  Reporter:  shauncutts| Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by shauncutts):

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

Comment:

 Opps... this is actually a manifestation of #10808

 (Not mentioned in description is that example "Profile" object actually
 has two base classes.)

 Closing 

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

-- 
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] #13792: Proposal - Refresh Django shell when code is changed (and saved)

[Django]

#13792: Proposal - Refresh Django shell when code is changed (and saved)
--+-
  Reporter:  putsin   | Owner:  nobody
Status:  closed   | Milestone:  1.3   
 Component:  django-admin.py  |   Version:  1.2   
Resolution:  wontfix  |  Keywords:  shell 
 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 can't see an obvious way to do this. Reload works for the development
 server because every request is isolated, so you can restart the entire
 system between requests. This isn't the case for the shell; the shell is
 long lived and stateful.

 I'm open to suggestions, but absent of a specific course of action, I'm
 marking this wontfix.

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

-- 
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] r13357 - django/branches/soc2010/query-refactor/django/contrib/contenttypes

[noreply]

Author: Alex
Date: 2010-06-17 21:04:10 -0500 (Thu, 17 Jun 2010)
New Revision: 13357

Modified:
   django/branches/soc2010/query-refactor/django/contrib/contenttypes/models.py
Log:
[soc2010/query-refactor] Fix an amusing typo (didn't break anything, was just 
stupid).  Thanks to Waldemar Kornewald for the report.

Modified: 
django/branches/soc2010/query-refactor/django/contrib/contenttypes/models.py
===
--- 
django/branches/soc2010/query-refactor/django/contrib/contenttypes/models.py
2010-06-17 23:50:51 UTC (rev 13356)
+++ 
django/branches/soc2010/query-refactor/django/contrib/contenttypes/models.py
2010-06-18 02:04:10 UTC (rev 13357)
@@ -72,7 +72,7 @@
 self.__class__._cache.setdefault(using, {})[ct.id] = ct
 
 class ContentType(models.Model):
-id = models.NativeAutoField(primary_key=100)
+id = models.NativeAutoField(primary_key=True)
 name = models.CharField(max_length=100)
 app_label = models.CharField(max_length=100)
 model = models.CharField(_('python model class name'), max_length=100)

-- 
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] #12634: sql compiler execute: fetchone empty result with ordering_aliases fail.

[Django]

#12634: sql compiler execute: fetchone empty result with ordering_aliases fail.
---+
  Reporter:  v...@163.com   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 You have *not* provided anything remotely resembling *evidence* that this
 is a problem in Django's code. You have provided a video of a debug
 session. You haven't told me what query you are running to generate that
 debug session. You haven't told me how your database is configured. You
 haven't even named the database backend that you are using.

 I'm glad that your QA people are happy with videos. I'm telling you that
 I'm not.

 Firstly, playing WMV is a pain in the ass. The video you provided doesn't
 play for me using Microsoft's own MacOS WMV player. I had to dig up an old
 version of VLC and coax it into life so that I could even view your video.

 Secondly, a video *by itself* doesn't give me any ability to reproduce a
 problem and investigate further. You say the problem is with has_results.
 That's fine. Maybe it is. But I'd like to see one frame higher in the
 stack to see how we got there. I'd like to see the consequences
 afterwards. I'd like to see what the SQLite backend does under comparable
 circumstances. But... oh... sorry I can't... because you haven't given
 me any details other than a video.

 If you want me to take you seriously, you need to prove you're serious.
 That means giving me the power to reproduce what you are seeing. A video
 doesn't achieve that, unless it's a *comprehensive* walkthrough, and
 that's not what you have provided.

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

-- 
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] #13791: cache.add encodes values as utf-8, cache.set does not

[Django]

#13791: cache.add encodes values as utf-8, cache.set does not
---+
  Reporter:  jbalogh   | Owner:  nobody
Status:  closed| Milestone:  1.3   
 Component:  Cache system  |   Version:  1.2   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
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:

 This is already reported in #13686, I believe.

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

-- 
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] #13686: Asymmetry in memcached.add and memcached.set

[Django]

#13686: Asymmetry in memcached.add and memcached.set
+---
  Reporter:  nedbatchelder  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Cache system   |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 #13791 reported the same thing, and has a patch with a test.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13792: Proposal - Refresh Django shell when code is changed (and saved)

[Django]

#13792: Proposal - Refresh Django shell when code is changed (and saved)
-+--
 Reporter:  putsin   |   Owner:  nobody
   Status:  new  |   Milestone:  1.3   
Component:  django-admin.py  | Version:  1.2   
 Keywords:  shell|   Stage:  Unreviewed
Has_patch:  0|  
-+--
 What I'm referring to is the style in which the development server
 refreshes when you save a file in your project. Is it possible to add that
 functionality to the Django shell?

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

-- 
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] #13791: cache.add encodes values as utf-8, cache.set does not

[Django]

#13791: cache.add encodes values as utf-8, cache.set does not
--+-
 Reporter:  jbalogh   |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Cache system  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 #11012 changed `cache.set` for the memcached backend to stop forcing
 `value.encode('utf-8')`, but `cache.add` still does encoding.  This means
 you receive a `unicode` object with `cache.set` and a `str` for the same
 object with `cache.add`.  Attached patch removes encoding from
 `cache.add`.

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

-- 
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] #5612: Signals for login / logout

[Django]

#5612: Signals for login / logout
-+--
  Reporter:  pterk   | Owner:  SmileyChris
Status:  new | Milestone: 
 Component:  Core framework  |   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by mitar):

 * cc: mmi...@gmail.com (added)

Comment:

 Another use case: with signal you could add a message to the user
 informing her that she was successfully logged in or out and redirect her
 to the page she wanted to go in the first place and not to the default
 login page. It is a nice information to users that they know what is
 happening behind the scenes.

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

-- 
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] r13356 - django/trunk/docs/ref

[noreply]

Author: kmtracey
Date: 2010-06-17 18:50:51 -0500 (Thu, 17 Jun 2010)
New Revision: 13356

Modified:
   django/trunk/docs/ref/request-response.txt
Log:
Fixed #13785: Corrected some misplaced and missing parentheses. Thanks LucianU.


Modified: django/trunk/docs/ref/request-response.txt
===
--- django/trunk/docs/ref/request-response.txt  2010-06-17 18:29:27 UTC (rev 
13355)
+++ django/trunk/docs/ref/request-response.txt  2010-06-17 23:50:51 UTC (rev 
13356)
@@ -286,7 +286,7 @@
 .. method:: QueryDict.setdefault(key, default)
 
 Just like the standard dictionary ``setdefault()`` method, except it uses
-``__setitem__`` internally.
+``__setitem__()`` internally.
 
 .. method:: QueryDict.update(other_dict)
 
@@ -305,7 +305,7 @@
 .. method:: QueryDict.items()
 
 Just like the standard dictionary ``items()`` method, except this uses the
-same last-value logic as ``__getitem()__``. For example::
+same last-value logic as ``__getitem__()``. For example::
 
>>> q = QueryDict('a=1=2=3')
>>> q.items()
@@ -315,7 +315,7 @@
 
 Just like the standard dictionary ``iteritems()`` method. Like
 :meth:`QueryDict.items()` this uses the same last-value logic as
-:meth:`QueryDict.__getitem()__`.
+:meth:`QueryDict.__getitem__()`.
 
 .. method:: QueryDict.iterlists()
 
@@ -325,7 +325,7 @@
 .. method:: QueryDict.values()
 
 Just like the standard dictionary ``values()`` method, except this uses the
-same last-value logic as ``__getitem()__``. For example::
+same last-value logic as ``__getitem__()``. For example::
 
>>> q = QueryDict('a=1=2=3')
>>> q.values()

-- 
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] #13790: Docs for CurrentSiteManager indicate an M2M field called "sites" will be auto-detected on a model when it won't

[Django]

#13790: Docs for CurrentSiteManager indicate an M2M field called "sites" will be
auto-detected on a model when it won't
---+
 Reporter:  gabrielhurley  |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Contrib apps   | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Throughout the Sites Framework docs the example models use `sites =
 ManyToManyField(Site)`, and under the
 
[http://docs.djangoproject.com/en/dev/ref/contrib/sites/#django.contrib.sites.django.contrib.sites.managers.CurrentSiteManager
 CurrentSiteManager section] it indicates that CurrentSiteManager will be
 able to automatically discover either a ForeignKey called "site" or a
 ManyToManyField called "sites", when in fact the code only looks for a
 field called "site".

 While it'd be an easy docs fix, it seems more valuable to fix
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sites/managers.py#L5
 the code for the manager] to actually do what the docs say.

 I'm happy to write up a patch and tests for it later.

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

-- 
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] #13784: pre_save is dispatched before executing upload_to attributes on FileFields when using ModelForm

[Django]

#13784: pre_save is dispatched before executing upload_to attributes on 
FileFields
when using ModelForm
-+--
  Reporter:  peterbe | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  duplicate   |  Keywords:  ModelForm pre_save
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

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

Comment:

 This behavior got a fair amount of discussion when it was introduced. See
 #10788 and the linked threads on django-developers.

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

-- 
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] #12634: sql compiler execute: fetchone empty result with ordering_aliases fail.

[Django]

#12634: sql compiler execute: fetchone empty result with ordering_aliases fail.
---+
  Reporter:  v...@163.com   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 1. Yes, a video. It's an effective communication tool.  Use it to work
 with the QA folks every day and everyone loves it.  Of cause it sounds
 like you just want to find any excuse not to deal with this particular
 problem, like that the text is too small even though I pointed out in the
 original post that one needs to download the video and run it full screen.

 2. What I'm presenting here is evidence that the problem shows up in
 Django's code, not in pyodbc or django-pyodbc.  This very well may be a
 red herring, but so far you haven't said anything relevant to refute it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13265: TransactionManagementError doesn't allow for easy debugging of views

[Django]

#13265: TransactionManagementError doesn't allow for easy debugging of views
---+
  Reporter:  orokusaki | Owner:  nobody 
Status:  reopened  | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  transaction
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by John Obelenus):

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

Comment:

 Seeing TransactionManagementError? that reports that "Transaction managed
 block ended with pending COMMIT/ROLLBACK" is the correct symptom.

 If you don't commit() or rollback() you will get this error. That much is
 obvious and correct. The problem that 'orokusaki' is talking about is if
 the view (or code called within the view) doesn't catch an exception
 thrown, the view will still give you TransactionManagementError. So, yes
 you doing just this: "It's not like we're rethrowing an error and thereby
 hiding a stack trace." The return of the view function is an exception,
 db.transaction sees the failure case, and raises its own TME exception -
 hiding the true problem.  The true exception can be an ImportError,
 ValueError, TypeError, or any basic error that fingers angry at their
 master can cause. In my case I had a simple ValueError from mistyping a
 variable name, thus giving an undeclared variable.

 The reproduction steps ought to be pretty simple. Cause a basic exception
 in a view with the @transaction.commit_manually decorator, don't catch it,
 and see the TME exception, not the basic exception with a trace to find
 it. If I can do anything to get a test case to let me know how best to
 submit it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13789: related manager does not limit correctly on a proxy model

[Django]

#13789: related manager does not limit correctly on a proxy model
--+-
 Reporter:  shauncutts|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If I have a proxy of a model, the related manager does not correctly limit
 related items.

 E.g.

 {{{
 class Profile( models.Model ):

  # ...

 class Location( models.Model ):
 home_of = models.ForeignKey( Profile, related_name= 'locations' )

 class ProxyProfile( Profile ):
 class Meta:
 proxy = True

 }}}
 Now if I have a particular Profile p with one location, its related
 manager
 will give me the correct number of objects, but not when accessed via the
 proxy:

 {{{
 >>> Location.objects.count()
 1000
 >>> p = Profile.objects.get( pk = 1234 )
 >>> p.locations.count()
 1
 >>> pp = ProxyProfile.objects.get( pk = 1234 )
 >>> pp.locations.count()
 1000
 }}}

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

-- 
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] #13779: GeoDjango doesn't find libgdal 1.7.0

[Django]

#13779: GeoDjango doesn't find libgdal 1.7.0
-+--
  Reporter:  Leo | Owner:  jbronn
Status:  assigned| Milestone:  1.3   
 Component:  GIS |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by Leo):

 Awesome, thanks! Any chance it could get backported into the 1.2.x release
 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] #13779: GeoDjango doesn't find libgdal 1.7.0

[Django]

#13779: GeoDjango doesn't find libgdal 1.7.0
-+--
  Reporter:  Leo | Owner:  jbronn
Status:  assigned| Milestone:  1.3   
 Component:  GIS |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * milestone:  => 1.3
  * owner:  nobody => jbronn
  * needs_docs:  => 0

Comment:

 Good catch -- putting on docket for 1.3 (but should land in trunk much
 sooner).

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

-- 
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] #13715: Creating GeoDjango model in shell does not work

[Django]

#13715: Creating GeoDjango model in shell does not work
-+--
  Reporter:  drdee   | Owner:  nobody   
 
Status:  closed  | Milestone:   
 
 Component:  GIS |   Version:  1.2  
 
Resolution:  invalid |  Keywords:  geodjango, postgresql 8.4, 
postgis 1.5
 Stage:  Unreviewed  | Has_patch:  0
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

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

Comment:

 This is not an issue specific to !GeoDjango -- same results when the
 import is `from django.db import models` and there's no `PolygonField` or
 `GeoManager`.  Declaring Django models like this at the shell is not the
 proper way to define models, as they expect to be a part of an application
 namespace (hence why it's barfing when trying to figure out the
 `app_label`).

 If what you really want are [wiki:DynamicModels dynamic models], then I
 suggest checking out the existing materials on the subject.

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

-- 
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] #13788: GEOSGeometry.transform() silently no-ops when GDAL isn't available or srid is None

[Django]

#13788: GEOSGeometry.transform() silently no-ops when GDAL isn't available or 
srid
is None
---+
  Reporter:  rcoup | Owner:  rcoup  
Status:  assigned  | Milestone:  1.3
 Component:  GIS   |   Version:  SVN
Resolution:|  Keywords:  transform geos gdal
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by rcoup):

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

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

-- 
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] #13788: GEOSGeometry.transform() silently no-ops when GDAL isn't available or srid is None

[Django]

#13788: GEOSGeometry.transform() silently no-ops when GDAL isn't available or 
srid
is None
---+
  Reporter:  rcoup | Owner:  nobody 
Status:  new   | Milestone:  1.3
 Component:  GIS   |   Version:  SVN
Resolution:|  Keywords:  transform geos gdal
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by rcoup):

 * cc: jbronn (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0
  * has_patch:  0 => 1
  * stage:  Unreviewed => Accepted

Comment:

 My documentation/rest-fu isn't strong, so probably worth a look there, and
 i'm not sure whether the notes for the release are all in the right 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.

[Django] #13788: GEOSGeometry.transform() silently no-ops when GDAL isn't available or srid is None

[Django]

#13788: GEOSGeometry.transform() silently no-ops when GDAL isn't available or 
srid
is None
-+--
 Reporter:  rcoup|   Owner:  nobody
   Status:  new  |   Milestone:  1.3   
Component:  GIS  | Version:  SVN   
 Keywords:  transform geos gdal  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 `GEOSGeometry.transform()` uses the GDAL library to re-project geometries.
 If GDAL is not available however, it silently does nothing.

 Geodjango-Users discussion thread:
 http://groups.google.com/group/geodjango/browse_thread/thread/788cafdbd592d617

 Current behaviour if GDAL is unavailable:
  * `.transform(clone=False)` (the default) does nothing
  * `.transform(clone=True)` returns `None`

 Also related:
  * `.transform(clone=False)` (the default) called on a geometry where
 `.srid` is `None` does nothing
  * `.transform(clone=True)` called on a geometry where `.srid` is `None`
 returns `None`

 Since `transform(clone=False)` (the default) mutates the geometry, it
 should raise an exception if it can't do what the caller asked.

 The attached patch:
  * short-circuits re-projection if the source and destination SRIDs match
  * makes `.transform()` raise a GEOSGeometry.Error if GDAL isn't available
  * adds tests around the new behaviour
  * adds a `FutureWarning` if the srid of the geometry is `None` or <0,
 pointing out that in 1.5 the behaviour will change an error will be
 raised.
  * adds some docs, including notes to the backwards-incompatibilities for
 1.3

 The backwards incompatible behaviour change is being introduced because:
  * `.transform()` no-op'ing if source & destination SRIDs don't match is
 NOT what the caller wants - it is in all cases a bug.
  * It's unlikely the user was manually checking either the return value
 (`clone=True`) or the geometry's srid (`clone=False`) and raising their
 own exception, the more common case would be to assert on `HAS_GDAL`.

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

-- 
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] #13190: Empty settings.AUTHENTICATION_BACKENDS creates hard to trace problem

[Django]

#13190: Empty settings.AUTHENTICATION_BACKENDS creates hard to trace problem
-+--
  Reporter:  joel3000| Owner:  gabrielhurley  
Status:  assigned| Milestone:  1.3
 Component:  Authentication  |   Version:  1.1
Resolution:  |  Keywords:  AUTHENTICATION_BACKENDS
 Stage:  Accepted| Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by gabrielhurley):

  * milestone:  => 1.3

Comment:

 Bumping to 1.3 milestone.

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

-- 
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] #13240: Modify RelatedManager and ManyRelatedManager add() and remove() to accept QuerySets

[Django]

#13240: Modify RelatedManager and ManyRelatedManager add() and remove() to 
accept
QuerySets
---+
  Reporter:  gabrielhurley | Owner:  
gabrielhurley
Status:  assigned  | Milestone:  1.3
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords: 
  
 Stage:  Ready for checkin | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by gabrielhurley):

  * status:  new => assigned
  * milestone:  => 1.3

Comment:

 Bumping to 1.3 milestone.

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

-- 
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] #12028: Generic Inline doesn't validate unique_together

[Django]

#12028: Generic Inline doesn't validate unique_together
---+
  Reporter:  diverman  | Owner: 
 
Status:  new   | Milestone: 
 
 Component:  Contrib apps  |   Version:  1.2
 
Resolution:|  Keywords:  content type generic 
inline unique validation formset admin modeladmin model
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by nessita):

 I unassigned myself from the bug a while back, currently I don't have
 enough time to spend in this issue, sorry :-/

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

-- 
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] r13355 - django/trunk/docs/ref/models

[noreply]

Author: kmtracey
Date: 2010-06-17 13:29:27 -0500 (Thu, 17 Jun 2010)
New Revision: 13355

Modified:
   django/trunk/docs/ref/models/instances.txt
Log:
Fixed #13778: Removed a stray colon in a code example. Thanks canassa.


Modified: django/trunk/docs/ref/models/instances.txt
===
--- django/trunk/docs/ref/models/instances.txt  2010-06-16 20:48:45 UTC (rev 
13354)
+++ django/trunk/docs/ref/models/instances.txt  2010-06-17 18:29:27 UTC (rev 
13355)
@@ -109,7 +109,7 @@
 
 from django.core.validators import ValidationError, NON_FIELD_ERRORS
 try:
-article.full_clean():
+article.full_clean()
 except ValidationError, e:
 non_field_errors = e.message_dict[NON_FIELD_ERRORS]
 

-- 
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] #13787: AuthenticationForm renders incorrect passwords

[Django]

#13787: AuthenticationForm renders incorrect passwords
--+-
 Reporter:  Ciantic   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Authentication| Version:  1.2   
 Keywords:  passwordinput AuthenticationForm  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If user fails to log in using
 `django.contrib.auth.forms.AuthenticationForm` the user is given form
 where password is ''filled with incorrect last try''.

 Instead AuthenticationForm's field Password should use the `PasswordInput`
 widget's parameter `render_value`, which turned as `False` would hide the
 incorrect passwords.

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

-- 
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] #13786: Test client PUT and DELETE do not include the GET query params

[Django]

#13786: Test client PUT and DELETE do not include the GET query params
-+--
   Reporter:  coulix |Owner:  nobody
 Status:  new|Milestone:
  Component:  Testing framework  |  Version:  1.2   
   Keywords: |Stage:  Unreviewed
  Has_patch:  0  |   Needs_docs:  0 
Needs_tests:  0  |   Needs_better_patch:  0 
-+--
 Using DJango test client to test my piston API using Oauth two legged i
 realised that when passing ?xoauth_requestor_id=foo as a GET variable on
 PUT and DELETE action the request response did not include the variable in
 request.GET.
 In the case of a PUT action request.GET and request.POST contanis the same
 POST data ... no trace of xoauth_requestor_id.

 It works well on POST and GET

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

-- 
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] #13785: Documentation typos

[Django]

#13785: Documentation typos
---+
 Reporter:  LucianU|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 At the page http://docs.djangoproject.com/en/1.2/ref/request-response
 /#ref-request-response there are the following errors:

 Under {{{QueryDict.setdefault(key, default)}}}, it should be
 {{{__setitem__()}}} not {{{__setitem__}}}.[[BR]]
 Under {{{QueryDict.items()}}}, it should be {{{__getitem__()}}} not
 {{{__getitem()__}}}.[[BR]]
 Under {{{QueryDict.iteritems()}}}, it should be {{{__getitem__()}}} not
 {{{__getitem()__()}}}.[[BR]]
 Under {{{QueryDict.values()}}}, it should be {{{__getitem__()}}} not
 {{{__getitem()__}}}.[[BR]]

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

-- 
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] #6064: Allow database connection initialization commands

[Django]

#6064: Allow database connection initialization commands
---+
  Reporter:  jacob | Owner:  floguy
Status:  closed| Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by tback):

 i never found out where at what place i had to register the signal
 handler.

 the best solution i found for the schema problem was to set a
 connect_query in pgbouncer.

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

-- 
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] #13737: Hide the extra column added by #11791

[Django]

#13737: Hide the extra column added by #11791
---+
  Reporter:  acdha | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:  duplicate |  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:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Duplicate of #13599

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

-- 
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] #13721: pass extra content-type values to file upload handlers

[Django]

#13721: pass extra content-type values to file upload handlers
-+--
  Reporter:  wkornewald  | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  File uploads/storage|   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by wkornewald):

 Still no response from a committer? :(
 Is something missing?

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

-- 
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] #13784: pre_save is dispatched before executing upload_to attributes on FileFields when using ModelForm

[Django]

#13784: pre_save is dispatched before executing upload_to attributes on 
FileFields
when using ModelForm
-+--
  Reporter:  peterbe | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  |  Keywords:  ModelForm pre_save
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by peterbe):

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

Comment:

 I suspect that the culprit is {{{Model.save_base}}} in
 {{{django/db/models/base.py}}} where it dispatches the signal before it
 does whatever it does to those {{{meta.local_files}}} but I don't
 understand the code enough to attempt a patch at this point.

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

-- 
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] #13784: pre_save is dispatched before executing upload_to attributes on FileFields when using ModelForm

[Django]

#13784: pre_save is dispatched before executing upload_to attributes on 
FileFields
when using ModelForm
+---
 Reporter:  peterbe |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Forms   | Version:  1.2   
 Keywords:  ModelForm pre_save  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Suppose you have this code:

 {{{
 def callable_upload_to(instance, filename):
 full_path = os.path.join(this_year(), filename)
 print "PLACING", full_path
 return full_path

 class Foo(models.Model):
 file = models.FileField(upload_to=callable_upload_to)
 size = models.IntegerField(null=True)

 def update_foo(sender, instance, **kwargs):
 print "UPDATING", str(instance.file)

 pre_save.connect(update_foo, sender=Foo)
 }}}

 Suppose you create one of these instances with a '''!ModelForm''' you'll
 get this output on stdout:
 {{{
 UPDATING sample.file
 PLACING 2010/sample.file
 }}}

 That means that you can't rely on the file path as dictated by the
 upload_to callable in your pre_save signal. Especially important is that
 within your {{{pre_save}}} method you can't even get to the file since it
 doesn't exist.

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

-- 
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] #13715: Creating GeoDjango model in shell does not work

[Django]

#13715: Creating GeoDjango model in shell does not work
-+--
  Reporter:  drdee   | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  GIS |   Version:  1.2  
 
Resolution:  |  Keywords:  geodjango, postgresql 8.4, 
postgis 1.5
 Stage:  Unreviewed  | Has_patch:  0
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * component:  Contrib apps => GIS

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

-- 
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] #13751: Avoid open redirect issue with whitelist

[Django]

#13751: Avoid open redirect issue with whitelist
+---
  Reporter:  anonymous  | Owner:  nobody 
Status:  new| Milestone:  1.3
 Component:  HTTP handling  |   Version:  SVN
Resolution: |  Keywords:  open redirect, security
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  1  |   Needs_tests:  1  
Needs_better_patch:  1  |  
+---
Changes (by russellm):

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

Comment:

 Agreed that we should do something to address this problem.

 However, the patch needs to be integrated into Django's source tree, and
 it needs to be tested and documented.

 The patch also requires some improvements -- in particular:

  * A common whitelist (REDIRECT_WHITELIST) should be defined in the
 settings file, augmented by the values provided to the redirect instance.
  * The whitelist should assume that all URL patterns are regular
 expressions, just like URL patterns do.
  * There is a backwards compatibility problem. We can't just turn this
 feature on without causing a major inconvenience to the existing userbase.
 We will need to phase this in over several versions. This probably means
 that:
 - the settings.py template should have a REDIRECT_WHITELIST setting,
 but the global settings should not
 - if there is no REDIRECT_WHITELIST defined (i.e., this is an old
 project being upgraded) a warning should be raised, and *all* URLs should
 be whitelisted. This allows existing sites to be notified that something
 needs to be addressed without causing a breakage.
 - In the next release, we can remove the warning and enable
 whitelisting for all redirects.

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

-- 
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] #13722: My Javascript string catalog contains calendar related strings that I didn't create, but only for French

[Django]

#13722: My Javascript string catalog contains calendar related strings that I
didn't create, but only for French
---+
  Reporter:  stodge| Owner:  nobody
Status:  closed| Milestone:
 Component:  Internationalization  |   Version:  1.1   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 These are the translation strings used by admin javascript. They're
 defined in the djangojs.po file. If you define your own djangojs domain
 file, you can add to these if you require.

 Also - for future reference, questions like this are better suited to
 django-users. Trac is for logging bugs; if you're uncertain if you've
 found a bug, or you want explanation of how something is/does/should work,
 django-users is the place to go.

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

-- 
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] #13713: Changing ModelMultipleChoiceField in admin is not reflected in override save() of the same model

[Django]

#13713: Changing ModelMultipleChoiceField in admin is not reflected in override
save() of the same model
-+--
  Reporter:  jonathan_livni  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Uncategorized   |   Version:  1.2   
Resolution:  invalid |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 It's not a queried cache result - it's correctly returning the values from
 the database at the point at which you are querying.

 M2M relations aren't saved as part of the save() call - they're a separate
 table, and they're saved separately, after the base model has been saved.

 I don't know what has given you the impression that the m2m is updated as
 part of the model save. It is modified as part of the *form* save, but
 that's a larger process than saving an individual model instance.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #12028: Generic Inline doesn't validate unique_together

[Django]

#12028: Generic Inline doesn't validate unique_together
---+
  Reporter:  diverman  | Owner: 
 
Status:  new   | Milestone: 
 
 Component:  Contrib apps  |   Version:  1.2
 
Resolution:|  Keywords:  content type generic 
inline unique validation formset admin modeladmin model
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by johndotnet):

  * version:  SVN => 1.2

Comment:

 this bug is still open, anyone on this ? what happen to nessita ?

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

-- 
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] #13782: Missing css on textarea & errors marking is too broad for multiple fields on same line

[Django]

#13782: Missing css on textarea & errors marking is too broad for multiple 
fields
on same line
--+-
 Reporter:  master|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Under the Admin, try to add-save an empty object of this example:

 models.py:
 {{{
 #!python
 class Test(models.Model):
 title = models.CharField(max_length=100, blank=True)
 presentation = models.TextField()

 }}}

 admin.py:
 {{{
 #!python
 class TestAdmin(admin.ModelAdmin):
 fieldsets = (
 (None,   {'fields': (('title', 'presentation'), )}),
 )
 admin.site.register(Test, TestAdmin)
 }}}


 The unexpected results are:
  * there is no red border on the offending 'presentation' field
  * the red border on the 'title' field is confusing, this field is not in
 error, as it can be empty

 The proposed patch adds:
  * the missing CSS rule on an erroneous textarea
  * a way (to be cleanedup) to lower the error marking from the 'form-row'
 to the 'field-box' level, so that only the offending fields are pointed
 out.

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

-- 
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] #13704: utils.html.urlize mishandles IDN style domain names

[Django]

#13704: utils.html.urlize mishandles IDN style domain names
--+-
  Reporter:  dryan| Owner:  nobody 
Status:  new  | Milestone: 
 Component:  Template system  |   Version:  1.2
Resolution:   |  Keywords:  IDN, urlize
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  1|   Needs_tests:  1  
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * has_patch:  0 => 1
  * component:  Uncategorized => Template system
  * stage:  Unreviewed => Accepted

Comment:

 Still needs tests; also needs PEP8 (i..e, strip all that extra space
 around the parentheses).

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

-- 
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] #13695: Django Comments Loses Ajax Headers When Redirecting (request.is_ajax() === True --> request.is_ajax() === False)

[Django]

#13695: Django Comments Loses Ajax Headers When Redirecting (request.is_ajax() 
===
True --> request.is_ajax() === False)
+---
  Reporter:  jacobstr   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 I'm with r1cky -- this is a problem on the client side, not the server
 side.

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

-- 
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] #13677: wrong backend with multidb and modelformset

[Django]

#13677: wrong backend with multidb and modelformset
---+
  Reporter:  pollux| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  => 0
  * milestone:  => 1.3
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13674: Javascript for adding inline fields doesn't update "for" attribute in label

[Django]

#13674: Javascript for adding inline fields doesn't update "for" attribute in 
label
---+
  Reporter:  Jonas | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:  admin 
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * component:  Uncategorized => django.contrib.admin
  * needs_tests:  => 0
  * milestone:  => 1.3
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13673: DEBUG=False and 404 / Flatpages

[Django]

#13673: DEBUG=False and 404 / Flatpages
--+-
  Reporter:  michael.mil...@12mm.net  | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Uncategorized|   Version:  1.2   
Resolution:  worksforme   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  1|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 I can't reproduce this. flatpages works fine for me, regardless of the
 value of DEBUG.

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

-- 
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] #13725: assertRedirects not taking url scheme into account

[Django]

#13725: assertRedirects not taking url scheme into account
+---
  Reporter:  rvdrijst   | Owner:  nobody
  
Status:  new| Milestone:
  
 Component:  Testing framework  |   Version:  1.2   
  
Resolution: |  Keywords:  test client 
assertRedirects https scheme
 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] #13668: ManyToManyField passes ModelBase to router.db_for_write

[Django]

#13668: ManyToManyField passes ModelBase to router.db_for_write
---+
  Reporter:  craig.kime...@gmail.com   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  => 0
  * milestone:  => 1.3
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13783: Admin module. Password change fails if TEMPLATE_STRING_IF_INVALID set in settings.py

[Django]

#13783: Admin module. Password change fails if TEMPLATE_STRING_IF_INVALID set in
settings.py
+---
  Reporter:  mrechte| Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  duplicate  |  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:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Duplicate of #13537, and plenty of others.

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

-- 
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] #13783: Admin module. Password change fails if TEMPLATE_STRING_IF_INVALID set in settings.py

[Django]

#13783: Admin module. Password change fails if TEMPLATE_STRING_IF_INVALID set in
settings.py
---+
 Reporter:  mrechte|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In the admin module, validating a user password change produces a django
 error if TEMPLATE_STRING_IF_INVALID is set to some value in settings.py
 (for example TEMPLATE_STRING_IF_INVALID = '[erreur template]')

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

-- 
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] #13650: Permissions of abstract model without fields not added on syncdb

[Django]

#13650: Permissions of abstract model without fields not added on syncdb
+---
  Reporter:  deschler   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 Yes - you are missing something. The model is abstract. That means it
 doesn't exist. As soon as you define a concrete subclass, the permissions,
 content type etc will be created for that concrete subclass; depending on
 how you have subclassed the concrete class, the permissions etc will be
 inherited.

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

-- 
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] #13707: Reflecting django docs in pydocs

[Django]

#13707: Reflecting django docs in pydocs
---+
  Reporter:  nyx...@gmail.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Documentation |   Version:  1.2   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 This is one of those wierd occasions where I'm in completely agreement,
 but I'm going to mark the ticket invalid.

 The reason is entirely procedural; documentation is better handled by a
 series of smaller tickets, each of which fixes some specific documentation
 problem. That way we can easily track the work that needs to be applied to
 trunk.

 If you want to address this, write a patch that adds docs to a specific
 module or group of modules (e.g., the query API), and open a new ticket
 that specifically addresses the area that you are documenting.

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

-- 
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] #13669: Django 1.2.1 test fails

[Django]

#13669: Django 1.2.1 test fails
+---
  Reporter:  humanfromearth | Owner:  nobody
Status:  closed | Milestone:
 Component:  Testing framework  |   Version:  1.2   
Resolution:  duplicate  |  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:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This appears to be a variation on a theme of #11077 -- that there is a
 difference between integration tests and application tests, but Django
 doesn't currently make that distinction.

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

-- 
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] #13710: raw() sql bug when using a model with many fields with long names

[Django]

#13710: raw() sql bug when using a model with many fields with long names
---+
  Reporter:  Renskers  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.2
  
Resolution:|  Keywords:  raw sql 
joins
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 This problem also presents itself in the admin. When I try to load the
 admin page for my model, I get this error:

 {{{
 Exception Type: TypeError at /admin/biobench/measurement/
 Exception Value: __init__() keywords must be strings
 }}}

 Traceback:

 {{{
 File
 "/opt/APPS/biobench/acc/Biobench/packages/django/core/handlers/base.py" in
 get_response
   100. response = callback(request, *callback_args,
 **callback_kwargs)
 File
 "/opt/APPS/biobench/acc/Biobench/packages/django/contrib/admin/options.py"
 in wrapper
   239. return self.admin_site.admin_view(view)(*args,
 **kwargs)
 File "/opt/APPS/biobench/acc/Biobench/packages/django/utils/decorators.py"
 in _wrapped_view
   76. response = view_func(request, *args, **kwargs)
 File
 "/opt/APPS/biobench/acc/Biobench/packages/django/views/decorators/cache.py"
 in _wrapped_view_func
   69. response = view_func(request, *args, **kwargs)
 File
 "/opt/APPS/biobench/acc/Biobench/packages/django/contrib/admin/sites.py"
 in inner
   190. return view(request, *args, **kwargs)
 File "/opt/APPS/biobench/acc/Biobench/packages/django/utils/decorators.py"
 in _wrapper
   21. return decorator(bound_func)(*args, **kwargs)
 File "/opt/APPS/biobench/acc/Biobench/packages/django/utils/decorators.py"
 in _wrapped_view
   76. response = view_func(request, *args, **kwargs)
 File "/opt/APPS/biobench/acc/Biobench/packages/django/utils/decorators.py"
 in bound_func
   17. return func(self, *args2, **kwargs2)
 File
 "/opt/APPS/biobench/acc/Biobench/packages/django/contrib/admin/options.py"
 in changelist_view
   1,071. 'selection_note': _('0 of %(cnt)s selected') %
 {'cnt': len(cl.result_list)},
 File "/opt/APPS/biobench/acc/Biobench/packages/django/db/models/query.py"
 in __len__
   81. self._result_cache = list(self.iterator())
 File "/opt/APPS/biobench/acc/Biobench/packages/django/db/models/query.py"
 in iterator
   274. only_load=only_load)
 File "/opt/APPS/biobench/acc/Biobench/packages/django/db/models/query.py"
 in get_cached_row
   1,208. obj = klass(**dict(zip(field_names, fields)))
 }}}

 My model has 175 fields (yeah...), which on average are 40 characters
 long.

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

-- 
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] #13488: Exceptions in GEOS I/O object destructor at process exit

[Django]

#13488: Exceptions in GEOS I/O object destructor at process exit
---+
  Reporter:  mro...@arinc.com  | Owner:  jbronn  
Status:  assigned  | Milestone:  
 Component:  GIS   |   Version:  1.2-beta
Resolution:|  Keywords:  gis 
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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