Re: [Django] #17829: Admin date filter's "Past 7 days" actually returns past 8 days.

[Django]

#17829: Admin date filter's "Past 7 days" actually returns past 8 days.
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  closed
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   |  worksforme
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 `list_filter` on a DateTimeField is mostly useful if applied to a field
 that stores a creation or modification date.

 It's Monday, 8am. Do you expect to see the updates of last Monday?
 Probably yes.

 In this case, the current code shows 7,33 days worth of data in this case
 (assuming you have no dates in the future). Your "easy fix" would show
 6,33 days instead. I'm not convinced this would be significantly more
 correct.

 We'd need a good reason, good enough to warrant breaking backwards
 compatibility, to change this.

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

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

Re: [Django] #17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when USE_TZ is set.

[Django]

#17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when 
USE_TZ is
set.
-+-
 Reporter:  Glenn Washburn   |Owner:  aaugustin
  |   Status:  new
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * severity:  Normal => Release blocker


-- 
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] #17831: Admin's date list filter's "This month/year" and "Today" are incorrect when USE_TZ is set (with the postgres backend).

[Django]

#17831: Admin's date list filter's "This month/year" and "Today" are incorrect 
when
USE_TZ is set (with the postgres backend).
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  closed
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  duplicate
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Indeed, this has the same root cause as #17260, which is a known
 limitation of the current implementation of time zone support.

 Until now, #17260 didn't include "`date_filter` on a `DateTimeField`" in
 the list of problems; I've added it.

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

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

Re: [Django] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Description changed by aaugustin:

Old description:

> Aggregation on dates is performed in UTC (the database timezone) when
> `settings.USE_TZ = True`, while an end user may expect its current time
> zone to be taken into account. This is a known problem in the initial
> implementation of time zone support.
>
> It affects:
> - `QuerySet.dates()`,
> -  the `year`, `month`, `day`, and `week_day` lookups,
> - `date_hierarchy` in the admin,
> - the date based generic views.

New description:

 Aggregation on dates is performed in UTC (the database timezone) when
 `settings.USE_TZ = True`, while an end user may expect its current time
 zone to be taken into account. This is a known problem in the initial
 implementation of time zone support.

 It affects:
 - `QuerySet.dates()`,
 -  the `year`, `month`, `day`, and `week_day` lookups,
 - `date_hierarchy` and `list_filter` or a `DateTimeField` in the admin,
 - the date based generic views.

--

-- 
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] #17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled

[Django]

#17260: `QuerySet.dates()` is computed in UTC when time zone support is enabled
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


-- 
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] #17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when USE_TZ is set.

[Django]

#17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when 
USE_TZ is
set.
-+-
 Reporter:  Glenn Washburn   |Owner:  aaugustin
  |   Status:  new
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 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
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

Re: [Django] #16433: Missing 'help_text' in admin form when showing the back reference for a OneToOne field.

[Django]

#16433: Missing 'help_text' in admin form when showing the back reference for a
OneToOne field.
---+
 Reporter:  chris@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by admackin@…):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17832: setup.py - purelib comment

[Django]

#17832: setup.py - purelib comment
--+--
 Reporter:  mk|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  SVN
 Severity:  Normal|   Keywords:  setup.py
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+--
 A comment in django/setup.py regarding purelib is exactly the wrong way
 around. This problem exists since Oct 16, 2006.

 The following change fixes the comment:

 {{{
 diff --git a/setup.py b/setup.py
 index fa42cac..72a38d0 100644
 --- a/setup.py
 +++ b/setup.py
 @@ -36,7 +36,7 @@ def fullsplit(path, result=None):
  return result
  return fullsplit(head, [tail] + result)

 -# Tell distutils to put the data_files in platform-specific installation
 +# Tell distutils to not put the data_files in platform-specific
 installation
  # locations. See here for an explanation:
  #
 
http://groups.google.com/group/comp.lang.python/browse_thread/thread/35ec7b2fed36eaec/2105ee4d9e8042cb
  for scheme in INSTALL_SCHEMES.values():
 }}}

-- 
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] #17831: Admin's date list filter's "This month/year" and "Today" are incorrect when USE_TZ is set (with the postgres backend).

[Django]

#17831: Admin's date list filter's "This month/year" and "Today" are incorrect 
when
USE_TZ is set (with the postgres backend).
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by akaariai):

 This is related to #17260, if not duplicate. Fixing this generally is
 going to be probably somewhat hard. I have one idea, though: you could
 manually add/subtract the offset from the datetime when doing the
 filtering. It is not perfect (DST not taken into account correctly). But
 it might be easy enough to do for 1.4.

-- 
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] #17831: Admin's date list filter's "This month/year" and "Today" are incorrect when USE_TZ is set (with the postgres backend).

[Django]

#17831: Admin's date list filter's "This month/year" and "Today" are incorrect 
when
USE_TZ is set (with the postgres backend).
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

 * needs_better_patch:   => 0
 * severity:  Normal => Release blocker
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> This may be applicable to other backends, but I'm not sure.
>
> When using USE_TZ the backend connection is set to use UTC.  So
> __year/__month/__day lookup filters will filter where the UTC timestamp
> has a year/month/day of the lookup value.  However, what's really desired
> is to use the timestamp at the current timezone.  For example, the
> current code when filtering for "today" datetimes which are not in UTC
> can potentially return a list of matching records where the set of days
> being displayed is more than one.

New description:

 This may be applicable to other backends, but I'm not sure.

 When using USE_TZ the backend connection is set to use UTC.  So
 `__year`/`__month`/`__day` lookup filters will filter where the UTC
 timestamp has a year/month/day of the lookup value.  However, what's
 really desired is to use the timestamp at the current timezone.  For
 example, the current code when filtering for "today" datetimes which are
 not in UTC can potentially return a list of matching records where the set
 of days being displayed is more than one.

--

Comment:

 I haven't been able to review this fully but this seems like a potential
 release blocker.

-- 
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] r17665 - in django/trunk: django/contrib/auth/management/commands django/contrib/auth/tests docs/ref

[noreply]

Author: SmileyChris
Date: 2012-03-04 20:17:55 -0800 (Sun, 04 Mar 2012)
New Revision: 17665

Modified:
   django/trunk/django/contrib/auth/management/commands/changepassword.py
   django/trunk/django/contrib/auth/management/commands/createsuperuser.py
   django/trunk/django/contrib/auth/tests/__init__.py
   django/trunk/django/contrib/auth/tests/management.py
   django/trunk/docs/ref/django-admin.txt
Log:
Fixes #17327 -- Add --database option to createsuperuser and change password 
management commands

Modified: django/trunk/django/contrib/auth/management/commands/changepassword.py
===
--- django/trunk/django/contrib/auth/management/commands/changepassword.py  
2012-03-05 03:41:01 UTC (rev 17664)
+++ django/trunk/django/contrib/auth/management/commands/changepassword.py  
2012-03-05 04:17:55 UTC (rev 17665)
@@ -1,8 +1,17 @@
+import getpass
+from optparse import make_option
+
 from django.core.management.base import BaseCommand, CommandError
 from django.contrib.auth.models import User
-import getpass
+from django.db import DEFAULT_DB_ALIAS
 
+
 class Command(BaseCommand):
+option_list = BaseCommand.option_list + (
+make_option('--database', action='store', dest='database',
+default=DEFAULT_DB_ALIAS, help='Nominates a database to query for 
the user. '
+'Defaults to the "default" database.'),
+)
 help = "Change a user's password for django.contrib.auth."
 
 requires_model_validation = False
@@ -23,11 +32,11 @@
 username = getpass.getuser()
 
 try:
-u = User.objects.get(username=username)
+u = 
User.objects.using(options.get('database')).get(username=username)
 except User.DoesNotExist:
 raise CommandError("user '%s' does not exist" % username)
 
-print "Changing password for user '%s'" % u.username
+self.stdout.write("Changing password for user '%s'\n" % u.username)
 
 MAX_TRIES = 3
 count = 0
@@ -36,7 +45,7 @@
 p1 = self._get_pass()
 p2 = self._get_pass("Password (again): ")
 if p1 != p2:
-print "Passwords do not match. Please try again."
+self.stdout.write("Passwords do not match. Please try 
again.\n")
 count = count + 1
 
 if count == MAX_TRIES:

Modified: 
django/trunk/django/contrib/auth/management/commands/createsuperuser.py
===
--- django/trunk/django/contrib/auth/management/commands/createsuperuser.py 
2012-03-05 03:41:01 UTC (rev 17664)
+++ django/trunk/django/contrib/auth/management/commands/createsuperuser.py 
2012-03-05 04:17:55 UTC (rev 17665)
@@ -6,10 +6,12 @@
 import re
 import sys
 from optparse import make_option
+
 from django.contrib.auth.models import User
 from django.contrib.auth.management import get_default_username
 from django.core import exceptions
 from django.core.management.base import BaseCommand, CommandError
+from django.db import DEFAULT_DB_ALIAS
 from django.utils.translation import ugettext as _
 
 RE_VALID_USERNAME = re.compile('[\w.@+-]+$')
@@ -19,10 +21,12 @@
 
r'|^"([\001-\010\013\014\016-\037!#-\[\]-\177]|\\[\001-\011\013\014\016-\177])*"'
 # quoted-string
 r')@(?:[A-Z0-9-]+\.)+[A-Z]{2,6}$', re.IGNORECASE)  # domain
 
+
 def is_valid_email(value):
 if not EMAIL_RE.search(value):
 raise exceptions.ValidationError(_('Enter a valid e-mail address.'))
 
+
 class Command(BaseCommand):
 option_list = BaseCommand.option_list + (
 make_option('--username', dest='username', default=None,
@@ -34,6 +38,9 @@
   'You must use --username and --email with --noinput, and '
   'superusers created with --noinput will not be able to log '
   'in until they\'re given a valid password.')),
+make_option('--database', action='store', dest='database',
+default=DEFAULT_DB_ALIAS, help='Nominates a database to save the 
user to. '
+'Defaults to the "default" database.'),
 )
 help = 'Used to create a superuser.'
 
@@ -42,6 +49,7 @@
 email = options.get('email', None)
 interactive = options.get('interactive')
 verbosity = int(options.get('verbosity', 1))
+database = options.get('database')
 
 # Do quick and dirty validation if --noinput
 if not interactive:
@@ -77,7 +85,7 @@
 username = None
 continue
 try:
-User.objects.get(username=username)
+User.objects.using(database).get(username=username)
 except User.DoesNotExist:
 break
 else:
@@ -114,7 +122,7 @@
 sys.stderr.write("\nOperation cancelled.\n")
 sys.exit(1)
 
-User.objec

Re: [Django] #17327: contrib.auth management commands ignores --database option

[Django]

#17327: contrib.auth management commands ignores --database option
-+-
 Reporter:  skam |Owner:
|  brianriley
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  django db models | Triage Stage:  Ready for
  createsuperuser management |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by SmileyChris):

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


Comment:

 In [17665]:
 {{{
 #!CommitTicketReference repository="" revision="17665"
 Fixes #17327 -- Add --database option to createsuperuser and change
 password management commands
 }}}

-- 
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] #17831: Admin's date list filter's "This month/year" and "Today" are incorrect when USE_TZ is set (with the postgres backend).

[Django]

#17831: Admin's date list filter's "This month/year" and "Today" are incorrect 
when
USE_TZ is set (with the postgres backend).
+
 Reporter:  Glenn Washburn   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  contrib.admin   |Version:  1.4-beta-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 This may be applicable to other backends, but I'm not sure.

 When using USE_TZ the backend connection is set to use UTC.  So
 __year/__month/__day lookup filters will filter where the UTC timestamp
 has a year/month/day of the lookup value.  However, what's really desired
 is to use the timestamp at the current timezone.  For example, the current
 code when filtering for "today" datetimes which are not in UTC can
 potentially return a list of matching records where the set of days being
 displayed is more than one.

