[Django] #17281: AdminErrorHandler silently fails if the log message contains newlines

[Django]

#17281: AdminErrorHandler silently fails if the log message contains newlines
+
   Reporter:  russellm  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Core (Other)  |Version:
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 If you have loggers configured with an django.utils.log.AdminEmailHandler,
 and you log a message that has a newline in it, the log message is handled
 by the logger, but is silently discarded.

 For example if you sent the following:
 {{{
 logger.error('This is a\n test message')
 }}}

 The log message will be correctly written to any text-based log handlers
 or console log handlers, but the AdminEmailHandler silently fails.

 This is because the subject of an email can't contain newlines.

 Given that the AdminEmailHandler is intended as a mechanism for reporting
 serious errors, it's pretty bad that it can fail silently due to the
 contents of the message it's reporting. The "subject" of the log email
 should be cleansed of newlines before the call to mail_admins is made.

 This cleansing could also be performed in the mail utilities themselves.
 However, I'm not convinced this is the right place; the general mail tools
 have "fail_silently" as an option, so it would be possible to handle this
 error in a better way. Failing is not an option during logging, so we
 should make sure that the messages to be sent are appropriately cleansed.

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

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

Re: [Django] #17256: ContentTypeManager.get_by_natural_key method doesn't cache

[Django]

#17256: ContentTypeManager.get_by_natural_key method doesn't cache
--+
 Reporter:  defaultwombat |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:  cache contenttypes| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

 * needs_tests:  1 => 0


Comment:

 Added tests

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

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

Re: [Django] #16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional warning.

[Django]

#16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional 
warning.
-+-
 Reporter:  cyclops  |Owner:
 Type:   |  yasar11732
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by yasar11732):

 Sorry for late response, I was busy lately. How about latest patch? And
 about your question, some features need some TEMPLATE_CONTEXT_PROCESSORS
 to be loaded for example.

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

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

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
-+-
 Reporter:  ikelly   |Owner:
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle postgresql|  Needs documentation:  0
  mysql schemas  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by anonymous):

 I have the same need, at the moment I'm trying to use this postgresql
 specific "hack" https://github.com/tuttle/django-schemata

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

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

Re: [Django] #16847: Session Cookies should default to HttpOnly = True

[Django]

#16847: Session Cookies should default to HttpOnly = True
--+
 Reporter:  PaulM |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.sessions  |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by PaulM):

 You're right, it was in the wrong place. Fixed that and improved the tests
 a bit in r17140 and r17141.

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

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

Re: [Django] #16817: Add a guide on code coverage to contributing docs

[Django]

#16817: Add a guide on code coverage to contributing docs
-+-
 Reporter:  julien   |Owner:
 Type:   |  krzysiumed
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by krzysiumed):

 * owner:  nobody => krzysiumed
 * 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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7623: Multi-table inheritance does not allow linking new instance of child model to existing parent model instance.

[Django]

#7623: Multi-table inheritance does not allow linking new instance of child 
model
to existing parent model instance.
-+-
 Reporter:  brooks.travis@…  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  model-inheritance,   |  decision needed
  multi-table-inheritance|  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Nan):

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


Comment:

 Here's a more reasonable example...

 {{{
 # models.py
 class Place(models.Model):
 name = models.CharField(max_length=50)
 address = models.CharField(max_length=80)

 class Restaurant(Place):
 place = models.OneToOneField(Place, parent_link=True,
 related_name='restaurant')
 serves_hot_dogs = models.BooleanField()
 serves_pizza = models.BooleanField()
 }}}

 Now, say we have a bunch of Place objects in the database, and a form
 where users can inform us what sort of business a particular Place is (OK,
 this is a contrived example, but I'm sure you can see that this could be a
 reasonable use case for some types of data).

 {{{
 # somewhere in views.py
 p = Place.objects.get(pk=1)
 restaurant = Restaurant(**{
 'place': p,
 'serves_hot_dogs': False,
 'serves_pizza': True,
 })
 restaurant.save()
 }}}

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

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

