[Changeset] r12779 - django/branches/releases/1.1.X/django/contrib/auth/tests

[noreply]

Author: russellm
Date: 2010-03-15 01:57:07 -0500 (Mon, 15 Mar 2010)
New Revision: 12779

Modified:
   django/branches/releases/1.1.X/django/contrib/auth/tests/forms.py
Log:
[1.1.X] Fixed #13108 -- Corrected an ambiguity in test data with the potential 
to cause test failures out of the box. Thanks to benreynwar for the report.

Backport of r12778 from trunk.

Modified: django/branches/releases/1.1.X/django/contrib/auth/tests/forms.py
===
--- django/branches/releases/1.1.X/django/contrib/auth/tests/forms.py   
2010-03-15 06:55:56 UTC (rev 12778)
+++ django/branches/releases/1.1.X/django/contrib/auth/tests/forms.py   
2010-03-15 06:57:07 UTC (rev 12779)
@@ -221,10 +221,10 @@
 
 # bug #5605, preserve the case of the user name (before the @ in the email 
address)
 # when creating a user.
->>> user = User.objects.create_user('test2', 't...@example.com', 'test')
+>>> user = User.objects.create_user('forms_test2', 't...@example.com', 'test')
 >>> user.email
 't...@example.com'
->>> user = User.objects.create_user('test3', 'tesT', 'test')
+>>> user = User.objects.create_user('forms_test3', 'tesT', 'test')
 >>> user.email
 'tesT'
 

-- 
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] r12778 - django/trunk/django/contrib/auth/tests

[noreply]

Author: russellm
Date: 2010-03-15 01:55:56 -0500 (Mon, 15 Mar 2010)
New Revision: 12778

Modified:
   django/trunk/django/contrib/auth/tests/forms.py
Log:
Fixed #13108 -- Corrected an ambiguity in test data with the potential to cause 
test failures out of the box. Thanks to benreynwar for the report.

Modified: django/trunk/django/contrib/auth/tests/forms.py
===
--- django/trunk/django/contrib/auth/tests/forms.py 2010-03-14 20:30:18 UTC 
(rev 12777)
+++ django/trunk/django/contrib/auth/tests/forms.py 2010-03-15 06:55:56 UTC 
(rev 12778)
@@ -221,10 +221,10 @@
 
 # bug #5605, preserve the case of the user name (before the @ in the email 
address)
 # when creating a user.
->>> user = User.objects.create_user('test2', 't...@example.com', 'test')
+>>> user = User.objects.create_user('forms_test2', 't...@example.com', 'test')
 >>> user.email
 't...@example.com'
->>> user = User.objects.create_user('test3', 'tesT', 'test')
+>>> user = User.objects.create_user('forms_test3', 'tesT', 'test')
 >>> user.email
 'tesT'
 

-- 
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] #12979: TestCase disables savepoint_commit, savepoint_rollback

[Django]

#12979: TestCase disables savepoint_commit, savepoint_rollback
+---
  Reporter:  forest | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by thejaswi_puthraya):

 Isn't this ticket similar to #12087 ?

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

-- 
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] #13111: 1.1.X: decorators broken by r12763

[Django]

#13111: 1.1.X: decorators broken by r12763
+---
  Reporter:  kmtracey   | Owner:  nobody
Status:  closed | Milestone:  1.2   
 Component:  Uncategorized  |   Version:  SVN   
Resolution:  fixed  |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 Digging into this a big more, I think this was an overenthusiastic
 backmerge on my part.

 The original problem from #13093 only deals with decorated class-like
 views. [12399] made some pretty big changes to decorator_from_middleware,
 in turn fixing problems introduced by [11586], which was addressing
 problems decorating bound methods rather than functions.

 Effectively, this means that there was no way to decorate a class-like
 view in Django 1.1 -- at least, not with the Django-provided utilities.
 Therefore, a backport of [12763] isn't required.

 Apologies for the temporary instability on 1.1.X; I'm going to close this
 fixed, as the revert from [12776] is what was required.

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

-- 
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] #13117: Recenter OSMGeoAdmin widget with coordinates

[Django]

#13117: Recenter OSMGeoAdmin widget with coordinates
+---
  Reporter:  anonymous  | Owner:  nobody  
Status:  new| Milestone:  
 Component:  GIS|   Version:  1.1 
Resolution: |  Keywords:  admin widget OSMGeoAdmin
 Stage:  Accepted   | Has_patch:  1   
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] #11015: django-1.0.2 does not catch the exception that database backend first close the db connection.

[Django]