-- 
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] #17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when USE_TZ is set.

[Django]

#17830: DateFieldListFilter "Past 7 days" filter uses naive datetime when 
USE_TZ is
set.
+
 Reporter:  Glenn Washburn   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  contrib.admin   |Version:  1.4-beta-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 The "Past 7 days" link for the DateFieldListFilter always contains a
 serialized naive datetime.  This becomes a problem when USE_TZ is set
 because that value with get parsed back into a naive datetime and used
 directly in a QuerySet.filter call.  The warning about using a naive data
 time will be raised.

-- 
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] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 In [17664]:
 {{{
 #!CommitTicketReference repository="" revision="17664"
 Fixed #16128 - Correctly cascade-delete proxy models as if they were the
 concrete model class. Thanks xkennyx for the report, and Aymeric Augustin,
 Claude Paroz, Adam Nelson, jaap3, and Anssi Kääriäinen for work on the
 patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] r17664 - in django/trunk: django/db/models tests/regressiontests/delete_regress

[noreply]

Author: carljm
Date: 2012-03-04 19:41:01 -0800 (Sun, 04 Mar 2012)
New Revision: 17664

Modified:
   django/trunk/django/db/models/deletion.py
   django/trunk/django/db/models/options.py
   django/trunk/tests/regressiontests/delete_regress/models.py
   django/trunk/tests/regressiontests/delete_regress/tests.py
Log:
Fixed #16128 - Correctly cascade-delete proxy models as if they were the 
concrete model class. Thanks xkennyx for the report, and Aymeric Augustin, 
Claude Paroz, Adam Nelson, jaap3, and Anssi 
K?\195?\164?\195?\164ri?\195?\164inen for work on the patch.

Modified: django/trunk/django/db/models/deletion.py
===
--- django/trunk/django/db/models/deletion.py   2012-03-05 03:25:27 UTC (rev 
17663)
+++ django/trunk/django/db/models/deletion.py   2012-03-05 03:41:01 UTC (rev 
17664)
@@ -144,6 +144,7 @@
 reverse_dependency=reverse_dependency)
 if not new_objs:
 return
+
 model = new_objs[0].__class__
 
 # Recursively collect parent models, but not their related objects.
@@ -157,7 +158,8 @@
  reverse_dependency=True)
 
 if collect_related:
-for related in 
model._meta.get_all_related_objects(include_hidden=True):
+for related in model._meta.get_all_related_objects(
+include_hidden=True, include_proxy_eq=True):
 field = related.field
 if related.model._meta.auto_created:
 self.add_batch(related.model, field, new_objs)

Modified: django/trunk/django/db/models/options.py
===
--- django/trunk/django/db/models/options.py2012-03-05 03:25:27 UTC (rev 
17663)
+++ django/trunk/django/db/models/options.py2012-03-05 03:41:01 UTC (rev 
17664)
@@ -359,12 +359,15 @@
 def get_delete_permission(self):
 return 'delete_%s' % self.object_name.lower()
 