Re: [Django] #17069: Extend the error logger's API to allow ignoring some errors

[Django]

#17069: Extend the error logger's API to allow ignoring some errors
---+
 Reporter:  julien |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by dlowe):

 FWIW here's the logging filter class I'm using to narrowly suppress
 IOError exceptions raised from _get_raw_post_data():

 {{{
 import sys, traceback
 class _SuppressUnreadablePost(object):
 def filter(self, record):
 _, exception, tb = sys.exc_info()
 if isinstance(exception, IOError):
 for _, _, function, _ in traceback.extract_tb(tb):
 if function == '_get_raw_post_data':
 return False
 return True
 }}}

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

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

Re: [Django] #17280: newform documentation link is gone

[Django]

#17280: newform documentation link is gone
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * component:  Forms => Documentation
 * needs_tests:   => 0
 * version:   => SVN
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 The offending link is in docs/releases/0.96.txt and it points to
 http://www.djangoproject.com/documentation/0.96/newforms/

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

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

[Django] #17280: newform documentation link is gone

[Django]

#17280: newform documentation link is gone
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I went back to an old release description page to try to find information
 about the newforms feature that is giving me an error.  there was a link
 in the page to "newforms documentation" that sent me to an error page
 where I clicked provide feedback.

 please leave information about old revs available so I can understand what
 has changed and how to update my code.

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

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

Re: [Django] #14370: Adding support for Autocomplete in contrib.admin

[Django]

#14370: Adding support for Autocomplete in contrib.admin
-+-
 Reporter:  tyrion   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  autocomplete,| Triage Stage:  Accepted
  jquery, javascript, widgets,   |  Needs documentation:  1
  admin  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  1
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Thijs Triemstra ):

 * cc: thijs.triemstra@… (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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17091: Djano 1.4 SimpleListFilter 'selected' option issue

[Django]

#17091: Djano 1.4 SimpleListFilter 'selected' option issue
-+-
 Reporter:  tejinderss@… |Owner:  julien
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  SimpleListFilter,| Triage Stage:  Design
  FilterSpec |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by julien):

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


Comment:

 I don't think we need to modify the documentation as it's clear-enough in
 relation to the problem reported in this ticket. I believe the original
 confusion here was in fact caused by that bug, which is now fixed.
 Therefore considering this ticket fixed 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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17279: Missing step in "Writing Your First Django App, Part 2"

[Django]

#17279: Missing step in "Writing Your First Django App, Part 2"
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3-beta
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by ramiro):

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


Comment:

 It is right there, in the second item of the bulleted list:

 https://docs.djangoproject.com/en/1.3/intro/tutorial02/#activate-the-
 admin-site

 Quoting:

 {{{
 #!rst
 Activate the admin site
 ===

 The Django admin site is not activated by default -- it's an opt-in thing.
 To
 activate the admin site for your installation, do these three things:

  * Add ``"django.contrib.admin"`` to your `INSTALLED_APPS` setting.

  * Run ``python manage.py syncdb``. Since you have added a new application
to `INSTALLED_APPS`, the database tables need to be updated.

  * ...
 }}}

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

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

Re: [Django] #17253: Add foreign object in memory without saving to database

[Django]

#17253: Add foreign object in memory without saving to database
-+-
 Reporter:  cyberkoa@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Why not add method send_invites to the Group model, and first save the
 group, then add the members, and then call send_invites. Having a side
 effect of sending invites to .save() isn't IMHO the way to go. It wouldn't
 be surprising if you hit a situation where you accidentally send invites
 because of that side effect.

 In short: the use case you have is solvable without altering the behaviour
 of .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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17279: Missing step in "Writing Your First Django App, Part 2"

[Django]