#11015: django-1.0.2 does not catch the exception that database backend first 
close
the db connection.
---+
  Reporter:  qingran   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 I've tried your scenario on current trunk, and can't recreate most of what
 you list above.

 First, the confirmation page now does list that the associated URL model
 is going to be deleted. This was likely done by the fix for #6191.

 Second, I don't get any hiding of DB errors. With debug on I get a debug
 page with full details of the error. With debug off I get a server error
 page.

 Perhaps because of the second item, I don't see any error related to
 trying to close an already-closed connection. I assume that is what you
 mean by "not recovering after db error"? If not please explain what you
 mean because I'm having hard time connecting what you are reporting now
 with the original report.

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

-- 
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] #11015: django-1.0.2 does not catch the exception that database backend first close the db connection.

[Django]

#11015: django-1.0.2 does not catch the exception that database backend first 
close
the db connection.
---+
  Reporter:  qingran   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by gkulewski):

 Well, I see at least the following bugs in it:
  * not recovering after db error in pg, possibly leaving whole
 application/thread/process unusable [critical IMHO, not duplicate of
 #12953],
  * hiding db errors in the admin (no traceback after the fkey violation,
 no 500 page, no nothing, admin tries to silently ignore the problem)
 [rather bad],
  * not warning about cascading via generic relations in the admin [very
 bad since it silently removes user data],
  * not cascading far enough in some cases (#12953).

 Should I report these as separate issues?

 Shouldn't this report be reopened and track progress about
  * not recovering after db error in pg, possibly leaving whole
 application/thread/process unusable [critical IMHO, not duplicate of
 #12953]?

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

-- 
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] #11015: django-1.0.2 does not catch the exception that database backend first close the db connection.

[Django]

#11015: django-1.0.2 does not catch the exception that database backend first 
close
the db connection.
---+
  Reporter:  qingran   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 Ok - so, now that you have provided some instructions on how to reproduce
 the problem, it looks like a duplicate of #12953.

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

-- 
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] #11015: django-1.0.2 does not catch the exception that database backend first close the db connection.

[Django]

#11015: django-1.0.2 does not catch the exception that database backend first 
close
the db connection.
---+
  Reporter:  qingran   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by gkulewski):

 Another case, possibly similar and not involving reversion.

 Model called URL has generic foreign key to model Resource.
 Model Resource has reverse generic relation back to model URL.
 Model Foo has normal foreign key to model URL.

 Then I am trying to delete Resource instance (via admin). This silently
 (as in admin does not warn about it) cascades to URLs connected to it (/me
 thinks the admin should warn about it...). And this breaks because django
 forgot to cascade to Foo referencing that URL. Boom (a silent one, in
 pgsql, not reported outside by django for some strange reason). And later
 big boom because something didn't recover nicely from the first error.
 Result: application can't make any SQL queries anymore.

 Thinking more about it, previously described case may be a special case of
 this one (not cascading correctly, reversion probably uses some generic
 relations too or something). And bad error recovery after errors repoted
 by pgsql is another 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] #8158: Make possible to extend admin/index.html

[Django]

#8158: Make possible to extend admin/index.html
---+
  Reporter:  marinho   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by julien):

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

Comment:

 I don't think this ticket should have been closed. No decision has been
 taken yet about whether or not the template extension system will be
 improved to cover this issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #11015: django-1.0.2 does not catch the exception that database backend first close the db connection.

[Django]

#11015: django-1.0.2 does not catch the exception that database backend first 
close
the db connection.
---+
  Reporter:  qingran   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by gkulewski):

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