-def get_all_related_objects(self, local_only=False, include_hidden=False):
+def get_all_related_objects(self, local_only=False, include_hidden=False,
+include_proxy_eq=False):
 return [k for k, v in self.get_all_related_objects_with_model(
-local_only=local_only, include_hidden=include_hidden)]
+local_only=local_only, include_hidden=include_hidden,
+include_proxy_eq=include_proxy_eq)]
 
 def get_all_related_objects_with_model(self, local_only=False,
-   include_hidden=False):
+   include_hidden=False,
+   include_proxy_eq=False):
 """
 Returns a list of (related-object, model) pairs. Similar to
 get_fields_with_model().
@@ -378,8 +381,9 @@
 predicates.append(lambda k, v: not v)
 if not include_hidden:
 predicates.append(lambda k, v: not k.field.rel.is_hidden())
-return filter(lambda t: all([p(*t) for p in predicates]),
-  self._related_objects_cache.items())
+cache = (self._related_objects_proxy_cache if include_proxy_eq
+ else self._related_objects_cache)
+return filter(lambda t: all([p(*t) for p in predicates]), 
cache.items())
 
 def _fill_related_objects_cache(self):
 cache = SortedDict()
@@ -392,11 +396,18 @@
 cache[obj] = parent
 else:
 cache[obj] = model
+# Collect also objects which are in relation to some proxy 
child/parent of self.
+proxy_cache = cache.copy()
 for klass in get_models(include_auto_created=True, 
only_installed=False):
 for f in klass._meta.local_fields:
-if f.rel and not isinstance(f.rel.to, basestring) and self == 
f.rel.to._meta:
-cache[RelatedObject(f.rel.to, klass, f)] = None
+if f.rel and not isinstance(f.rel.to, basestring):
+if self == f.rel.to._meta:
+cache[RelatedObject(f.rel.to, klass, f)] = None
+proxy_cache[RelatedObject(f.rel.to, klass, f)] = None
+elif self.concrete_model == f.rel.to._meta.concrete_model:
+proxy_cache[RelatedObject(f.rel.to, klass, f)] = None
 self._related_objects_cache = cache
+self._related_objects_proxy_cache = proxy_cache
 
 def get_all_related_many_to_many_objects(self, local_only=False):
 try:

Modified: django/trunk/tests/regressiontests/delete_regress/models.py
===
--- django/trunk/tests/regressiontests/delete_regress/models.py 2012-03-05 
03:25:27 UTC (rev 17663)
+++ django/trunk/tests/regressiontests/delete_regress/models.py 2012-03-05 
03:41:01 UTC (rev 17664)
@@ -67,3 +67,27 @@
 clas

Re: [Django] #16335: Cannot iterate defaultdict in template

[Django]

#16335: Cannot iterate defaultdict in template
-+-
 Reporter:  jacob.ninja.dev@…|Owner:
 Type:  Bug  |  bluejeansummer
Component:  Documentation|   Status:  assigned
 Severity:  Normal   |  Version:  1.3
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  1|  Needs documentation:  0
 |  Patch needs improvement:  1
 |UI/UX:  0
-+-

Comment (by SmileyChris):

 Hrm, I wonder if the `_resolve_lookup` method could be made smarter with
 something like the following for the dictionary lookup section:
 {{{
 try:
 if bit not in current:
 raise KeyError
 except TypeError:
 pass
 current = current[bit]
 }}}

-- 
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] r17663 - in django/trunk/docs: howto ref/templates

[noreply]

Author: SmileyChris
Date: 2012-03-04 19:25:27 -0800 (Sun, 04 Mar 2012)
New Revision: 17663

Modified:
   django/trunk/docs/howto/custom-template-tags.txt
   django/trunk/docs/ref/templates/builtins.txt
Log:
Fixed #16939 -- Inaccurate implementation of {% comment %} presented in custom 
template tag 'howto' guide. Thanks sebastian for the patch.

Modified: django/trunk/docs/howto/custom-template-tags.txt
===
--- django/trunk/docs/howto/custom-template-tags.txt2012-03-05 02:24:23 UTC 
(rev 17662)
+++ django/trunk/docs/howto/custom-template-tags.txt2012-03-05 03:25:27 UTC 
(rev 17663)
@@ -1155,7 +1155,7 @@
 To create a template tag such as this, use ``parser.parse()`` in your
 compilation function.
 
-Here's how the standard :ttag:`{% comment %}` tag is implemented:
+Here's how a simplified ``{% comment %}`` tag might be implemented:
 
 .. code-block:: python
 
@@ -1168,6 +1168,14 @@
 def render(self, context):
 return ''
 
+.. note::
+The actual implementation of :ttag:`{% comment %}` is slightly
+different in that it allows broken template tags to appear between
+``{% comment %}`` and ``{% endcomment %}``. It does so by calling
+``parser.skip_past('endcomment')`` instead of 
``parser.parse(('endcomment',))``
+followed by ``parser.delete_first_token()``, thus avoiding the generation 
of a
+node list.
+
 ``parser.parse()`` takes a tuple of names of block tags ''to parse until''. It
 returns an instance of ``django.template.NodeList``, which is a list of
 all ``Node`` objects that the parser encountered ''before'' it encountered

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2012-03-05 02:24:23 UTC 
(rev 17662)
+++ django/trunk/docs/ref/templates/builtins.txt2012-03-05 03:25:27 UTC 
(rev 17663)
@@ -51,7 +51,7 @@
 comment
 ^^^
 
-Ignores everything between ``{% comment %}`` and ``{% endcomment %}``
+Ignores everything between ``{% comment %}`` and ``{% endcomment %}``.
 
 .. templatetag:: csrf_token
 

-- 
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] #16939: Inaccurate implementation of {% comment %} presented in custom template tag 'howto' guide

[Django]

#16939: Inaccurate implementation of {% comment %} presented in custom template 
tag
'howto' guide
-+-
 Reporter:  julien   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by SmileyChris):

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


Comment:

 In [17663]:
 {{{
 #!CommitTicketReference repository="" revision="17663"
 Fixed #16939 -- Inaccurate implementation of {% comment %} presented in
 custom template tag 'howto' guide. Thanks sebastian for the patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 Transifex will automatically pick up those English base translation files.
 Once we're close to do the final 1.4 release we need to just pull the
 updates from Transifex.

-- 
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] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 In [17662]:
 {{{
 #!CommitTicketReference repository="" revision="17662"
 Updated localflavor base translation files with new strings. Refs #17822.
 }}}

-- 
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] r17662 - django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES

[noreply]

Author: jezdez
Date: 2012-03-04 18:24:23 -0800 (Sun, 04 Mar 2012)
New Revision: 17662

Modified:
   django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES/django.mo
   django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES/django.po
Log:
Updated localflavor base translation files with new strings. Refs #17822.

Modified: 
django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES/django.mo
===
--- django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES/django.mo 
2012-03-05 02:24:14 UTC (rev 17661)
+++ django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES/django.mo 
2012-03-05 02:24:23 UTC (rev 17662)
@@ -1,9 +1,10 @@
-Þ  •$   ,   8   9Project-Id-Version: 
Django
+Þ  •$   ,   8   *   9Project-Id-Version: 
Django
 Report-Msgid-Bugs-To: 
-POT-Creation-Date: 2011-06-28 12:44+0200
+POT-Creation-Date: 2012-03-05 02:25+0100
 PO-Revision-Date: 2010-05-13 15:35+0200
 Last-Translator: Django team
 Language-Team: English 
+Language: en
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

Modified: 
django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES/django.po 
2012-03-05 02:24:14 UTC (rev 17661)
+++ django/trunk/django/contrib/localflavor/locale/en/LC_MESSAGES/django.po 
2012-03-05 02:24:23 UTC (rev 17662)
@@ -4,7 +4,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-12-22 23:56+0100\n"
+"POT-Creation-Date: 2012-03-05 02:25+0100\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
@@ -2474,7 +2474,8 @@
 
 #: pl/forms.py:131
 msgid ""
-"Enter a tax number field (NIP) in the format XXX-XXX-XX-XX or XX-XX-XXX-XXX."
+"Enter a tax number field (NIP) in the format XXX-XXX-XX-XX, XXX-XX-XX-XXX or "
+"XX."
 msgstr ""
 
 #: pl/forms.py:132

-- 
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] r17661 - django/trunk/django/contrib/gis/locale/en/LC_MESSAGES

[noreply]

Author: jezdez
Date: 2012-03-04 18:24:14 -0800 (Sun, 04 Mar 2012)
New Revision: 17661

Modified:
   django/trunk/django/contrib/gis/locale/en/LC_MESSAGES/django.mo
   django/trunk/django/contrib/gis/locale/en/LC_MESSAGES/django.po
Log:
Updated gis base translation files with new strings. Refs #17822.

Modified: django/trunk/django/contrib/gis/locale/en/LC_MESSAGES/django.mo
===
--- django/trunk/django/contrib/gis/locale/en/LC_MESSAGES/django.mo 
2012-03-05 02:24:06 UTC (rev 17660)
+++ django/trunk/django/contrib/gis/locale/en/LC_MESSAGES/django.mo 
2012-03-05 02:24:14 UTC (rev 17661)
@@ -1,9 +1,10 @@
-Þ  •$   ,   8   9Project-Id-Version: 
Django
+Þ  •$   ,   8   *   9Project-Id-Version: 
Django
 Report-Msgid-Bugs-To: 
-POT-Creation-Date: 2011-03-15 13:16-0400
+POT-Creation-Date: 2012-03-05 02:25+0100
 PO-Revision-Date: 2010-05-13 15:35+0200
 Last-Translator: Django team
 Language-Team: English 
+Language: en
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

Modified: django/trunk/django/contrib/gis/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/contrib/gis/locale/en/LC_MESSAGES/django.po 
2012-03-05 02:24:06 UTC (rev 17660)
+++ django/trunk/django/contrib/gis/locale/en/LC_MESSAGES/django.po 
2012-03-05 02:24:14 UTC (rev 17661)
@@ -4,7 +4,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-12-22 23:56+0100\n"
+"POT-Creation-Date: 2012-03-05 02:25+0100\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
@@ -13,6 +13,15 @@
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 
+#: views.py:7
+msgid "No feeds are registered."
+msgstr ""
+
+#: views.py:17
+#, python-format
+msgid "Slug %r isn't registered."
+msgstr ""
+
 #: db/models/fields.py:50
 msgid "The base GIS field -- maps to the OpenGIS Specification Geometry type."
 msgstr ""
@@ -62,3 +71,18 @@
 "An error occurred when transforming the geometry to the SRID of the geometry "
 "form field."
 msgstr ""
+
+#: sitemaps/views.py:44
+#, python-format
+msgid "No sitemap available for section: %r"
+msgstr ""
+
+#: sitemaps/views.py:58
+#, python-format
+msgid "Page %s empty"
+msgstr ""
+
+#: sitemaps/views.py:60
+#, python-format
+msgid "No page '%s'"
+msgstr ""

-- 
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] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 In [17661]:
 {{{
 #!CommitTicketReference repository="" revision="17661"
 Updated gis base translation files with new strings. Refs #17822.
 }}}

-- 
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] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 In [17660]:
 {{{
 #!CommitTicketReference repository="" revision="17660"
 Updated flatpages base translation files with new strings. Refs #17822.
 }}}

-- 
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] r17660 - django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES

[noreply]

Author: jezdez
Date: 2012-03-04 18:24:06 -0800 (Sun, 04 Mar 2012)
New Revision: 17660

Modified:
   django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES/django.mo
   django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES/django.po
Log:
Updated flatpages base translation files with new strings. Refs #17822.

Modified: django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES/django.mo
===
--- django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES/django.mo   
2012-03-05 02:23:57 UTC (rev 17659)
+++ django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES/django.mo   
2012-03-05 02:24:06 UTC (rev 17660)
@@ -1,9 +1,10 @@
-Þ  •$   ,   8   9Project-Id-Version: 
Django
+Þ  •$   ,   8   *   9Project-Id-Version: 
Django
 Report-Msgid-Bugs-To: 
-POT-Creation-Date: 2011-03-15 13:15-0400
+POT-Creation-Date: 2012-03-05 02:25+0100
 PO-Revision-Date: 2010-05-13 15:35+0200
 Last-Translator: Django team
 Language-Team: English 
+Language: en
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

Modified: django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES/django.po   
2012-03-05 02:23:57 UTC (rev 17659)
+++ django/trunk/django/contrib/flatpages/locale/en/LC_MESSAGES/django.po   
2012-03-05 02:24:06 UTC (rev 17660)
@@ -4,7 +4,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-12-22 23:56+0100\n"
+"POT-Creation-Date: 2012-03-05 02:25+0100\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
@@ -17,22 +17,30 @@
 msgid "Advanced options"
 msgstr ""
 
-#: forms.py:6 models.py:7
+#: forms.py:7 models.py:7
 msgid "URL"
 msgstr ""
 
-#: forms.py:7
+#: forms.py:8
 msgid ""
 "Example: '/about/contact/'. Make sure to have leading and trailing slashes."
 msgstr ""
 
-#: forms.py:9
+#: forms.py:10
 msgid ""
 "This value must contain only letters, numbers, dots, underscores, dashes, "
 "slashes or tildes."
 msgstr ""
 
-#: forms.py:27
+#: forms.py:19
+msgid "URL is missing a leading slash."
+msgstr ""
+
+#: forms.py:23
+msgid "URL is missing a trailing slash."
+msgstr ""
+
+#: forms.py:38
 #, python-format
 msgid "Flatpage with url %(url)s already exists for site %(site)s"
 msgstr ""

-- 
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] r17659 - django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES

[noreply]

Author: jezdez
Date: 2012-03-04 18:23:57 -0800 (Sun, 04 Mar 2012)
New Revision: 17659

Modified:
   django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES/django.mo
   django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES/django.po
Log:
Updated contenttypes base translation files with new strings. Refs #17822.

Modified: 
django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES/django.mo
===
--- django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES/django.mo
2012-03-05 02:23:49 UTC (rev 17658)
+++ django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES/django.mo
2012-03-05 02:23:57 UTC (rev 17659)
@@ -1,9 +1,10 @@
-Þ  •$   ,   8   9Project-Id-Version: 
Django
+Þ  •$   ,   8   *   9Project-Id-Version: 
Django
 Report-Msgid-Bugs-To: 
-POT-Creation-Date: 2011-03-15 13:15-0400
+POT-Creation-Date: 2012-03-05 02:25+0100
 PO-Revision-Date: 2010-05-13 15:35+0200
 Last-Translator: Django team
 Language-Team: English 
+Language: en
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

Modified: 
django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES/django.po
2012-03-05 02:23:49 UTC (rev 17658)
+++ django/trunk/django/contrib/contenttypes/locale/en/LC_MESSAGES/django.po
2012-03-05 02:23:57 UTC (rev 17659)
@@ -4,7 +4,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-12-22 23:56+0100\n"
+"POT-Creation-Date: 2012-03-05 02:25+0100\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
@@ -13,14 +13,29 @@
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 
-#: models.py:126
+#: models.py:123
 msgid "python model class name"
 msgstr ""
 
-#: models.py:130
+#: models.py:127
 msgid "content type"
 msgstr ""
 
-#: models.py:131
+#: models.py:128
 msgid "content types"
 msgstr ""
+
+#: views.py:15
+#, python-format
+msgid "Content type %(ct_id)s object has no associated model"
+msgstr ""
+
+#: views.py:19
+#, python-format
+msgid "Content type %(ct_id)s object %(obj_id)s doesn't exist"
+msgstr ""
+
+#: views.py:25
+#, python-format
+msgid "%(ct_name)s objects don't have a get_absolute_url() method"
+msgstr ""

-- 
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] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 In [17659]:
 {{{
 #!CommitTicketReference repository="" revision="17659"
 Updated contenttypes base translation files with new strings. Refs #17822.
 }}}

-- 
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] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 In [17658]:
 {{{
 #!CommitTicketReference repository="" revision="17658"
 Updated comments base translation files with new strings. Refs #17822.
 }}}

-- 
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] r17658 - django/trunk/django/contrib/comments/locale/en/LC_MESSAGES

[noreply]

Author: jezdez
Date: 2012-03-04 18:23:49 -0800 (Sun, 04 Mar 2012)
New Revision: 17658

Modified:
   django/trunk/django/contrib/comments/locale/en/LC_MESSAGES/django.mo
   django/trunk/django/contrib/comments/locale/en/LC_MESSAGES/django.po
Log:
Updated comments base translation files with new strings. Refs #17822.

Modified: django/trunk/django/contrib/comments/locale/en/LC_MESSAGES/django.mo
===
--- django/trunk/django/contrib/comments/locale/en/LC_MESSAGES/django.mo
2012-03-05 02:23:40 UTC (rev 17657)
+++ django/trunk/django/contrib/comments/locale/en/LC_MESSAGES/django.mo
2012-03-05 02:23:49 UTC (rev 17658)
@@ -1,9 +1,10 @@
-Þ  •$   ,   8   9Project-Id-Version: 
Django
+Þ  •$   ,   8   *   9Project-Id-Version: 
Django
 Report-Msgid-Bugs-To: 
-POT-Creation-Date: 2011-03-15 13:14-0400
+POT-Creation-Date: 2012-03-05 02:25+0100
 PO-Revision-Date: 2010-05-13 15:35+0200
 Last-Translator: Django team
 Language-Team: English 
+Language: en
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

Modified: django/trunk/django/contrib/comments/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/contrib/comments/locale/en/LC_MESSAGES/django.po
2012-03-05 02:23:40 UTC (rev 17657)
+++ django/trunk/django/contrib/comments/locale/en/LC_MESSAGES/django.po
2012-03-05 02:23:49 UTC (rev 17658)
@@ -4,7 +4,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-12-22 23:56+0100\n"
+"POT-Creation-Date: 2012-03-05 02:25+0100\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
@@ -91,7 +91,11 @@
 msgstr[0] ""
 msgstr[1] ""
 
-#: forms.py:184
+#: forms.py:181 templates/comments/preview.html:16
+msgid "and"
+msgstr ""
+
+#: forms.py:186
 msgid ""
 "If you enter anything in this field your comment will be treated as spam"
 msgstr ""
@@ -274,10 +278,6 @@
 msgstr[1] ""
 
 #: templates/comments/preview.html:16
-msgid "and"
-msgstr ""
-
-#: templates/comments/preview.html:16
 msgid "Post your comment"
 msgstr ""
 

-- 
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] r17657 - django/trunk/django/contrib/auth/locale/en/LC_MESSAGES

[noreply]

Author: jezdez
Date: 2012-03-04 18:23:40 -0800 (Sun, 04 Mar 2012)
New Revision: 17657

Modified:
   django/trunk/django/contrib/auth/locale/en/LC_MESSAGES/django.mo
   django/trunk/django/contrib/auth/locale/en/LC_MESSAGES/django.po
Log:
Updated auth base translation files with new strings. Refs #17822.

Modified: django/trunk/django/contrib/auth/locale/en/LC_MESSAGES/django.mo
===
--- django/trunk/django/contrib/auth/locale/en/LC_MESSAGES/django.mo
2012-03-05 02:23:31 UTC (rev 17656)
+++ django/trunk/django/contrib/auth/locale/en/LC_MESSAGES/django.mo
2012-03-05 02:23:40 UTC (rev 17657)
@@ -1,9 +1,10 @@
-Þ  •$   ,   8   9Project-Id-Version: 
Django
+Þ  •$   ,   8   *   9Project-Id-Version: 
Django
 Report-Msgid-Bugs-To: 
-POT-Creation-Date: 2011-03-15 13:14-0400
+POT-Creation-Date: 2012-03-05 02:25+0100
 PO-Revision-Date: 2010-05-13 15:35+0200
 Last-Translator: Django team
 Language-Team: English 
+Language: en
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

Modified: django/trunk/django/contrib/auth/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/contrib/auth/locale/en/LC_MESSAGES/django.po
2012-03-05 02:23:31 UTC (rev 17656)
+++ django/trunk/django/contrib/auth/locale/en/LC_MESSAGES/django.po
2012-03-05 02:23:40 UTC (rev 17657)
@@ -4,7 +4,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-12-22 23:56+0100\n"
+"POT-Creation-Date: 2012-03-05 02:25+0100\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
@@ -13,229 +13,243 @@
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 
-#: admin.py:38
+#: admin.py:41
 msgid "Personal info"
 msgstr ""
 
-#: admin.py:39
+#: admin.py:42
 msgid "Permissions"
 msgstr ""
 
-#: admin.py:40
+#: admin.py:44
 msgid "Important dates"
 msgstr ""
 
-#: admin.py:41
-msgid "Groups"
-msgstr ""
-
-#: admin.py:116
+#: admin.py:125
 msgid "Password changed successfully."
 msgstr ""
 
-#: admin.py:126
+#: admin.py:135
 #, python-format
 msgid "Change password: %s"
 msgstr ""
 
-#: forms.py:37
-msgid "Hash type"
-msgstr ""
-
-#: forms.py:39
-msgid "Masked hash"
-msgstr ""
-
-#: forms.py:57
+#: forms.py:58
 msgid "A user with that username already exists."
 msgstr ""
 
-#: forms.py:58 forms.py:229 forms.py:279
+#: forms.py:59 forms.py:247 forms.py:304
 msgid "The two password fields didn't match."
 msgstr ""
 
-#: forms.py:60 forms.py:97 forms.py:120
+#: forms.py:61 forms.py:106 forms.py:135
 msgid "Username"
 msgstr ""
 
-#: forms.py:61 forms.py:98
+#: forms.py:63 forms.py:107
 msgid "Required. 30 characters or fewer. Letters, digits and @/./+/-/_ only."
 msgstr ""
 
-#: forms.py:62 forms.py:99
+#: forms.py:66 forms.py:110
 msgid "This value may contain only letters, numbers and @/./+/-/_ characters."
 msgstr ""
 
-#: forms.py:63 forms.py:100 forms.py:121 forms.py:281
+#: forms.py:68 forms.py:112 forms.py:136 forms.py:306
 msgid "Password"
 msgstr ""
 
-#: forms.py:64
+#: forms.py:70
 msgid "Password confirmation"
 msgstr ""
 
-#: forms.py:65
+#: forms.py:72
 msgid "Enter the same password as above, for verification."
 msgstr ""
 
-#: forms.py:100
+#: forms.py:113
 msgid ""
-"We don't store raw passwords, so there's no way to see this user's password, "
-"but you can change the password using this form."
+"Raw passwords are not stored, so there is no way to see this user's "
+"password, but you can change the password using this "
+"form."
 msgstr ""
 
-#: forms.py:124
+#: forms.py:139
 msgid ""
 "Please enter a correct username and password. Note that both fields are case-"
 "sensitive."
 msgstr ""
 
-#: forms.py:126
+#: forms.py:141
 msgid ""
 "Your Web browser doesn't appear to have cookies enabled. Cookies are "
 "required for logging in."
 msgstr ""
 
-#: forms.py:128
+#: forms.py:143
 msgid "This account is inactive."
 msgstr ""
 
-#: forms.py:170
+#: forms.py:187
 msgid ""
 "That e-mail address doesn't have an associated user account. Are you sure "
 "you've registered?"
 msgstr ""
 
-#: forms.py:172
+#: forms.py:189
 msgid ""
 "The user account associated with this e-mail address cannot reset the "
 "password."
 msgstr ""
 
-#: forms.py:175
+#: forms.py:192
 msgid "E-mail"
 msgstr ""
 
-#: forms.py:231
+#: forms.py:249
 msgid "New password"
 msgstr ""
 
-#: forms.py:232
+#: forms.py:251
 msgid "New password confirmation"
 msgstr ""
 
-#: forms.py:259
+#: forms.py:280
 msgid "Your old password was entered incorrectly. Please enter it again."
 msgstr ""
 
-#: forms.py:261
+#: forms.py:283
 msgid "Old password"
 msgstr ""
 
-#: forms.py:282
+#: forms.py:308
 msgid "Password (again)"
 msgstr ""
 
-#: models.py:51 models.py:79
+#: hashers.py:218 hashers.py:269 hashers.py

Re: [Django] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 In [17657]:
 {{{
 #!CommitTicketReference repository="" revision="17657"
 Updated auth base translation files with new strings. Refs #17822.
 }}}

-- 
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] r17656 - django/trunk/django/contrib/admin/locale/en/LC_MESSAGES

[noreply]

Author: jezdez
Date: 2012-03-04 18:23:31 -0800 (Sun, 04 Mar 2012)
New Revision: 17656

Modified:
   django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/django.mo
   django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/django.po
   django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/djangojs.mo
   django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/djangojs.po
Log:
Updated admin base translation files with new strings. Refs #17822.

Modified: django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/django.mo
===
--- django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/django.mo   
2012-03-05 02:23:17 UTC (rev 17655)
+++ django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/django.mo   
2012-03-05 02:23:31 UTC (rev 17656)
@@ -1,9 +1,10 @@
-Þ  •$   ,   8   9Project-Id-Version: 
Django
+Þ  •$   ,   8   *   9Project-Id-Version: 
Django
 Report-Msgid-Bugs-To: 
-POT-Creation-Date: 2011-03-20 21:03+0100
+POT-Creation-Date: 2012-03-05 02:24+0100
 PO-Revision-Date: 2010-05-13 15:35+0200
 Last-Translator: Django team
 Language-Team: English 
+Language: en
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

Modified: django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/django.po   
2012-03-05 02:23:17 UTC (rev 17655)
+++ django/trunk/django/contrib/admin/locale/en/LC_MESSAGES/django.po   
2012-03-05 02:23:31 UTC (rev 17656)
@@ -4,7 +4,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-12-22 23:56+0100\n"
+"POT-Creation-Date: 2012-03-05 02:24+0100\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
@@ -18,12 +18,12 @@
 msgid "Successfully deleted %(count)d %(items)s."
 msgstr ""
 
-#: actions.py:60 options.py:1295
+#: actions.py:60 options.py:1297
 #, python-format
 msgid "Cannot delete %(name)s"
 msgstr ""
 
-#: actions.py:62 options.py:1297
+#: actions.py:62 options.py:1299
 msgid "Are you sure?"
 msgstr ""
 
@@ -32,39 +32,39 @@
 msgid "Delete selected %(verbose_name_plural)s"
 msgstr ""
 
-#: filters.py:99 filters.py:189 filters.py:229 filters.py:266 filters.py:371
+#: filters.py:100 filters.py:190 filters.py:230 filters.py:267 filters.py:372
 msgid "All"
 msgstr ""
 
-#: filters.py:230
+#: filters.py:231
 msgid "Yes"
 msgstr ""
 
-#: filters.py:231
+#: filters.py:232
 msgid "No"
 msgstr ""
 
-#: filters.py:245
+#: filters.py:246
 msgid "Unknown"
 msgstr ""
 
-#: filters.py:295
+#: filters.py:296
 msgid "Any date"
 msgstr ""
 
-#: filters.py:296
+#: filters.py:297
 msgid "Today"
 msgstr ""
 
-#: filters.py:301
+#: filters.py:302
 msgid "Past 7 days"
 msgstr ""
 
-#: filters.py:305
+#: filters.py:306
 msgid "This month"
 msgstr ""
 
-#: filters.py:309
+#: filters.py:310
 msgid "This year"
 msgstr ""
 
@@ -83,7 +83,7 @@
 msgid "Your e-mail address is not your username. Try '%s' instead."
 msgstr ""
 
-#: helpers.py:19
+#: helpers.py:20
 msgid "Action:"
 msgstr ""
 
@@ -134,132 +134,132 @@
 msgid "LogEntry Object"
 msgstr ""
 
-#: options.py:149 options.py:165
+#: options.py:150 options.py:166
 msgid "None"
 msgstr ""
 
-#: options.py:671
+#: options.py:673
 #, python-format
 msgid "Changed %s."
 msgstr ""
 
-#: options.py:671 options.py:681
+#: options.py:673 options.py:683
 msgid "and"
 msgstr ""
 
-#: options.py:676
+#: options.py:678
 #, python-format
 msgid "Added %(name)s \"%(object)s\"."
 msgstr ""
 
-#: options.py:680
+#: options.py:682
 #, python-format
 msgid "Changed %(list)s for %(name)s \"%(object)s\"."
 msgstr ""
 
-#: options.py:685
+#: options.py:687
 #, python-format
 msgid "Deleted %(name)s \"%(object)s\"."
 msgstr ""
 
-#: options.py:689
+#: options.py:691
 msgid "No fields changed."
 msgstr ""
 
-#: options.py:772
+#: options.py:774
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was added successfully."
 msgstr ""
 
-#: options.py:776 options.py:824
+#: options.py:778 options.py:826
 msgid "You may edit it again below."
 msgstr ""
 
-#: options.py:788 options.py:837
+#: options.py:790 options.py:839
 #, python-format
 msgid "You may add another %s below."
 msgstr ""
 
-#: options.py:822
+#: options.py:824
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was changed successfully."
 msgstr ""
 
-#: options.py:830
+#: options.py:832
 #, python-format
 msgid ""
 "The %(name)s \"%(obj)s\" was added successfully. You may edit it again below."
 msgstr ""
 
-#: options.py:899 options.py:1159
+#: options.py:901 options.py:1161
 msgid ""
 "Items must be selected in order to perform actions on them. No items have "
 "been changed."
 msgstr ""
 
-#: options.py:918
+#: options.py:920
 msgid "No action selected."
 msgstr ""
 
-#: options.py:998
+#: options.py:1000

Re: [Django] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 In [17656]:
 {{{
 #!CommitTicketReference repository="" revision="17656"
 Updated admin base translation files with new strings. Refs #17822.
 }}}

-- 
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] #17822: Update base translations and push to Transifex

[Django]

#17822: Update base translations and push to Transifex
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |  1.4-beta-1
 Severity:  Release blocker  |   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 jezdez):

 In [17655]:
 {{{
 #!CommitTicketReference repository="" revision="17655"
 Updated core base translation files with new strings. Refs #17822.
 }}}

-- 
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] r17655 - in django/trunk/django: conf/locale/en/LC_MESSAGES views

[noreply]

Author: jezdez
Date: 2012-03-04 18:23:17 -0800 (Sun, 04 Mar 2012)
New Revision: 17655

Modified:
   django/trunk/django/conf/locale/en/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/en/LC_MESSAGES/django.po
   django/trunk/django/views/static.py
Log:
Updated core base translation files with new strings. Refs #17822.

Modified: django/trunk/django/conf/locale/en/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: django/trunk/django/conf/locale/en/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/en/LC_MESSAGES/django.po2012-03-04 
20:32:12 UTC (rev 17654)
+++ django/trunk/django/conf/locale/en/LC_MESSAGES/django.po2012-03-05 
02:23:17 UTC (rev 17655)
@@ -4,7 +4,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-12-22 23:56+0100\n"
+"POT-Creation-Date: 2012-03-05 02:24+0100\n"
 "PO-Revision-Date: 2010-05-13 15:35+0200\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
@@ -289,70 +289,70 @@
 msgid "Enter a valid URL."
 msgstr ""
 
-#: core/validators.py:164 forms/fields.py:474
+#: core/validators.py:165 forms/fields.py:474
 msgid "Enter a valid e-mail address."
 msgstr ""
 
-#: core/validators.py:167 forms/fields.py:1022
+#: core/validators.py:168 forms/fields.py:1023
 msgid ""
 "Enter a valid 'slug' consisting of letters, numbers, underscores or hyphens."
 msgstr ""
 
-#: core/validators.py:170 core/validators.py:187 forms/fields.py:996
+#: core/validators.py:171 core/validators.py:188 forms/fields.py:997
 msgid "Enter a valid IPv4 address."
 msgstr ""
 
-#: core/validators.py:174 core/validators.py:188
+#: core/validators.py:175 core/validators.py:189
 msgid "Enter a valid IPv6 address."
 msgstr ""
 
-#: core/validators.py:183 core/validators.py:186
+#: core/validators.py:184 core/validators.py:187
 msgid "Enter a valid IPv4 or IPv6 address."
 msgstr ""
 
-#: core/validators.py:208 db/models/fields/__init__.py:636
+#: core/validators.py:209 db/models/fields/__init__.py:638
 msgid "Enter only digits separated by commas."
 msgstr ""
 
-#: core/validators.py:214
+#: core/validators.py:215
 #, python-format
 msgid "Ensure this value is %(limit_value)s (it is %(show_value)s)."
 msgstr ""
 
-#: core/validators.py:232 forms/fields.py:209 forms/fields.py:262
+#: core/validators.py:233 forms/fields.py:209 forms/fields.py:262
 #, python-format
 msgid "Ensure this value is less than or equal to %(limit_value)s."
 msgstr ""
 
-#: core/validators.py:237 forms/fields.py:210 forms/fields.py:263
+#: core/validators.py:238 forms/fields.py:210 forms/fields.py:263
 #, python-format
 msgid "Ensure this value is greater than or equal to %(limit_value)s."
 msgstr ""
 
-#: core/validators.py:243
+#: core/validators.py:244
 #, python-format
 msgid ""
 "Ensure this value has at least %(limit_value)d characters (it has "
 "%(show_value)d)."
 msgstr ""
 
-#: core/validators.py:249
+#: core/validators.py:250
 #, python-format
 msgid ""
 "Ensure this value has at most %(limit_value)d characters (it has "
 "%(show_value)d)."
 msgstr ""
 
-#: db/models/base.py:765
+#: db/models/base.py:770
 #, python-format
 msgid "%(field_name)s must be unique for %(date_field)s %(lookup)s."
 msgstr ""
 
-#: db/models/base.py:788 forms/models.py:570
+#: db/models/base.py:793 forms/models.py:577
 msgid "and"
 msgstr ""
 
-#: db/models/base.py:789 db/models/fields/__init__.py:65
+#: db/models/base.py:794 db/models/fields/__init__.py:65
 #, python-format
 msgid "%(model_name)s with this %(field_label)s already exists."
 msgstr ""
@@ -375,159 +375,181 @@
 msgid "Field of type: %(field_type)s"
 msgstr ""
 
-#: db/models/fields/__init__.py:506 db/models/fields/__init__.py:948
-#: db/models/fields/__init__.py:1103 db/models/fields/__init__.py:1114
-#: db/models/fields/__init__.py:1141
+#: db/models/fields/__init__.py:506 db/models/fields/__init__.py:961
 msgid "Integer"
 msgstr ""
 
-#: db/models/fields/__init__.py:510 db/models/fields/__init__.py:946
+#: db/models/fields/__init__.py:510 db/models/fields/__init__.py:959
 #, python-format
 msgid "'%s' value must be an integer."
 msgstr ""
 
-#: db/models/fields/__init__.py:551
+#: db/models/fields/__init__.py:552
 #, python-format
 msgid "'%s' value must be either True or False."
 msgstr ""
 
-#: db/models/fields/__init__.py:553
+#: db/models/fields/__init__.py:554
 msgid "Boolean (Either True or False)"
 msgstr ""
 
-#: db/models/fields/__init__.py:603 db/models/fields/__init__.py:1124
+#: db/models/fields/__init__.py:605
 #, python-format
 msgid "String (up to %(max_length)s)"
 msgstr ""
 
-#: db/models/fields/__init__.py:631
+#: db/models/fields/__init__.py:633
 msgid "Comma-separated integers"
 msgstr ""
 
-#: db/models/fields/__init__.py:645
+#: db/models/fields/__init__.py:647
 #, python-format
 msgid "'%s' value has an invalid date format. It must be in -MM-DD format."
 ms

Re: [Django] #17726: Admin's Recent Actions broken for multiple admin site instances with unique registered models

[Django]

#17726: Admin's Recent Actions broken for multiple admin site instances with 
unique
registered models
-+-
 Reporter:  smacleod |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  admin, multiple  | Triage Stage:  Accepted
  admin sites, recent actions|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

 * status:  closed => reopened
 * resolution:  duplicate =>
 * stage:  Unreviewed => Accepted


Comment:

 I don't believe this is actually a duplicate of #9151, though it is
 similar. #9151 is about `django.contrib.sites`; this ticket is about
 creating multiple instances of `django.contrib.admin.Site`. Despite the
 confusing naming, those are two completely separate things. And I don't
 think the wontfix reasoning applied in #9151 applies here; while there may
 be nothing about `django.contrib.sites.models.Site` that warrants special
 treatment in the admin, I think it's reasonable to expect that the admin's
 *own* multiple-admin-site feature won't break the admin's own recent-
 actions feature.

 Reopening.

-- 
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] #17709: Include info on DocumentRoot in Apache setup doc

[Django]

#17709: Include info on DocumentRoot in Apache setup doc
--+
 Reporter:  fastfrwrd@…   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 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 carljm):

 If this ticket really only applied to `mod_python` I'd have no trouble
 wontfixing it right now. However, I note that that
 [https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/ the
 mod_wsgi page] also includes Apache configuration samples for serving
 static assets, and that that example doesn't include `DocumentRoot`
 either, and it seems like it probably ought to.

-- 
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] #17745: Support for PostgreSQL Arrays

[Django]

#17745: Support for PostgreSQL Arrays
-+-
 Reporter:  dbrgn|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 I agree that features that only one of the supported database backends
 support are better supported by external apps when possible.

-- 
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] #17829: Admin date filter's "Past 7 days" actually returns past 8 days.

[Django]

#17829: Admin date filter's "Past 7 days" actually returns past 8 days.
+
 Reporter:  Glenn Washburn   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  contrib.admin   |Version:  1.4-beta-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Essentially the problem is analogous to
 {{{
  end = 10
  start = end - 7
  qs.filter(f__gte=start, f__lte=end) # this will allow 8 numbers not 7
 (namely: [3,4,5,6,7,8,9,10])
 }}}

 I think this is fairly obvious (and easy to fix), but I an explain more if
 needed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17828: Admin should not handle IncorrectLookupParameters if settings.DEBUG is set

[Django]

#17828: Admin should not handle IncorrectLookupParameters if settings.DEBUG is 
set
-+-
 Reporter:  Glenn Washburn   |Owner:  nobody
  |   Status:  new
 Type:  Uncategorized|  Version:
Component:  contrib.admin|  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Glenn Washburn ):

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


Comment:

 Also as an optional addon to this fix, the traceback should preserve the
 original exception's traceback.  I've implemented this by modifying the
 raise statement in **admin.views.main.ChangeList.get_query_set** to be
 **raise IncorrectLookupParameters, IncorrectLookupParameters(e),
 sys.exc_info()[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.

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:
 Type:  Bug  |  mtredinnick
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by milosu):

 * needs_better_patch:  1 => 0


Comment:

 Hi,

 being an author of the initial patch, which is already almost 2 years old,
 I have found a time to make a (hopefully final) patch for this feature.

 I'm proposing the following v5 patch that solves the failures in "queries"
 test case mentioned above (there were 4 failures in total) and passes the
 Django-1.4b1 test suite.

 Regards

 --
 Milos

-- 
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] #17375: 'makemessages' ignores plural from 'blocktrans'

[Django]

#17375: 'makemessages' ignores plural from 'blocktrans'
--+
 Reporter:  ahagenbruch   |Owner:  pigletto
 Type:  Bug   |   Status:  assigned
Component:  Internationalization  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by pigletto):

 * needs_better_patch:  1 => 0


Comment:

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

[Django] #17828: Admin should not handle IncorrectLookupParameters if settings.DEBUG is set

[Django]

#17828: Admin should not handle IncorrectLookupParameters if settings.DEBUG is 
set
+
 Reporter:  Glenn Washburn   |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  contrib.admin   |Version:  1.4-beta-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Right now its difficult to debug exceptions raised in ListFilter code
 which raises an exception because the exception will be wrapped in an
 IncorrectLookupParameters exception, then caught by
 ModelAdmin.changelist_view which renders an uninformative
 invalid_setup.html template.

 I propose adding in the except IncorrectLookupParameters block the
 following:
 {{{
 if settings.DEBUG:
 raise
 }}}
 So that the main django exception handler can render the much more
 informative exception template.  I've tested this and it seems to work
 fine.

-- 
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] #17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name attribute

[Django]

#17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name
attribute
-+-
 Reporter:  andreyfedoseev   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Design decision needed


Comment:

 I'm not sure what to do with this ticket.

 `to_field_name` is an internal API. I'd like to know if it's possible to
 trigger a bug by using only public APIs. But the patch appears to be an
 improvement.

 This needs more thought.

-- 
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] #17740: BaseModelFormSet should use its queryset when initializing the ModelForm's pk_field's ModelChoiceField.

[Django]

#17740: BaseModelFormSet should use its queryset when initializing the 
ModelForm's
pk_field's ModelChoiceField.
-+--
 Reporter:  larsent  |Owner:  larsent
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 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 aaugustin):

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


Comment:

 Let me elaborate a bit on the bug report; it's terse and it took me a
 while to figure out what's going on.

 `BaseModelFormSet.add_fields(self, form, index)` adds a field that
 contains the primary key to `form`. This field is invisible to the end
 user -- it uses a `HiddenInput` widget -- but it's necessary for Django to
 know which instance of the model `form` deals with, when it received the
 contents of `form` in the next request. Django uses a `ModelChoiceField`
 for this extra field: this makes sense for designating which instance the
 `form` applies to, among all existing instances of the model.

 "All existing instances of the model" is `qs =
 self.model._default_manager.get_query_set()`. By definition -- and unless
 I missed something -- this queryset always contains all instances of the
 model. Could you explain how it's possible for your `custom_manager` to
 contain an object that isn't in `_default_manager`?

-- 
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] #17669: Allow user specific queries as search_fields in django.contrib.admin.views.main.ChangeList

[Django]

#17669: Allow user specific queries as search_fields in
django.contrib.admin.views.main.ChangeList
-+-
 Reporter:  kunitoki@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.3-rc1
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  feature  | Triage Stage:  Accepted
  search_fields admin ChangeList |  Needs documentation:  0
  eav-django |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Like all feature requests, it will only happen if someone:
 - sends a good API proposal to django-developers
 - develops a patch (with tests and docs)
 - improves it until it's ready for checkin

 There's no activity on #15961. That means that until now, nobody was
 sufficiently interested to take ownership of the ticket. If you want to do
 it, you're very welcome!

-- 
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] #17669: Allow user specific queries as search_fields in django.contrib.admin.views.main.ChangeList

[Django]

#17669: Allow user specific queries as search_fields in
django.contrib.admin.views.main.ChangeList
-+-
 Reporter:  kunitoki@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.3-rc1
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  feature  | Triage Stage:  Accepted
  search_fields admin ChangeList |  Needs documentation:  0
  eav-django |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by kunitoki@…):

 Yes sure, i missed that... sorry.

 Btw... any plans to include something more pluggable in future versions ?

-- 
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] #15961: Admin search should be pluggable

[Django]

#15961: Admin search should be pluggable
-+-
 Reporter:  jdunck   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 #17669 was a duplicate.

-- 
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] #17669: Allow user specific queries as search_fields in django.contrib.admin.views.main.ChangeList

[Django]

#17669: Allow user specific queries as search_fields in
django.contrib.admin.views.main.ChangeList
-+-
 Reporter:  kunitoki@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.3-rc1
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  feature  | Triage Stage:  Accepted
  search_fields admin ChangeList |  Needs documentation:  0
  eav-django |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => duplicate
 * stage:  Unreviewed => Accepted


Comment:

 Unless I missed something, this feature was already requested in #15961.

-- 
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] #17697: Implement a new property as list type (like extra_argument) into the ListView class

[Django]

#17697: Implement a new property as list type (like extra_argument) into the
ListView class
-+-
 Reporter:  sylock   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Generic views|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  extra_context| Triage Stage:
  generic views listview |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 > Really need little modification to the existing code!

 Would you mind attaching the changes you suggest as a diff file? That
 would make it easier to assess this ticket.

-- 
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] #17826: Failures in Firefox+Windows 7+Admin filter tests

[Django]

#17826: Failures in Firefox+Windows 7+Admin filter tests
---+
 Reporter:  ramiro |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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 ramiro):

 Replying to [comment:1 charettes]:
 > Can you update your version and FF and see if it fixes it?

 I'm unable to do that ATM but I forgot to report these tests pass on
 Debian Linux unstable (Debian's flavors of Firefox Iceweasel 10.0.2 and of
 Chrome engine Chromium browser ''17.0.963.56 (Developer Build 121963
 Linux)'')

 Just wanted to leave a note about the failure on win32.

-- 
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] #17716: include(arg, namespace=None, app_name=None) replace app_name with namespace

[Django]

#17716: include(arg, namespace=None, app_name=None) replace app_name with 
namespace
-+-
 Reporter:  blackip@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:
 Severity:  Normal   |  1.4-alpha-1
 Keywords:  include reverse url  |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Reading the [https://docs.djangoproject.com/en/dev/topics/http/urls
 /#defining-url-namespaces URL namespaces docs], it appears that it's
 invalid to write an include with `app_name` but without `namespace`.

 Django could check that `app_name` and `namespace` are either both `None`,
 or both `not None`, in `django.conf.urls.url`, making this error is easier
 to debug. Accepting on this basis.

-- 
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] #17827: code example seems not to be correct

[Django]

#17827: code example seems not to be correct
---+--
 Reporter:  bernhardkircher@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 You're looking at the docs for the development version of the docs, but
 using version 1.3 of the code.

 You can switch to the 1.3 version of the docs with the version chooser at
 the bottom-right of the website.

 Duplicate of
 [https://code.djangoproject.com/search?q=django.conf.urls.defaults a dozen
 tickets].

-- 
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] #17827: code example seems not to be correct

[Django]

#17827: code example seems not to be correct
---+--
 Reporter:  bernhardkircher@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  duplicate
 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 kmtracey):

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


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

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

[Django] #17827: code example seems not to be correct

[Django]

#17827: code example seems not to be correct
---+
 Reporter:  bernhardkircher@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 the last code example on page
 [https://docs.djangoproject.com/en/dev/intro/tutorial03/]:
 seems to be wrong:

 from django.conf.urls import patterns, include, url

 should be:

 from django.conf.urls.'''defaults''' import patterns, include, url

-- 
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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
-+-
 Reporter:  minarets |Owner:  julien
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-

Comment (by aaugustin):

 #17826 could be fixed by this patch too (to be tested).

-- 
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] #17826: Failures in Firefox+Windows 7+Admin filter tests

[Django]

#17826: Failures in Firefox+Windows 7+Admin filter tests
---+
 Reporter:  ramiro |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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
---+
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 This feature was rewritten in #13614, which should be committed any time.
 There's a non-negligible chance that this problem will be fixed as a side
 effect.

-- 
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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
-+-
 Reporter:  minarets |Owner:  julien
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-

Comment (by ramiro):

 Replying to [comment:25 julien]:

 > With this patch, in Firefox, if there are multiple filter widgets on the
 page, then only the first one keeps the selected values after pressing
 'Back'; all other widgets receive the initial values. Run the
 `test_back_button_bug_13614` test to get an illustration.
 >
 > I've spent a lot of time trying to debug this and I'm really stumped. I
 haven't been able to figure out why Firefox behaves that way yet. Any
 insight would be helpful.

 I've tested the patch on Windows 7:

 * Things work ok and as expected on Chrome (test passes)

 * ... and sort of work on Firefox (10.0.2)

 If (always with Firefox):

 * In the relevant sections I have Peter, Jenny, Lisa and Bob in the
 top/left -hand lists and Jason, John, Arthur and Cliff in the bottom/right
 -hand lists (as left by execute_basic_operations())

 * Then click the 'Home' link and then the Back browser button

 I get back the status preserved in both widgets **ordering included**.

 At this point the `test_back_button_bug_13614()` test method seems to
 expect them in e.g. the Bob, Jenny, Lisa, Peter order.

 Then, when I save the School and come back to edit it again... I get the
 order the tests expect (maybe by Student PK?).

 Maybe we can change at least one of the assertions to just assert that
 set(...) == set(...)?

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

[noreply]

Author: aaugustin
Date: 2012-03-04 12:32:12 -0800 (Sun, 04 Mar 2012)
New Revision: 17654

Modified:
   django/trunk/docs/topics/i18n/timezones.txt
Log:
Fixed a ReST error. Thanks md4d for the report.


Modified: django/trunk/docs/topics/i18n/timezones.txt
===
--- django/trunk/docs/topics/i18n/timezones.txt 2012-03-04 17:34:22 UTC (rev 
17653)
+++ django/trunk/docs/topics/i18n/timezones.txt 2012-03-04 20:32:12 UTC (rev 
17654)
@@ -32,9 +32,9 @@
 
 Time zone support is disabled by default. To enable it, set :setting:`USE_TZ =
 True ` in your settings file. Installing pytz_ is highly recommended,
-but not mandatory. It's as simple as::
+but not mandatory. It's as simple as:
 
-.. code-block::
+.. code-block:: bash
 
 $ sudo pip install pytz
 

-- 
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] #17683: `BaseModelFormSet` ignore form's widgets options when adding the pk field

[Django]

#17683: `BaseModelFormSet` ignore form's widgets options when adding the pk 
field
-+-
 Reporter:  charettes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  basemodelformset | Triage Stage:  Accepted
  widget |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by charettes):

 * cc: charette.s@… (added)
 * has_patch:  0 => 1
 * needs_tests:  1 => 0


Comment:

 Added patch with tests. Note that I also corrected
 `regressiontests.model_formsets.regress.CustomWidget` (introduced for
 #13095) to actually be a widget and not a field subclass.

-- 
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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 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 alpar):

 Replying to [comment:21 aaugustin]:
 > For the record, I disagree strongly with the [comment:5 wording
 suggested in comment 5].

 That wording was used only to emphasize that I found it a major issue. I
 didn't intended that text for actual inclusion in the doc, either. Sorry
 for not being clearer about it.

 Replying to [comment:26 kmtracey]:

 > > My problem is that although we "use a better database" for production,
 but we use SQLite during the development, because it is easier to setup,
 to create and share snapshots etc.
 >
 > ...and it will quietly accept plenty of error cases that your production
 database will choke on, thus hiding errors during development that will
 NOT be hidden in production. Get a better database, even in development.

 I don't think this is the right place for debating over development
 practices. Like it or not, many people use SQLite in some stages of
 development even when eventually a more capable database is used for
 production. And those people are affected by the 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-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] #17763: Problem with auth_permission name length

[Django]

#17763: Problem with auth_permission name length
--+
 Reporter:  stenius@… |Owner:  elbarto
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.3
 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 elbarto):

 * owner:  nobody => elbarto


-- 
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] #17683: `BaseModelFormSet` ignore form's widgets options when adding the pk field

[Django]

#17683: `BaseModelFormSet` ignore form's widgets options when adding the pk 
field
-+-
 Reporter:  charettes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  basemodelformset | Triage Stage:  Accepted
  widget |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by claudep):

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


Comment:

 I see no reason why the pk field wouldn't respect the widgets dict. Patch
 welcome!

-- 
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] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 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 claudep):

 Could you test with Django 1.4? I'm quite sure at least one bug related
 with Unicode file names has been fixed, but was unable to find the ticket.

-- 
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] #17826: Failures in Firefox+Windows 7+Admin filter tests

[Django]

#17826: Failures in Firefox+Windows 7+Admin filter tests
---+--
 Reporter:  ramiro |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by ramiro:

Old description:

> Ran the `admin_widgets` regression tests as of now are run with both the
> Firefox and Chrome Selenium drivers active.
>
> Chrome tests run without errors, Firefox ones show two failures:
> {{{
> (selenium) C:\...\django\trunk\tests>python runtests.py
> --settings=test_sqlite admin_widgets
> Creating test database for alias 'default'...
> Creating test database for alias 'other'...
> ..FF
> ==
> FAIL: test_basic
> (regressiontests.admin_widgets.tests.HorizontalVerticalFilterSeleniumFirefoxTests)
> --
> Traceback (most recent call last):
>   File
> "C:\...\django\trunk\tests\regressiontests\admin_widgets\tests.py", line
> 604, in test_basic
> [self.arthur, self.cliff, self.jason, self.john])
> AssertionError: Lists differ: [,  [, 
> First differing element 0:
> Lisa
> Arthur
>
> Second list contains 2 additional elements.
> First extra element 2:
> Jason
>
> - [, ]
> }}}
>

> Versions:
>
> - Firefox: 10.0.2
> - selenium Python module
> - Chrome: 17.0.963.56 m
> - Windows: 7 64 bits

New description:

 Ran the `admin_widgets` regression tests as of now are run with both the
 Firefox and Chrome Selenium drivers active.

 Chrome tests run without errors, Firefox ones show two failures:
 {{{
 (selenium) C:\...\django\trunk\tests>python runtests.py
 --settings=test_sqlite admin_widgets
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 ..FF
 ==
 FAIL: test_basic
 
(regressiontests.admin_widgets.tests.HorizontalVerticalFilterSeleniumFirefoxTests)
 --
 Traceback (most recent call last):
   File "C:\...\django\trunk\tests\regressiontests\admin_widgets\tests.py",
 line 604, in test_basic
 [self.arthur, self.cliff, self.jason, self.john])
 AssertionError: Lists differ: [, , , ]
 }}}


 Versions:

 - Firefox: 10.0.2
 - selenium Python module: 2.20.0
 - Chrome: 17.0.963.56 m
 - Windows: 7 64 bits

--

-- 
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] #17826: Failures in Firefox+Windows 7+Admin filter tests

[Django]

#17826: Failures in Firefox+Windows 7+Admin filter tests
---+--
 Reporter:  ramiro |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 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 charettes):

 * cc: charette.s@… (added)


Comment:

 Ran the tests with FF11 on ubuntu 12.04 64 bits and it works fine

 {{{
 (django-trunk)simon@simon-laptop:~/Developpement/django-trunk/tests$
 ./runtests.py admin_widgets --settings=test_sqlite
 --liveserver=localhost:8082
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 ..s.s..
 --
 Ran 41 tests in 21.377s

 OK (skipped=2)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

 Can you update your version and FF and see if it fixes it?

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

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

Re: [Django] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 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 kmtracey):

 Replying to [comment:15 alpar]:
 > Replying to [comment:7 carljm]:
 > > [...] since it seems likely that the answer "use a better database"
 suffices to prevent it being an actual problem in production [...]
 >
 > My problem is that although we "use a better database" for production,
 but we use SQLite during the development, because it is easier to setup,
 to create and share snapshots etc.

 ...and it will quietly accept plenty of error cases that your production
 database will choke on, thus hiding errors during development that will
 NOT be hidden in production. Get a better database, even in development.

-- 
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] #17826: Failures in Firefox+Windows 7+Admin filter tests

[Django]

#17826: Failures in Firefox+Windows 7+Admin filter tests
-+
   Reporter:  ramiro |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  SVN
   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  |
-+
 Ran the `admin_widgets` regression tests as of now are run with both the
 Firefox and Chrome Selenium drivers active.

 Chrome tests run without errors, Firefox ones show two failures:
 {{{
 (selenium) C:\...\django\trunk\tests>python runtests.py
 --settings=test_sqlite admin_widgets
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 ..FF
 ==
 FAIL: test_basic
 
(regressiontests.admin_widgets.tests.HorizontalVerticalFilterSeleniumFirefoxTests)
 --
 Traceback (most recent call last):
   File "C:\...\django\trunk\tests\regressiontests\admin_widgets\tests.py",
 line 604, in test_basic
 [self.arthur, self.cliff, self.jason, self.john])
 AssertionError: Lists differ: [, , , ]
 }}}


 Versions:

 - Firefox: 10.0.2
 - selenium Python module
 - Chrome: 17.0.963.56 m
 - Windows: 7 64 bits

-- 
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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 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
-+-
Changes (by aaugustin):

 * owner:  aaugustin => nobody


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

[noreply]

Author: aaugustin
Date: 2012-03-04 09:34:22 -0800 (Sun, 04 Mar 2012)
New Revision: 17653

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Documented a limit of the SQLite backend, in relation with the bulk_create 
function. Refs #17788.


Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2012-03-04 16:47:28 UTC (rev 
17652)
+++ django/trunk/docs/ref/models/querysets.txt  2012-03-04 17:34:22 UTC (rev 
17653)
@@ -1371,6 +1371,21 @@
 * If the model's primary key is an :class:`~django.db.models.AutoField` it
   does not retrieve and set the primary key attribute, as ``save()`` does.
 
+.. admonition:: Limits of SQLite
+
+SQLite sets a limit on the number of parameters per SQL statement. The
+maximum is defined by the SQLITE_MAX_VARIABLE_NUMBER_ compilation option,
+which defaults to 999. For instance, if your model has 8 fields (including
+the primary key), you cannot create more than 999 // 8 = 124 instances at
+a time. If you exceed this limit, you will get an exception::
+
+django.db.utils.DatabaseError: too many SQL variables
+
+If your application's performance requirements exceed SQLite's limits, you
+should switch to another database engine, such as PostgreSQL.
+
+.. _SQLITE_MAX_VARIABLE_NUMBER: 
http://sqlite.org/limits.html#max_variable_number
+
 count
 ~
 

-- 
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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 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 aaugustin):

 In [17653]:
 {{{
 #!CommitTicketReference repository="" revision="17653"
 Documented a limit of the SQLite backend, in relation with the bulk_create
 function. Refs #17788.
 }}}

-- 
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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 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
-+-
Changes (by aaugustin):

 * severity:  Release blocker => Normal


-- 
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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   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 akaariai):

 Looks good to me.

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

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

Re: [Django] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
-+-
 Reporter:  minarets |Owner:  julien
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by aaugustin):

 * stage:  Accepted => Ready for checkin


Comment:

 I don't have much to say about the patch: it's a rewrite, it looks clean,
 and it's tested.

 I tested on a model with four M2M fields, two displayed horizontally and
 two vertically, under OS X.

 Without the patch: Firefox => OK, Chrome => KO, Safari => KO. This
 confirms the initial analysis that failures occurred under WebKit.

 With the patch: Firefox => OK, Chrome => OK, Safari => OK.

 As far as manual testing goes, it seems to me that everything is OK, even
 with multiple widgets. Specifically, I can't reproduce the problems you
 encountered with Firefox. Assuming you've checked that the widgets work
 under IE, the patch is good to go.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] r17652 - django/trunk/tests/regressiontests/staticfiles_tests

[noreply]

Author: kmtracey
Date: 2012-03-04 08:47:28 -0800 (Sun, 04 Mar 2012)
New Revision: 17652

Modified:
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Fix staticfiles_tests.TestCollectionCachedStorage.test_post_processing so it 
passes on Windows.


Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-04 16:10:18 UTC (rev 17651)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-04 16:47:28 UTC (rev 17652)
@@ -495,8 +495,8 @@
 collectstatic_cmd = CollectstaticCommand()
 collectstatic_cmd.set_options(**collectstatic_args)
 stats = collectstatic_cmd.collect()
-self.assertTrue(u'cached/css/window.css' in stats['post_processed'])
-self.assertTrue(u'cached/css/img/window.png' in stats['unmodified'])
+self.assertTrue(os.path.join('cached', 'css', 'window.css') in 
stats['post_processed'])
+self.assertTrue(os.path.join('cached', 'css', 'img', 'window.png') in 
stats['unmodified'])
 
 # we set DEBUG to False here since the template tag wouldn't work otherwise
 TestCollectionCachedStorage = override_settings(**dict(TEST_SETTINGS,

-- 
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] #17627: contrib.admin.util is misnamed

[Django]

#17627: contrib.admin.util is misnamed
--+
 Reporter:  PaulM |Owner:  lukegb
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by lukegb):

 * needs_better_patch:  1 => 0


Comment:

 Uploaded 0003.patch - replaced import * with a more specific import, and
 fixed deprecation.txt.

-- 
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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   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 aaugustin):

 I'm taking care of adding a warning. It boils down to: "don't use SQLite
 if your application has requirements that exceed SQLite's limits."

 For the record, I disagree strongly with the [comment:5 wording suggested
 in comment 5]. We won't spread FUD like "this number depends on the
 database backend", nor cargo-cult advice like "don't use this function."

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

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

Re: [Django] #17677: WizardView.get_form destroys 'instance' and 'queryset' from get_form_kwargs

[Django]

#17677: WizardView.get_form destroys 'instance' and 'queryset' from 
get_form_kwargs
---+---
 Reporter:  goodtune   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.formtools  |  Version:  1.4-alpha-1
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+---
Changes (by jezdez):

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


Comment:

 In [17651]:
 {{{
 #!CommitTicketReference repository="" revision="17651"
 Fixed #17677 -- Made sure the WizardView doesn't accidentally overwrite
 the `instance` or `queryset` form parameters when they are already set by
 the `get_form_kwargs` method. Thanks to goodtune and Stephan Jäkel.
 }}}

-- 
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] r17651 - in django/trunk/django/contrib/formtools: tests/wizard tests/wizard/wizardtests wizard

[noreply]

Author: jezdez
Date: 2012-03-04 08:10:18 -0800 (Sun, 04 Mar 2012)
New Revision: 17651

Modified:
   django/trunk/django/contrib/formtools/tests/wizard/__init__.py
   django/trunk/django/contrib/formtools/tests/wizard/wizardtests/forms.py
   django/trunk/django/contrib/formtools/tests/wizard/wizardtests/tests.py
   django/trunk/django/contrib/formtools/wizard/views.py
Log:
Fixed #17677 -- Made sure the WizardView doesn't accidentally overwrite the 
`instance` or `queryset` form parameters when they are already set by the 
`get_form_kwargs` method. Thanks to goodtune and Stephan J?\195?\164kel.

Modified: django/trunk/django/contrib/formtools/tests/wizard/__init__.py
===
--- django/trunk/django/contrib/formtools/tests/wizard/__init__.py  
2012-03-04 09:33:28 UTC (rev 17650)
+++ django/trunk/django/contrib/formtools/tests/wizard/__init__.py  
2012-03-04 16:10:18 UTC (rev 17651)
@@ -15,4 +15,5 @@
 CookieWizardTests,
 WizardTestKwargs,
 WizardTestGenericViewInterface,
+WizardFormKwargsOverrideTests,
 )

Modified: 
django/trunk/django/contrib/formtools/tests/wizard/wizardtests/forms.py
===
--- django/trunk/django/contrib/formtools/tests/wizard/wizardtests/forms.py 
2012-03-04 09:33:28 UTC (rev 17650)
+++ django/trunk/django/contrib/formtools/tests/wizard/wizardtests/forms.py 
2012-03-04 16:10:18 UTC (rev 17651)
@@ -2,8 +2,10 @@
 import tempfile
 
 from django import forms
+from django.contrib.auth.models import User
 from django.core.files.storage import FileSystemStorage
 from django.forms.formsets import formset_factory
+from django.forms.models import modelformset_factory
 from django.http import HttpResponse
 from django.template import Template, Context
 
@@ -50,6 +52,13 @@
 context.update({'another_var': True})
 return context
 
+class UserForm(forms.ModelForm):
+class Meta:
+model = User
+fields = ('username', 'email')
+
+UserFormSet = modelformset_factory(User, form=UserForm)
+
 class SessionContactWizard(ContactWizard):
 storage_name = 
'django.contrib.formtools.wizard.storage.session.SessionStorage'
 

Modified: 
django/trunk/django/contrib/formtools/tests/wizard/wizardtests/tests.py
===
--- django/trunk/django/contrib/formtools/tests/wizard/wizardtests/tests.py 
2012-03-04 09:33:28 UTC (rev 17650)
+++ django/trunk/django/contrib/formtools/tests/wizard/wizardtests/tests.py 
2012-03-04 16:10:18 UTC (rev 17651)
@@ -7,6 +7,7 @@
 from django.conf import settings
 from django.contrib.auth.models import User
 from django.contrib.formtools.wizard.views import CookieWizardView
+from django.contrib.formtools.tests.wizard.forms import UserForm, UserFormSet
 
 
 class WizardTests(object):
@@ -331,3 +332,48 @@
 response = view(factory.get('/'))
 self.assertEquals(response.context_data['test_key'], 'test_value')
 self.assertEquals(response.context_data['another_key'], 
'another_value')
+
+
+class WizardFormKwargsOverrideTests(TestCase):
+def setUp(self):
+super(WizardFormKwargsOverrideTests, self).setUp()
+self.rf = RequestFactory()
+
+# Create two users so we can filter by is_staff when handing our
+# wizard a queryset keyword argument.
+self.normal_user = User.objects.create(username='test1', 
email='nor...@example.com')
+self.staff_user = User.objects.create(username='test2', 
email='st...@example.com', is_staff=True)
+
+def test_instance_is_maintained(self):
+self.assertEqual(2, User.objects.count())
+queryset = User.objects.get(pk=self.staff_user.pk)
+
+class InstanceOverrideWizard(CookieWizardView):
+def get_form_kwargs(self, step):
+return {'instance': queryset}
+
+view = InstanceOverrideWizard.as_view([UserForm])
+response = view(self.rf.get('/'))
+
+form = response.context_data['wizard']['form']
+
+self.assertNotEqual(form.instance.pk, None)
+self.assertEqual(form.instance.pk, self.staff_user.pk)
+self.assertEqual('st...@example.com', form.initial.get('email', None))
+
+def test_queryset_is_maintained(self):
+queryset = User.objects.filter(pk=self.staff_user.pk)
+
+class QuerySetOverrideWizard(CookieWizardView):
+def get_form_kwargs(self, step):
+return {'queryset': queryset}
+
+view = QuerySetOverrideWizard.as_view([UserFormSet])
+response = view(self.rf.get('/'))
+
+formset = response.context_data['wizard']['form']
+
+self.assertNotEqual(formset.queryset, None)
+self.assertEqual(formset.initial_form_count(), 1)
+self.assertEqual(['st...@example.com'],
+list(formset.queryset.values_list('email', flat=True)))

Modified: django/trunk/django/contrib/formt

Re: [Django] #17726: Admin's Recent Actions broken for multiple admin site instances with unique registered models

[Django]

#17726: Admin's Recent Actions broken for multiple admin site instances with 
unique
registered models
-+-
 Reporter:  smacleod |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  admin, multiple  | Triage Stage:
  admin sites, recent actions|  Unreviewed
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:   => duplicate


Comment:

 Thanks for the report, however this is a duplicate of #9151, which was
 wontfixed. If you disagree with this resolution, please take this question
 to [http://groups.google.com/group/django-developers/topics django-
 developers].

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13223: ValueError with inline and save as new

[Django]

#13223: ValueError with inline and save as new
+
 Reporter:  lucalenardi |Owner:  igors
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  1.1
 Severity:  Normal  |   Resolution:
 Keywords:  admin, save-as-new  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by igors):

 I'm pushing small commits to my git fork:
 https://github.com/igorsobreira/django/commits/master (if anyone is
 interesting in follow or review step-by-step).

 When I'm done I'll attach the full patch here.

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

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

Re: [Django] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   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 akaariai):

 Good catch. It does indeed break self-referencing foreign keys. Although
 the breakage happens only when the batch needs to be splitted, and in that
 case you currently get an error anyways... Still, the pk set/not set mixed
 in one query could already give you problems with foreign keys.

 Leaving all this as a 1.5 problem sounds like a good plan at this point.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


-- 
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] #17788: bulk_create() "too many SQL variables" error

[Django]

#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   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 aaugustin):

 Possibly a stupid question, but what if the model has a foreign key to
 itself? Isn't the chunking likely to break foreign key constraints?

 Even though the patch is rather straightforward, I'm really wary of
 unexpected side effets, on the eve of a release candidate.

 I suggest we document the problem as a know limitation of the SQLite
 backend in 1.4 and fix it properly later -- along with the other problems
 triggered by this limitation, like #16426.

-- 
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] #17765: Better model 'app_label' introspection using 'INSTALLED_APPS'

[Django]

#17765: Better model 'app_label' introspection using 'INSTALLED_APPS'
-+-
 Reporter:  fengb|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  app_label|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1
 * type:  New feature => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Your proposal looks correct. But maybe Django should just forbid to define
 modules outside of `.models` — this deserves a bit more
 investigation.

 Maybe we should raise an error when `app_label` isn't in `INSTALLED_APPS`.
 Currently it's possible to import models from an app that isn't in
 `INSTALLED_APPS`, and it can lead to hard-to-debug errors. This is related
 to the app-refactor project.

-- 
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] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 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 andi@…):

 Checking the locale was '''the''' first thing to check. No matter what I
 did: UnicodeEncodeError.
 The system, Apache and python (os.environ) all report locale to be as set
 de_DE.UTF-8.

 As I said, it was working on Debian 5 (Python 2.5, Django 1.3.1). It just
 fails on Ubuntu (Python 2.6, Django 1.3.1; haven't tried other server OS).

 This is the link to the group discussion: http://groups.google.com/group
 /django-users/browse_thread/thread/444e92fffbac31ae

-- 
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] #17700: Django formset documentation missing Class Based View Docs

[Django]

#17700: Django formset documentation missing Class Based View Docs
--+
 Reporter:  rh0dium   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 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
--+
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 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):

 One more idea: would it be possible to actually try to set the locale to
 UTF8 based one when the server is started and the locale isn't one
 already? That would be a new setting: something like LOCALE='en_US.UTF8'.
 The global_settings default would be None for "use whatever configured",
 and the settings template would need to have OS-dependent LOCALE. There is
 already a precedent: the TIME_ZONE setting alters os.environ...

 The way to do this is use locale.setlocale(LC_ALL, wanted_locale) in
 django.conf.__init__.py.

 I haven't tried this idea, so I don't know if this really works, but maybe
 worth a try in 1.5.

-- 
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] #17752: Serialization and multi-table inheritance

[Django]

#17752: Serialization and multi-table inheritance
--+
 Reporter:  issarisc@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 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
--+
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 I'm not sure of what the best practice is, but it seems there's room for
 improving the docs. Accepting on this basis.

-- 
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] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 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 aaugustin):

 (I wrote this before reading Anssi's comment.)

 Many developers would be surprised if Django automatically altered the
 names of uploaded files, and it would be backwards incompatible, so we
 won't do that.

 Should we offer this feature as an option? "Normalizing" file names is
 easy -- the snippet you pasted above shows how to do it -- but it's also a
 matter of taste. For instance, one could prefer:

 {{{
 data.name = unicodedata.normalize('NFKD', data.name).encode('ascii',
 'ignore')
 }}}

 Therefore, I'm reluctant to provide this feature in Django.

 

 Still, I'm surprised that you got an `UnicodeEncodeError`. It may reveal a
 bug in Django.

 I suppose you already set
 [https://docs.djangoproject.com/en/1.3/howto/deployment/modpython/#if-you-
 get-a-unicodeencodeerror LANG and LC_ALL] correctly?

 Can you provide a link to the django-users discussion?

-- 
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] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 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
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 Isn't this the nice "you must set your locale correctly for your web-
 server user" error. Something like this:
 http://stackoverflow.com/questions/6171278/unicode-in-django-admin. If you
 Google for this there are lot more similar errors to be found.

 I, too, was hit with this issue some time ago. I have two suggestions:
   - Issue a warning when Django is ran in non-UTF8 environment. Granted,
 this will be hidden in the log files, but still gives developers a chance
 to fix this before bug-reports from production. This is one of those bugs
 which are hard to spot in testing...
   - When the unicode error happens in file saving, convert it to a more
 explanatory one. Link to documentation explaining this issue if possible.

 You could also issue an warning always when a file save operation gets an
 unicode string and the server is not in UTF-8 locale setting, even if
 there isn't any actual error.

 Of course, adding more warnings about this in the documentation is one way
 forward, too.

 I am not too sure if the optional conversion is a good solution. The
 problem here is that you will still get the error in production. You will
 not remember to check that option _before_ you are hit with this, and
 having it default to on is not going to work. If there are enough users
 who want that option then why not, but it will not magically solve this
 problem.

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

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

Re: [Django] #17725: Extend EMPTY_VALUES for the form and|or model field

[Django]

#17725: Extend EMPTY_VALUES for the form and|or model field
-+--
 Reporter:  prudnikov|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 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 aaugustin):

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


Comment:

 While this may be appropriate for your particular use case, it sounds like
 a anti-feature to me:
 {{{
 >>> import urllib
 >>> urllib.urlencode({"name":"Hello","parent":"None"})   # my parent
 is actually called "None", anything wrong with that?
 'name=Hello&parent=None'
 }}}

 If you need this logic in your app, you may implement it:
 - for a specific field, in your (Model)Form's `clean_` method
 - for all fields of a model, in your (Model)Form's `clean` method (by
 iterating over all fields)
 - for all fields of all models, in the `clean` method of a mixin class
 that you'll add to your (Model)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-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] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 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 anonymous):

 I would not call it a "bug", as it was working absolutely fine on Debian
 Lenny. I've tried to locate the problem with help of the Django users
 group, but I found no way of getting it to work on a Ubuntu server.

 In my particular case I'm uploading images for a gallery app. And having
 nice URL-friendly filenames would be a "feature".
 Having non-ASCII characters in an URL (even if allowed) can get quite
 messy, especially when server and browser speak different dialects, e.g.
 de_DE.utf8 and de_DE.latin1.

 So, please look at this "bug report" as a 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-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] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 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 aaugustin):

 If this is a bug in Django, it must be fixed, not worked-around with a
 data-destroying operation.

 It may also be a problem in your setup (environment, locale, etc.)

-- 
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] #17816: UnicodeEncodeError in Image- and FileFields

[Django]

#17816: UnicodeEncodeError in Image- and FileFields
-+-
 Reporter:  andi@…   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Forms|   Resolution:
 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 andi@…):

 Another elegant solution woud be:


 {{{
 class MyImageField(ImageField):

 def __init__(self, *args, **kwargs):
 super(MyImageField, self).__init__(*args, **kwargs)

 def clean(self, *args, **kwargs):
 data = super(MyImageField, self).clean(*args, **kwargs)
 data.name = data.name.encode('ascii','ignore')
 return data
 }}}

-- 
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] #17789: when i use a custom FieldListFilter class for a given field.

[Django]

#17789: when i use a custom FieldListFilter class for a given field.
-+--
 Reporter:  Kidwind  |Owner:  julien
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  FieldListFilter  | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by julien):

 * status:  new => closed
 * resolution:   => needsinfo
 * stage:  Accepted => Unreviewed


Comment:

 As stated in the documentation, if an element of `list_filter` is a tuple,
 then the first element of that tuple must be a field name. Your example
 (`'RelationModel__Field'`) isn't just a field name — it spans
 relationships. I'm not saying that there can't be any valid use case for
 this, but right now it seems like a mis-use of the API.

 Please reopen this ticket if you can describe a valid use case for using a
 field name spanning relationships inside that tuple. If you do, then
 providing some sample code would be useful to understand your use case.
 Thank you.

-- 
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] #17716: include(arg, namespace=None, app_name=None) replace app_name with namespace

[Django]

#17716: include(arg, namespace=None, app_name=None) replace app_name with 
namespace
-+-
 Reporter:  blackip@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:
 Severity:  Normal   |  1.4-alpha-1
 Keywords:  include reverse url  |   Resolution:
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Old description:

> When we register urls - we can specify app_name like this
>
> urlpatterns = patterns('',
> url(r'^inventory/', include('inventory.urls', app_name='inventory')),
> url(r'^cart/', include('cart.urls',app_name='cart')),
>
> Then we can use reverse method or {% url cart:cart  %} to generate url.
>
> But it does not work - ''got NoReverseMatch at /cart/
>
> u'cart' is not a registered namespace
> Request Method: GET
> Request URL:http://localhost:8000/cart/
> Django Version: 1.4a1
> ''
>
> When I register urls like this
>
> url(r'^inventory/', include('inventory.urls',
> namespace='inventory')),
> url(r'^cart/', include('cart.urls',namespace='cart')),
>
> IT DOES WORK !
>
> According to documentation format for urls should be
>
> {% url app_name:view_name  %}
> but actual format is
> {% url namespace:view_name  %}
>
> I think this is a bug
>

>
> The source of bug may be in
>
> file /usr/local/lib/python2.7/site-packages/django/conf/urls/__init__.py
> function include(arg, namespace=None, app_name=None)
>
> It returns tuple (urlconf_module, app_name, namespace)
> It looks like it should be (urlconf_module, namespace, app_name)

New description:

 When we register urls - we can specify `app_name` like this

 {{{
 urlpatterns = patterns('',
 url(r'^inventory/', include('inventory.urls', app_name='inventory')),
 url(r'^cart/', include('cart.urls',app_name='cart')),
 }}}

 Then we can use `reverse` method or `{% url cart:cart  %}` to generate
 url.

 But it does not work

 {{{
 got NoReverseMatch at /cart/

 u'cart' is not a registered namespace
 Request Method: GET
 Request URL:http://localhost:8000/cart/
 Django Version: 1.4a1
 }}}

 When I register urls like this

 {{{
 url(r'^inventory/', include('inventory.urls', namespace='inventory')),
 url(r'^cart/', include('cart.urls',namespace='cart')),
 }}}

 IT DOES WORK !

 According to documentation format for urls should be

 `{% url app_name:view_name  %}`

 but actual format is

 `{% url namespace:view_name  %}`

 I think this is a bug

 The source of bug may be in
 file `/usr/local/lib/python2.7/site-packages/django/conf/urls/__init__.py`
 function `include(arg, namespace=None, app_name=None)`

 It returns `tuple (urlconf_module, app_name, namespace)`

 It looks like it should be `(urlconf_module, namespace, app_name) `

--

Comment:

 Fixed formatting (please use preview).

-- 
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] #17812: Symlink link to media files is deleted after calling of delete method of ImageField if value of it field is None.

[Django]

#17812: Symlink link to media files is deleted after calling of delete method of
ImageField if value of it field is None.
-+-
 Reporter:  piterimov@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.3
  uploads/storage|   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Here's what I understand from your report (I see you aren't a native
 speaker):

 - `settings.MEDIA_ROOT` is a symlink — for instance, `/var/www/media ->
 /mnt/storage/media`
 - you save a model that has an `ImageField`, without providing any value —
 `instance = MyModel.objects.get(pk=1); instance.my_image = None;
 instance.save()`
 - the symlink gets deleted

 I tried that, and I can't reproduce the problem. To be honest, it sounds
 extremely unlikely that Django would delete a directory or a symlink like
 that.

-- 
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] #17802: Pass the request down to the Sitemap callable

[Django]

#17802: Pass the request down to the Sitemap callable
--+--
 Reporter:  rm_   |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sitemaps  |  Version:  SVN
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by aaugustin):

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


Comment:

 This patch doesn't change anything to the public API. It only makes it
 easier for developers to write subclasses of `Sitemap` (which isn't
 officially supported).

 If we decided to make this change, it would have to be tested. Otherwise,
 it could be refactored away by mistake. We could also document more parts
 of `Sitemap`, making them public APIs.

 

 However, I'm not sure this patch is the best solution to the original
 problem. If you "serve the same app under different domains", you must be
 using different sites, which means different `settings.SITE_ID`. IMO you
 should just change the output of your sitemaps based on the current site
 (for the "different domains" part), or on another setting.

 Tentatively closing "needsinfo", please reopen if that solution doesn't
 work.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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.