#17279: Missing step in "Writing Your First Django App, Part 2"
---+--
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.3-beta
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 The section "Activate the Admin Site" doesn't tell you to run 'python
 manage.py syncdb' after uncommenting the admin lines. This is apparently
 an important step, and not obvious from the error you get if you try to
 save a change.

 BTW, thanks for putting together such a great tutorial -- it's been very
 helpful.

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

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

[Django] #17278: Unlike sqlite, spatialite requires NAME to be set to run the tests

[Django]

#17278: Unlike sqlite, spatialite requires NAME to be set to run the tests
+
   Reporter:  aaugustin |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  GIS   |Version:
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 See
 
http://ci.djangoproject.com/job/Django/database=spatialite,python=python2.7/504/console

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

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

Re: [Django] #17253: Add foreign object in memory without saving to database

[Django]

#17253: Add foreign object in memory without saving to database
-+-
 Reporter:  cyberkoa@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cyberkoa@…):

 Sorry that need to call save() twice.  And my case is not as complex as
 M2M by the way.

 Actually my case is as below, we are creating a Sports community website.
 When a user create a Sport Group, at the same time , the user can invite
 other users to join as member .
 In this case , each invited users will be created as a record in
 GroupMember , with status field as "invited"

 When this Group is created, we want to notify the users who has set the
 favourite sport same as the new Group created BUT skip those "invited"
 members.

 If I would like to do it in views.py , it can be done. However , I would
 like to do it in the models.py because I feel that this code should be in
 the models.py.

 Therefore, I plan to override the save() in Group. In this case , I need
 to know "invited" users in the save() , so that I can skip them from the
 notification.

 If I save Group before adding the GroupMember , in the save function() , I
 can't retrieve this information (can I pass parameters ?)

 example : I created a football Group

 class  Group
 def save()
 super().save() ..

 # notify to all users who has 'football' as favourite sport but
 skip the invited users
 notify()

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

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

Re: [Django] #17015: IntegrityError: ORA-01400: cannot insert NULL into (...."AUTH_PERMISSION"."ID") when running syncdb with Oracle

[Django]

#17015: IntegrityError: ORA-01400: cannot insert NULL into
("AUTH_PERMISSION"."ID")  when running syncdb with Oracle
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  oracle, trigger  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ikelly):

 It should, yes.  I'll have to do some digging to try to figure out why it
 evidently doesn't.

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

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

Re: [Django] #16778: Bad geometry escape in postgis

[Django]

#16778: Bad geometry escape in postgis
+-
 Reporter:  piro|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  1.3
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+-

Comment (by anonymous):

 Replying to [comment:6 stephaner]:
 > Just for the sake of clarity, the PostgreSQL option is:
 >
 > `standard_conforming_strings = off`
 >
 > See the trailing `s` at the end.
 >
 > Now that major Linux distributions have switched to PostgreSQL 9.1 (eg.
 Fedora 16, Ubuntu 11.10), this bug impacts many more people.
 > So as said by pjdelport, it would great to include this fix in Django
 1.3.2.


 The current policy for backporting fixes to maintenance branches (like
 1.3.x) is that they only get fixes for data loss or security problems. So
 unfortunately that means this fix won't be backported to such branch.

 The good news is that you can apply this four-line patch by yourself to
 your copy of Django. By doing this:

 * You know there is not other change to 1.3.1 than the fix for this issue
 (some shops have policies about only using officially released versions of
 software, this would mean breaking that but OTOH this item means you can
 keep risks low when you have heavily invested and tested 1.3.1)
 * You don't have to wait for Django 1.3.2
 * You don't have to wait for Django 1.4

 In the practice, a line needs to be drawn regarding compatibility with
 features of other parts of the stack. Django 1.3 was releases in March
 2011 and Postgres 9.1 in September 2011. If every release of Django would
 need to be updated for every change of behavior of every new version piece
 of software that appear in every new OS release, the task of adapting to
 them would be a never ending one. That's what the development trunk in the
 repository is for.

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

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

Re: [Django] #16778: Bad geometry escape in postgis