Comment:

 Still, closing obviously non-stupid bug reports that more than 3 people
 have with worksforme isn't the best way to solve the problem. And google
 shows several other such reports, IIRC some also in this trac. Maybe they
 should be merged or at least considered together somehow.

 Anyway, could you please try to reproduce scenario when django connected
 to postgresql tries to delete some object and does not succeed because
 deleting the row would violate foreign key constraint from some other
 table? I think one case of such exception may come from such scenario and
 may mean django (or python/django pg driver) does not recover gracefully
 from such error. For me it should throw some exception, render 500 page
 and (if needed) reopen the connection.

 What happens (from sql log):

 {{{
 LOG:  0: statement: DELETE FROM "auth_user" WHERE "id" IN (49)
 LOCATION:  exec_simple_query, postgres.c:848
 LOG:  0: duration: 0.167 ms
 LOCATION:  exec_simple_query, postgres.c:1074
 ERROR:  23503: update or delete on table "auth_user" violates foreign key
 constraint "reversion_revision_user_id_fkey" on table "reversion_revision"
 DETAIL:  Key (id)=(49) is still referenced from table
 "reversion_revision".
 LOCATION:  ri_ReportViolation, ri_triggers.c:3501
 STATEMENT:  END
 NOTICE:  25P01: there is no transaction in progress
 LOCATION:  UserAbortTransactionBlock, xact.c:3160
 STATEMENT:  ABORT
 LOG:  0: duration: 0.074 ms  statement: ABORT
 LOCATION:  exec_simple_query, postgres.c:1081
 LOG:  0: disconnection: session time: 0:00:00.303 user=formatec
 database=formatec host=[local]
 LOCATION:  log_disconnections, postgres.c:4041
 }}}

 Note: as of yet I have no idea how somebody managed to create non
 cascading fkey in django...


 {{{
Table
 "public.reversion_revision"
 Column|   Type   |
 Modifiers| Description
 
--+--+-+-
  id   | integer  | not null default
 nextval('reversion_revision_id_seq'::regclass) |
  date_created | timestamp with time zone | not null
 |
  user_id  | integer  |
 |
  comment  | text |
 |
 Indexes:
 "reversion_revision_pkey" PRIMARY KEY, btree (id)
 "reversion_revision_user_id" btree (user_id)
 Foreign-key constraints:
 "reversion_revision_user_id_fkey" FOREIGN KEY (user_id) REFERENCES
 auth_user(id) DEFERRABLE INITIALLY DEFERRED
 Has OIDs: no
 }}}

 But most probably this isn't the only cause of such problem. But it's
 quite possible that other cases will also mean bad recovery from strange
 errors in pgsql drivers in django or in the admin.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #11015: django-1.0.2 does not catch the exception that database backend first close the db connection.

[Django]

#11015: django-1.0.2 does not catch the exception that database backend first 
close
the db connection.
---+
  Reporter:  qingran   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 Replying to [comment:6 gkulewski]:
 > That was really helpful, thanks.
 >
 > Good it works for you. But it does not work for others. Look above. Use
 google to get many more such results. Something definitively _is_ broken,
 it's just hard to track it down.

 If this were a serious or regularly occurring problem, I wouldn't need to
 use Google. It would be a regular topic on Django-users, django-dev, or an
 observable issue on any one of the *many* Django sites that I and the rest
 of the core team manage personally. Neither of these things are true.

 > I will post if I have more info.

 Which is exactly what I asked you to do.

 Please consider this from our point of view. We have a report of a fairly
 generic sounding error, that can apparently be generated under unknown
 conditions. I can't reproduce the error myself. There has been no evidence
 presented that this is anything other than a cosmetic problem (ok - sure,
 there is an error message, but does that mean data is being lost, or just
 that it's an annoying log entry?). I can't even be certain that this isn't
 due to a misconfiguration of the servers in question -- for example, if
 your database server has a timeout set much shorter than your web server's
 page delivery timeout, for example.

 As I said - If someone is able to provide instructions for reproducing
 this bug -- even if only intermittently or on specific setups -- I'm only
 to happy to investigate further. However, there is literally *nothing* we
 can do until you can tell us how to reproduce the problem.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #11015: django-1.0.2 does not catch the exception that database backend first close the db connection.

[Django]

#11015: django-1.0.2 does not catch the exception that database backend first 
close
the db connection.
---+
  Reporter:  qingran   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by gkulewski):

 That was really helpful, thanks.

 Good it works for you. But it does not work for others. Look above. Use
 google to get many more such results. Something definitively _is_ broken,
 it's just hard to track it down. I will post if I have more info.

 As for now I know only that it is most probably related to:
 - the admin,
 - postgresql,
 - not OS specific (happens on linux and bsd at least),
 - cascading removes of complex object hierarchies in the admin (but maybe
 not only),
 - most probably these hierarchies have generic relations inside (may be
 the trigger or may not be).

 For example it happens when trying to remove an user (as in django.auth
 User) in my application because the user is linked to gazilion of other
 objects that should be also deleted (since django wants to cascade
 deletes). It also happens sometimes when trying to remove other objects
 that cascade and have generic relations in the hierarchy. But again - the
 exception happens way after the real error showing exactly nothing useful
 and there are so many objects involved that I can only guess what could
 the trigger be.

 Any help to track it down will be appreciated. If anybody else is really
 interested in it, that is.

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

-- 
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] #13117: Recenter OSMGeoAdmin widget with coordinates

[Django]

#13117: Recenter OSMGeoAdmin widget with coordinates
-+--
  Reporter:  anonymous   | Owner:  nobody  
Status:  new | Milestone:  
 Component:  GIS |   Version:  1.1 
Resolution:  |  Keywords:  admin widget OSMGeoAdmin
 Stage:  Unreviewed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by nbv4):

  * needs_better_patch:  => 0
  * summary:  recenter => Recenter OSMGeoAdmin widget with coordinates
  * 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] #13117: recenter