[Django]

#16778: Bad geometry escape in postgis
+-
 Reporter:  piro|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  1.3
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+-

Comment (by stephaner):

 Just for the sake of clarity, the PostgreSQL option is:

 `standard_conforming_strings = off`

 See the trailing `s` at the end.

 Now that major Linux distributions have switched to PostgreSQL 9.1 (eg.
 Fedora 16, Ubuntu 11.10), this bug impacts many more people.
 So as said by pjdelport, it would great to include this fix in Django
 1.3.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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17144 - django/trunk/django/contrib/humanize

[noreply]

Author: Alex
Date: 2011-11-22 01:20:58 -0800 (Tue, 22 Nov 2011)
New Revision: 17144

Modified:
   django/trunk/django/contrib/humanize/tests.py
Log:
Fixed the humanize tests to work properly with a pure-python datetime module 
(platforms such as PyPy)

Modified: django/trunk/django/contrib/humanize/tests.py
===
--- django/trunk/django/contrib/humanize/tests.py   2011-11-22 09:14:09 UTC 
(rev 17143)
+++ django/trunk/django/contrib/humanize/tests.py   2011-11-22 09:20:58 UTC 
(rev 17144)
@@ -1,5 +1,7 @@
 from __future__ import with_statement
+
 import datetime
+import new
 
 from django.template import Template, Context, defaultfilters
 from django.test import TestCase
@@ -182,12 +184,13 @@
 from django.contrib.humanize.templatetags import humanize
 from django.utils import timesince
 orig_humanize_datetime = humanize.datetime
-orig_timesince_datetime = timesince.datetime.datetime
+orig_timesince_datetime = timesince.datetime
 humanize.datetime = MockDateTime
+timesince.datetime = new.module("mock_datetime")
 timesince.datetime.datetime = MockDateTime
 
 try:
 self.humanize_tester(test_list, result_list, 'naturaltime')
 finally:
 humanize.datetime = orig_humanize_datetime
-timesince.datetime.datetime = orig_timesince_datetime
+timesince.datetime = orig_timesince_datetime

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

Re: [Django] #17252: Multi-sort in admin does not respect initial admin_order_field

[Django]

#17252: Multi-sort in admin does not respect initial admin_order_field
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  SVN
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  multi-sort, admin,   | Triage Stage:  Accepted
  ordering   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-
Changes (by julien):

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


Comment:

 In [17143]:
 {{{
 #!CommitTicketReference repository="" revision="17143"
 Fixed #17252 -- Fixed a minor regression introduced by the work in #11868,
 where the default sorted columns wouldn't correctly be visually
 represented in the changelist table headers if those columns referred to
 non model fields. Thanks to sebastian for the report and patch.
 }}}

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

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

[Changeset] r17143 - in django/trunk: django/contrib/admin/views tests/regressiontests/admin_views

[noreply]

Author: julien
Date: 2011-11-22 01:14:09 -0800 (Tue, 22 Nov 2011)
New Revision: 17143

Modified:
   django/trunk/django/contrib/admin/views/main.py
   django/trunk/tests/regressiontests/admin_views/admin.py
   django/trunk/tests/regressiontests/admin_views/models.py
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Fixed #17252 -- Fixed a minor regression introduced by the work in #11868, 
where the default sorted columns wouldn't correctly be visually represented in 
the changelist table headers if those columns referred to non model fields. 
Thanks to sebastian for the report and patch.

Modified: django/trunk/django/contrib/admin/views/main.py
===
--- django/trunk/django/contrib/admin/views/main.py 2011-11-22 07:44:26 UTC 
(rev 17142)
+++ django/trunk/django/contrib/admin/views/main.py 2011-11-22 09:14:09 UTC 
(rev 17143)
@@ -169,6 +169,28 @@
 ordering = self.lookup_opts.ordering
 return ordering
 