[Django]

#13117: recenter
--+-
 Reporter:  anonymous |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  GIS   | Version:  1.1   
 Keywords:  admin widget OSMGeoAdmin  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 By default, all mapplets that gets created by the
 contrib.gis.admin.GeoModelAdmin and contrib.gis.admin.OSMGeoAdmin classes
 are centered at 0,0, which makes it tedious to enter geographic data with
 that widget when you have the lattitude and longitude coordinates in
 numeric form.

 There should be a textbox for centering the map to a set of coordinates.

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

-- 
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] #13115: Display multiple widgets within a particular admin fieldset horizontally

[Django]

#13115: Display multiple widgets within a particular admin fieldset horizontally
---+
  Reporter:  delfick...@gmail.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by delfick):

 @foxulet : oh, I do read the documentation, it is fantastic documentation.
 I have the same problem as gabrielhurley, the number of times I have read
 the documentation and missed that.

 However, Thankyou so much for pointing that out, it is perfect.

 Sorry I missed 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] #13115: Display multiple widgets within a particular admin fieldset horizontally

[Django]

#13115: Display multiple widgets within a particular admin fieldset horizontally
---+
  Reporter:  delfick...@gmail.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by gabrielhurley):

 Thanks foxulet. I can't believe how many times I've read those docs
 without seeing that tidbit tucked in there! My bad!

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

-- 
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] #13115: Display multiple widgets within a particular admin fieldset horizontally

[Django]

#13115: Display multiple widgets within a particular admin fieldset horizontally
---+
  Reporter:  delfick...@gmail.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by foxulet):

 And once again the old RTFM applies, and with such a good documentation
 there's no reason why not to read the Django manual.

 To display multiple fields on the same line, wrap those fields in their
 own tuple. In this example, the first_name and last_name fields will
 display on the same line:

 {
 'fields': (('first_name', 'last_name'), 'address', 'city', 'state'),
 }

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

-- 
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] #13116: Specify in docs that template variables created e.g. by {%url%} are block-local

[Django]

#13116: Specify in docs that template variables created e.g. by {%url%} are 
block-
local
+---
  Reporter:  leif_p | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:  template,variables,scoping
 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] #13114: escapejs filter produces invalid JSON according to http://www.json.org/

[Django]

#13114: escapejs filter produces invalid JSON according to http://www.json.org/
+---
  Reporter:  David Danier   | Owner:  
nobody
Status:  new| Milestone:  
1.2   
 Component:  Uncategorized  |   Version:  
1.1   
Resolution: |  Keywords:

 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.

Re: [Django] #13112: Customize map type in contrib.gis.maps.google

[Django]

#13112: Customize map type in contrib.gis.maps.google
---+
  Reporter:  nbv4  | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  GIS   |   Version:  1.1  
Resolution:|  Keywords:  googlemaps, gmaps
 Stage:  Accepted  | Has_patch:  1
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] #13110: Multiple enclosures per feed's item

[Django]

#13110: Multiple enclosures per feed's item
+---
  Reporter:  Piaume | Owner:  nobody
Status:  new| Milestone:
 Component:  RSS framework  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Accepted
  * milestone:  1.3 =>

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13109: template tag ssi, doesn't resolve variable name for path

[Django]

#13109: template tag ssi, doesn't resolve variable name for path
--+-
  Reporter:  htumblin | Owner:  nobody 
Status:  closed   | Milestone: 
 Component:  Template system  |   Version:  1.1
Resolution:  duplicate|  Keywords:  templatetag ssi
 Stage:  Unreviewed   | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 Duplicate of #9666

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

-- 
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] #13108: contrib.auth test fails due to duplicate user

[Django]

#13108: contrib.auth test fails due to duplicate user
+---
  Reporter:  benreynwar | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Authentication |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Ready for checkin
  * milestone:  => 1.2

Comment:

 I'm guessing this problem can only be triggered with certain test
 ordering, because I can't force the error myself. However, it's a trivial
 fix, so it warrants correction.

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

-- 
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] #13106: Show confirmation page when deleting objects from an inline form

[Django]

#13106: Show confirmation page when deleting objects from an inline form
---+
  Reporter:  bmjames   | 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 |  
---+
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] #11015: django-1.0.2 does not catch the exception that database backend first close the db connection.

[Django]

#11015: django-1.0.2 does not catch the exception that database backend first 
close
the db connection.
---+
  Reporter:  qingran   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 "Something goes wrong some of the time" isn't a useful bug report. Unless
 you can provide specific conditions under which the problem can be
 reproduced, I'm closing worksforme. If you can provide a minimal set of
 models, views and data, and a server setup in which this problem can be
 observed, feel free to reopen.

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

-- 
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] #13104: greater differentiation in display of citations/quotes for trac tickets

[Django]

#13104: greater differentiation in display of citations/quotes for trac tickets
--+-
  Reporter:  rctay| Owner:  nobody
Status:  closed   | Milestone:
 Component:  Django Web site  |   Version:  1.1   
Resolution:  wontfix  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 Trac shouldn't be a repository of complex discussions, and making it
 easier to track complex discussions will only serve to encourage a
 practice we don't want. If a complex discussion is required, it should be
 happening on django-users/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] #12986: SelectDateField doesn't repost data when USE_L10N = True and LANGUAGE_CODE = 'nl'

[Django]

#12986: SelectDateField doesn't repost data when USE_L10N = True and 
LANGUAGE_CODE
= 'nl'
---+
  Reporter:  w...@go2people.nl  | Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  Forms |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  0 |  
---+
Comment (by bmihelac):

 Tests moved from widgets.py to to proper extra.py.
 Changed to always display blank choices for selects, so partial selection
 can be made and redisplayed.

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

-- 
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] #13103: say "model object's"

[Django]

#13103: say "model object's" 
+---
  Reporter:  rctay  | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
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.

Re: [Django] #12986: SelectDateField doesn't repost data when USE_L10N = True and LANGUAGE_CODE = 'nl'

[Django]

#12986: SelectDateField doesn't repost data when USE_L10N = True and 
LANGUAGE_CODE
= 'nl'
---+
  Reporter:  w...@go2people.nl  | Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  Forms |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  0 |  
---+
Changes (by bmihelac):

 * cc: bmihelac (added)

Comment:

 Attached is patch with tests.
 Code is slightly changed from original so it would also properly redisplay
 invalid dates when USE_L10N = True given that default input format consist
 of %Y, %m and %d format directives.

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

-- 
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] #13014: Document using LANGUAGE_CODE with the cache template tag

[Django]

#13014: Document using LANGUAGE_CODE with the cache template tag
+---
  Reporter:  yml| Owner: 
Status:  new| Milestone:  1.2
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by fgutier...@aureal.com.pe):

 * cc: fgutier...@aureal.com.pe (added)
  * has_patch:  0 => 1

Comment:

 Just added a doc patch. Hope it is correct.

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

-- 
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] #13085: GenericForeignKey.get_content_type fails if `object` or `id` evaluate to False. Should use 'is not None' test.

[Django]

#13085: GenericForeignKey.get_content_type fails if `object` or `id` evaluate to
False.  Should use 'is not None' test.
---+
  Reporter:  benreynwar| Owner:  benreynwar
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by benreynwar):

  * needs_tests:  1 => 0

Comment:

 I've included a new patch with a regression test included.  The object
 will be false if it has __nonzero__ is defined and returns False, or if
 __len__ is defined and returns 0.  Either of these should be possible
 without generic objects failing.  The bug would also cause problems if a
 generic object was used with content_type_id=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] #13115: Display multiple widgets within a particular admin fieldset horizontally

[Django]

#13115: Display multiple widgets within a particular admin fieldset horizontally
---+
  Reporter:  delfick...@gmail.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by foxulet):

 I have just reached the same issue as described here. And as in the
 graphic example above, I use grappelli too.
 Each field is in it's own div, and if we use field sets then all divs are
 grouped as we choose inside a single div.

 As it would be very difficult to change the code I have just opted to
 rearrange the fields inside that fieldset using CSS positioning.
 But a general layout system would be interesting.

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

-- 
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] #8886: loaddata deserializes BooleanFields wrong for inheriting model

[Django]

#8886: loaddata deserializes BooleanFields wrong for inheriting model
---+
  Reporter:  eri...@calytrix.com   | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  loaddata 
BooleanField
 Stage:  Design decision needed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 Will it EVER be fixed? It's annoying. Why shouldn't I have user =
 model.ForeignKey(User) in the first place? What am I going to call it?
 user_? user_whatever? Just, wtf.. This should be fixed for 1.2, you 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] #13116: Specify in docs that template variables created e.g. by {%url%} are block-local

[Django]

#13116: Specify in docs that template variables created e.g. by {%url%} are 
block-
local
+---
 Reporter:  leif_p  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Documentation   | Version:  1.1   
 Keywords:  template,variables,scoping  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Hi. {% url view_name as var %}  seems to create a var whose scope is the
 block where the tag was called.  This is not evident from the
 documentation, and took me a little while to figure out.

 I assume this is the behavior of any other templatetag that lets you
 create a variable.  Maybe you could add a section about scoping in the
 template system, and then have a link to it from the docs for each
 templatetag.

 I am using Django 1.1 on Google App Engine, if that makes a difference.

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