+def get_ordering_field(self, field_name):
+"""
+Returns the proper model field name corresponding to the given
+field_name to use for ordering. field_name may either be the name of a
+proper model field or the name of a method (on the admin or model) or a
+callable with the 'admin_order_field' attribute. Returns None if no
+proper model field name can be matched.
+"""
+try:
+field = self.lookup_opts.get_field(field_name)
+return field.name
+except models.FieldDoesNotExist:
+# See whether field_name is a name of a non-field
+# that allows sorting.
+if callable(field_name):
+attr = field_name
+elif hasattr(self.model_admin, field_name):
+attr = getattr(self.model_admin, field_name)
+else:
+attr = getattr(self.model, field_name)
+return getattr(attr, 'admin_order_field', None)
+
 def get_ordering(self, request):
 params = self.params
 # For ordering, first check the if exists the "get_ordering" method
@@ -176,7 +198,6 @@
 # options, then check the object's default ordering. Finally, a
 # manually-specified ordering from the query string overrides anything.
 ordering = self.model_admin.get_ordering(request) or 
self._get_default_ordering()
-
 if ORDER_VAR in params:
 # Clear ordering and used params
 ordering = []
@@ -185,33 +206,18 @@
 try:
 none, pfx, idx = p.rpartition('-')
 field_name = self.list_display[int(idx)]
-try:
-f = self.lookup_opts.get_field(field_name)
-except models.FieldDoesNotExist:
-# See whether field_name is a name of a non-field
-# that allows sorting.
-try:
-if callable(field_name):
-attr = field_name
-elif hasattr(self.model_admin, field_name):
-attr = getattr(self.model_admin, field_name)
-else:
-attr = getattr(self.model, field_name)
-field_name = attr.admin_order_field
-except AttributeError:
-continue # No 'admin_order_field', skip it
-else:
-field_name = f.name
-
-ordering.append(pfx + field_name)
-
+order_field = self.get_ordering_field(field_name)
+if not order_field:
+continue # No 'admin_order_field', skip it
+ordering.append(pfx + order_field)
 except (IndexError, ValueError):
 continue # Invalid ordering specified, skip it.
-
 return ordering
 
 def get_ordering_field_columns(self):
-# Returns a SortedDict of ordering field column numbers and asc/desc
+"""
+Returns a SortedDict of ordering field column numbers and asc/desc
+"""
 
 # We must cope with more than one column having the same underlying 
sort
 # field, so we base things on column numbers.
@@ -227,19 +233,10 @@
 order_type = 'desc'
 else:
 order_type = 'asc'
-index = None
-try:
-# Search for simply field name first
-index = list(self.list_display).index(field)
-except ValueError:
-# No match, but there might be a match if we take into
-# account 'admin_order_field'
-for _index, attr in enumerate(self.list_display):
-

Re: [Django] #17015: IntegrityError: ORA-01400: cannot insert NULL into (...."AUTH_PERMISSION"."ID") when running syncdb with Oracle

[Django]

#17015: IntegrityError: ORA-01400: cannot insert NULL into
("AUTH_PERMISSION"."ID")  when running syncdb with Oracle
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  oracle, trigger  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * keywords:   => oracle, trigger


Comment:

 Replying to [comment:4 ikelly]:
 > Sounds to me like the sequence trigger is missing for some reason.  Can
 you verify whether the TEST1.AUTH_PERMISSION table has any triggers on it?



 You are right, I checked the "AUTH_PERMISSION" table and it does not have
 a trigger.

 On other instances that work with oracle, the trigger "AUTH_PERMISSION_TR"
 exists.

 I did the following to resolve this issue.

 drop table AUTH_PERMISSION; grant trigger to TEST1; python manage.py
 syncdb;

 I didn't get the error anymore and verified the trigger was created.


 It seems that on the initial syncdb it was able to create all objects
 except triggers because it didn't have that permission.
 Shouldn't the syncdb catch the permissions error for triggers like it does
 on sequence?

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

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