-- 
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] #13115: Display multiple widgets within a particular admin fieldset horizontally

[Django]

#13115: Display multiple widgets within a particular admin fieldset horizontally
---+
  Reporter:  delfick...@gmail.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by gabrielhurley):

 * cc: gabrielhurley (added)
  * summary:  Display controls in particular fieldset in django admin add
  page horizontally => Display multiple widgets
  within a particular admin fieldset horizontally

Comment:

 I think Ramiro may have slightly misunderstood what the OP was asking
 for... I'll bring it up on django-developers since I think this is still a
 worthwhile feature.

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

-- 
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] #13115: Display controls in particular fieldset in django admin add page horizontally

[Django]

#13115: Display controls in particular fieldset in django admin add page
horizontally
---+
  Reporter:  delfick...@gmail.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 You already can do that. Please read carefully the documentation of the
 `fieldsets` ModelAdmin option documentation:
 
http://docs.djangoproject.com/en/1.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fieldsets

 Post any further question to the django.users mailing list or the #django
 IRC channel.

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

-- 
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] #13115: Display controls in particular fieldset in django admin add page horizontally

[Django]

#13115: Display controls in particular fieldset in django admin add page
horizontally
---+
  Reporter:  delfick...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by gabrielhurley):

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

Comment:

 Just FYI, this is not the easiest thing to do. It's not that hard to make
 a single widget that has multiple fields on one row, but making multiple
 widgets coexist on one row requires changing how the admin templates
 render the rows.

 Right now it just uses a for loop to render each field in its own div, and
 render the appropriate label and widget inside that div.

 Making it allow horizontally-arranged bits would involve changes to the
 admin templates, admin stylesheet, and to the forms component itself (to
 add some sort of attribute determining which fields should be floated next
 to each other).

 You could implement it entirely in admin, but if you're going to do all
 that work, why not implement it for all forms instead of just admin
 forms...

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

-- 
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] r12777 - django/branches/releases/1.1.X/tests/regressiontests/views/tests

[noreply]

Author: kmtracey
Date: 2010-03-14 15:30:18 -0500 (Sun, 14 Mar 2010)
New Revision: 12777

Modified:
   django/branches/releases/1.1.X/tests/regressiontests/views/tests/defaults.py
Log:
[1.1.X] Made a Python 2.3 compatibility test fix.


Modified: 
django/branches/releases/1.1.X/tests/regressiontests/views/tests/defaults.py
===
--- 
django/branches/releases/1.1.X/tests/regressiontests/views/tests/defaults.py
2010-03-14 00:17:37 UTC (rev 12776)
+++ 
django/branches/releases/1.1.X/tests/regressiontests/views/tests/defaults.py
2010-03-14 20:30:18 UTC (rev 12777)
@@ -62,8 +62,8 @@
 
 def test_get_absolute_url_attributes(self):
 "A model can set attributes on the get_absolute_url method"
-self.assertTrue(getattr(UrlArticle.get_absolute_url, 'purge', False),
+self.failUnless(getattr(UrlArticle.get_absolute_url, 'purge', False),
 'The attributes of the original get_absolute_url must 
be added.')
 article = UrlArticle.objects.get(pk=1)
-self.assertTrue(getattr(article.get_absolute_url, 'purge', False),
+self.failUnless(getattr(article.get_absolute_url, 'purge', False),
 'The attributes of the original get_absolute_url must 
be added.')

-- 
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] #13035: Wrong documentation for admin and default managers

[Django]

#13035: Wrong documentation for admin and default managers
---+
  Reporter:  rasca | Owner:  gabrielhurley  
   
Status:  assigned  | Milestone:  1.2
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  manager objects 
admin docs
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by gabrielhurley):

  * summary:  Wrong documentaion or bad admin behaviour => Wrong
  documentation for admin and default managers

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

-- 
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] #13115: Display controls in particular fieldset in django admin add page horizontally

[Django]

#13115: Display controls in particular fieldset in django admin add page
horizontally
--+-
 Reporter:  delfick...@gmail.com  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hello,

 I wonder if it would be possible to be able to specify to display some
 controls in an admin add page to be next to each other instead of on top
 of each other.

 I'm not sure I've explained that very well, so I'll add too screenshots.
 First one is what i have currently for a particular project of mine. The
 other is a gimped version of what I want.

 Thankyou

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

-- 
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] #13110: Multiple enclosures per feed's item

[Django]

#13110: Multiple enclosures per feed's item
+---
  Reporter:  Piaume | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  RSS framework  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ericholscher):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * needs_tests:  => 0
  * milestone:  1.2 => 1.3

Comment:

 Feature Request.

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

-- 
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] #13100: Model docs imply that ModelForm will call Model.full_clean(), but it won't.

[Django]

#13100: Model docs imply that ModelForm will call Model.full_clean(), but it 
won't.
+---
  Reporter:  orokusaki  | Owner:  jkocherhans
Status:  assigned   | Milestone:  1.2
 Component:  Documentation  |   Version:  1.2-beta   
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by orokusaki):

 @russellm I don't think you even need to maintain 2 implementations. Did
 you check out my "New Version" above where I simply called full_clean()
 instead of using full_clean()'s implementation? Here's what I mean:


 Here is ModelForm._post_clean():


 {{{
 def _post_clean(self):
 exclude = self._get_validation_exclusions()
 opts = self._meta

 # Update the model instance with self.cleaned_data.
 self.instance = construct_instance(self, self.instance,
 opts.fields, opts.exclude)

 # Clean the model instance's fields.
 try:
 self.instance.clean_fields(exclude=exclude)
 except ValidationError, e:
 self._update_errors(e.message_dict)

 # Call the model instance's clean method.
 try:
 self.instance.clean()
 except ValidationError, e:
 self._update_errors({NON_FIELD_ERRORS: e.messages})

 # Validate uniqueness if needed.
 if self._validate_unique:
 self.validate_unique()
 }}}

 And here is Model.full_clean():


 {{{
 def full_clean(self, exclude=None):
 """
 Calls clean_fields, clean, and validate_unique, on the model,
 and raises a ``ValidationError`` for any errors that occured.
 """
 errors = {}
 if exclude is None:
 exclude = []

 try:
 self.clean_fields(exclude=exclude)
 except ValidationError, e:
 errors = e.update_error_dict(errors)

 # Form.clean() is run even if other validation fails, so do the
 # same with Model.clean() for consistency.
 try:
 self.clean()
 except ValidationError, e:
 errors = e.update_error_dict(errors)

 # Run unique checks, but only for fields that passed validation.
 for name in errors.keys():
 if name != NON_FIELD_ERRORS and name not in exclude:
 exclude.append(name)
 try:
 self.validate_unique(exclude=exclude)
 except ValidationError, e:
 errors = e.update_error_dict(errors)

 if errors:
 raise ValidationError(errors)
 }}}

 ModelForm._post_clean() is simply repeating the exact implementation of
 Model.full_clean(), instead of just calling Model.full_clean(). It's not a
 bug, but is not a good idea to repeat the implementation of an abstraction
 and very much breaks DRY. The only difference between its implementation
 and ModelForm._post_clean() is the internal check it makes before running
 validate_unique().

 The benefit it adds is that you can then override full_clean() to use a
 database transaction. This is absolutely necessary to do what Django
 recommends (model altering inside of clean()).

 Pretty please change this.

 Again, here is my patch:

 ModelForm._post_clean():


 {{{
 def _post_clean(self):
 exclude = self._get_validation_exclusions()
 opts = self._meta

 # Update the model instance with self.cleaned_data.
 self.instance = construct_instance(self, self.instance,
 opts.fields, opts.exclude)

 # Perform all model validation by using the already implemented
 Model.full_clean() (which saves time by not having 2 implementations of
 almost the exact same code)
 try:
 self.instance.full_clean(exclude=exclude)
 except ValidationError, e:
 self._update_errors(e.message_dict)
 }}}

 Again, I will test it and perform all steps along the way if this is
 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.

[Django] #13114: escapejs filter produces invalid JSON according to http://www.json.org/

[Django]

#13114: escapejs filter produces invalid JSON according to http://www.json.org/
---+
 Reporter:  David Danier   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The escapejs filter uses \x.. to escape special characters inside strings.
 According to http://www.json.org/ this is wrong, \u should be used
 instead.

 This actually bite me while using jQuery. Since jQuery 1.4 the JSON-
 responses get validated, so all my JSON-responses (that are constructed
 using escapejs) got broken.

 Patch to fix this should be rather trivial.

 Steps to reproduce:
 {{{
 >>> from django.template.defaultfilters import escapejs
 >>> print escapejs('just-a-test')
 just\x2Da\x2Dtest
 }}}

 Open http://www.jsonlint.com/ and paste {{{ ["just\x2Da\x2Dtest"] }}}, hit
 Validate.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #12998: RSS feed test fails in various situations due to time check

[Django]

#12998: RSS feed test fails in various situations due to time check
+---
  Reporter:  Leo| Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  RSS framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 Replying to [comment:4 kmtracey]:
 > The end of DST in the US has revealed another problem with the time
 check in this test, see: #13113
 >

 That would be the start of DST, not the end. Really missing my hour of
 sleep.

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

-- 
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] #12998: RSS feed test fails in various situations due to time check

[Django]

#12998: RSS feed test fails in various situations due to time check
+---
  Reporter:  Leo| Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  RSS framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

  * summary:  RSS feed test fails on windows => RSS feed test fails in
  various situations due to time check

Comment:

 Replying to [comment:3 anonymous]:
 > Is the workaround then to just set `TIMEZONE` in my settings for running
 the tests?

 That doesn't work on Windows, and if someone wants/needs to run with
 TIMEZONE=None it's also not good to have to put something else in the test
 settings file.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #12998: RSS feed test fails on windows

[Django]

#12998: RSS feed test fails on windows
+---
  Reporter:  Leo| Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  RSS framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 The end of DST in the US has revealed another problem with the time check
 in this test, see: #13113

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

-- 
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] #13113: Syndication test fails after end of DST

[Django]

#13113: Syndication test fails after end of DST
+---
  Reporter:  jezdez | Owner:  nobody  
Status:  closed | Milestone:  1.2 
 Component:  RSS framework  |   Version:  1.2-beta
Resolution:  duplicate  |  Keywords:  
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

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

Comment:

 We've already got a ticket open for this test's time check being broken in
 various environments: #12988

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

-- 
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] #2170: db lookup methods not case sensitive on mysql

[Django]

#2170: db lookup methods not case sensitive on mysql
---+
  Reporter:  derelm| Owner:  PhiR
Status:  closed| Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  wontfix   |  Keywords:  
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 Yes, the fix for this was reverted, after much investigation and attempt
 to make it work. The problems it introduced were worse than the problem it
 fixed. So this bug is essentially wontfix. (Though if I'm remembering
 right there may be another one open to look for a better fix -- but the
 fix here is definitely not viable.) See:
 http://code.djangoproject.com/ticket/2170#comment:11 and the other tickets
 linked.

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

-- 
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] #10736: Add Uruguayan (uy) localflavor

[Django]

#10736: Add Uruguayan (uy) localflavor
-+--
  Reporter:  gonz| Owner:  nobody   
 
Status:  closed  | Milestone:  1.2  
 
 Component:  django.contrib.localflavor  |   Version:  SVN  
 
Resolution:  fixed   |  Keywords:  localflavor, 
l10n, uy, uruguay
 Stage:  Accepted| Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Comment (by john3050):

 Replying to [comment:5 jezdez]:
 > (In [12041]) Fixed #10736 - Added Uruguayan (uy) localflavor. Thanks
 [http://treatmentofmesothelioma.org/mesothelioma.html mesothelioma] to
 Gonzalo Saavedra for providing the [http://zolpo.com/ insurance quotes]
 patch.
 Thank you 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] #13113: Syndication test fails after end of DST

[Django]

#13113: Syndication test fails after end of DST
+---
  Reporter:  jezdez | Owner:  nobody  
Status:  new| Milestone:  1.2 
 Component:  RSS framework  |   Version:  1.2-beta
Resolution: |  Keywords:  
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

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

[Django] #13113: Syndication test fails after end of DST

[Django]

#13113: Syndication test fails after end of DST
-+--
   Reporter:  jezdez |Owner:  nobody
 Status:  new|Milestone:
  Component:  RSS framework  |  Version:  1.2-beta  
   Keywords: |Stage:  Unreviewed
  Has_patch:  0  |   Needs_docs:  0 
Needs_tests:  0  |   Needs_better_patch:  0 
-+--
 {{{
 ==
 FAIL: test_rss2_feed
 (regressiontests.syndication.tests.SyndicationFeedTest)
 --
 Traceback (most recent call last):
   File
 "/Users/Jannis/Code/git/django/tests/regressiontests/syndication/tests.py",
 line 67, in test_rss2_feed
 'copyright': 'Copyright (c) 2007, Sally Smith',
   File
 "/Users/Jannis/Code/git/django/tests/regressiontests/syndication/tests.py",
 line 25, in assertChildNodeContent
 elem.getElementsByTagName(k)[0].firstChild.wholeText, v)
 AssertionError: u'Thu, 03 Jan 2008 13:30:00 -0500' != 'Thu, 03 Jan 2008
 13:30:00 -0600'
 }}}

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

-- 
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] #7539: Add ON DELETE and ON UPDATE support to Django

[Django]

#7539: Add ON DELETE and ON UPDATE support to Django
---+
  Reporter:  glassfordm| Owner: 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  feature
 Stage:  Design decision needed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by paluh):

 * cc: pal...@gmail.com (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.