Re: [Django] #17944: Unable to access to User record in the admin if the user has a unmanageable password

[Django]

#17944: Unable to access to User record in the admin if the user has a 
unmanageable
password
-+--
 Reporter:  saxix|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.4-beta-1
 Severity:  Release blocker  |   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 saxix):

 * needs_tests:  1 => 0


Comment:

 Added ReadOnlyPasswordHashWidget_0.1.patch

  - added tests both for empty and unparseable password
  - removed exception capturing

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

-- 
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] #17936: SimpleListFilter redirects to ?e=1

[Django]

#17936: SimpleListFilter redirects to ?e=1
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by julien):

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


Comment:

 In [17772]:
 {{{
 #!CommitTicketReference repository="" revision="17772"
 Fixed #17936 -- Fixed a code sample in the admin `SimpleListFilter`
 documentation. Thanks to anonymous for the report.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] r17772 - django/trunk/docs/ref/contrib/admin

[noreply]

Author: julien
Date: 2012-03-20 22:57:22 -0700 (Tue, 20 Mar 2012)
New Revision: 17772

Modified:
   django/trunk/docs/ref/contrib/admin/index.txt
Log:
Fixed #17936 -- Fixed a code sample in the admin `SimpleListFilter` 
documentation. Thanks to anonymous for the report.

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2012-03-20 21:04:57 UTC 
(rev 17771)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2012-03-21 05:57:22 UTC 
(rev 17772)
@@ -606,6 +606,8 @@
   attributes to and override the ``lookups`` and ``queryset`` methods,
   e.g.::
 
+   from datetime import date
+
from django.utils.translation import ugettext_lazy as _
from django.contrib.admin import SimpleListFilter
 
@@ -639,11 +641,11 @@
# Compare the requested value (either '80s' or 'other')
# to decide how to filter the queryset.
if self.value() == '80s':
-   return queryset.filter(birthday__year__gte=1980,
-   birthday__year__lte=1989)
+   return queryset.filter(birthday__gte=date(1980, 1, 1),
+   birthday__lte=date(1989, 12, 
31))
if self.value() == '90s':
-   return queryset.filter(birthday__year__gte=1990,
-  birthday__year__lte=1999)
+   return queryset.filter(birthday__gte=date(1990, 1, 1),
+   birthday__lte=date(1999, 12, 
31))
 
class PersonAdmin(ModelAdmin):
list_filter = (DecadeBornListFilter,)
@@ -677,11 +679,11 @@
   anyone born in the corresponding decades.
   """
   qs = model_admin.queryset(request)
-  if qs.filter(birthday__year__gte=1980,
-birthday__year__lte=1989).exists():
+  if qs.filter(birthday__gte=date(1980, 1, 1),
+birthday__lte=date(1989, 12, 31)).exists():
   yield ('80s', _('in the eighties'))
-  if qs.filter(birthday__year__gte=1990,
-birthday__year__lte=1999).exists():
+  if qs.filter(birthday__gte=date(1990, 1, 1),
+birthday__lte=date(1999, 12, 31)).exists():
   yield ('90s', _('in the nineties'))
 
 * a tuple, where the first element is a field name and the second

-- 
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] #17936: SimpleListFilter redirects to ?e=1

[Django]

#17936: SimpleListFilter redirects to ?e=1
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  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 julien):

 * component:  contrib.admin => Documentation
 * severity:  Release blocker => Normal
 * stage:  Unreviewed => Accepted


Comment:

 Ok, I've verified with the 1.3.X branch and there is no regression here.
 The ORM simply does not consider "birthday__year__gte" a valid lookup. So
 I'll just fix the documentation 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] #17944: Unable to access to User record in the admin if the user has a unmanageable password

[Django]

#17944: Unable to access to User record in the admin if the user has a 
unmanageable
password
-+--
 Reporter:  saxix|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by carljm):

 * severity:  Normal => Release blocker
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 This is definitely a release-blocking regression, thanks for the report.

 Patch looks good to me except that the "except" clause captures the
 exception when it has no use for it (and uses the old syntax to do so);
 the ",e" should just be removed.

 And it needs a test.

 This violates the string freeze, but I don't see any good alternative.
 Having this fixed with an untranslated message in 1.4 is better than not
 having it fixed.

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

-- 
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] #17944: Unable to access to User record in the admin if the user has a unmanageable password

[Django]

#17944: Unable to access to User record in the admin if the user has a 
unmanageable
password
--+--
 Reporter:  saxix |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4-beta-1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by saxix):

 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * 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] #17944: Unable to access to User record in the admin if the user has a unmanageable password

[Django]

#17944: Unable to access to User record in the admin if the user has a 
unmanageable
password
---+
 Reporter:  saxix  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.auth   |Version:  1.4-beta-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 If the user has a unmanageable password (ie no hashers found)
 ReadOnlyPasswordHashWidget reraise  ValueError up to the UI, this prevents
 to access to the user record if the form contains
 ReadOnlyPasswordHashWidget ( admin ), this happen also for blank password.
 If the system use a custom backend with external authentication there is
 no reason for django to known the password algorithm, but should be still
 possible to access to the user record.
 The patch simply surround the involved lined into the
 ReadOnlyPasswordHashWidget.render() and display a 'Unknown password
 hashing algorithm' message instead.
 Not sure if the message could be improved/changed.

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

-- 
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] #17934: RuntimeWarning: DateTimeField received a naive datetime

[Django]

#17934: RuntimeWarning: DateTimeField received a naive datetime
---+--
 Reporter:  DonYang|Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Uncategorized  |  Version:  1.4-beta-1
 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
---+--

Comment (by charettes):

 You should really use wikiformating, it's quite hard to read your report.

 BTW, [https://bitbucket.org/andrewgodwin/south/changeset/ab21b72cdf8a
 latest south commit fixes something related to timezone]. Can you try to
 reproduce using it? I think you can install *trunk* version by doing `pip
 install https://bitbucket.org/andrewgodwin/south/get/tip.tar.gz`

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

-- 
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] #17934: RuntimeWarning: DateTimeField received a naive datetime

[Django]

#17934: RuntimeWarning: DateTimeField received a naive datetime
---+--
 Reporter:  DonYang|Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Uncategorized  |  Version:  1.4-beta-1
 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 DonYang):

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


Comment:

 I used virtualenvwrapper==3.1
 $mkvirtualenv mysite
 $workon mysite
 (mysite)$pip install Django-1.4c2.tar.gz
 (mysite)$pip install south
 (mysite)$tar zxvf MySQL-python-1.2.3.tar.gz
 (mysite)$cd MySQL-python-1.2.3
 (mysite)$vi site.cfg
 uncommented mysql_config and changed -> /usr/local/mysql/bin/mysql_config
 changed registry_key -> SOFTWARE\MySQL AB\MySQL Server 5.1
 (mysite)$python setup.py build
 (mysite)$python setup install

 (mysite)$pip freeze
 Django==1.4c2
 MySQL-python==1.2.3
 South==0.7.3
 wsgiref==0.1.2

 (mysite)$django-admin.py startproject mysite
 (mysite)$./manage.py startapp polls
 add something to models.py
 --
 from django.db import models

 class Poll(models.Model):
 question = models.CharField(max_length=200)
 --
 created a mysql database 'mysite' with utf-8 unicode
 changed database to mysql
 added south and polls to INSTALLED_APPS
 USE_TZ is True by default
 (mysite)$python manage.py syncdb
 create superuser : no
 (mysite)$python manage convert_to_south polls
 got this
 --
 Creating migrations directory at
 '/Users/don/Workspaces/test_work/mysite/polls/migrations'...
 Creating __init__.py in
 '/Users/don/Workspaces/test_work/mysite/polls/migrations'...
  + Added model polls.Poll
 Created 0001_initial.py. You can now apply this migration with:
 ./manage.py migrate polls
  - Soft matched migration 0001 to 0001_initial.
 Running migrations for polls:
  - Migrating forwards to 0001_initial.
  > polls:0001_initial
(faked)
 /Users/don/.virtualenvs/mysite/lib/python2.7/site-
 packages/django/db/models/fields/__init__.py:808: RuntimeWarning:
 DateTimeField received a naive datetime (2012-03-21 02:00:29.098454) while
 time zone support is active.
   RuntimeWarning)

 App 'polls' converted. Note that South assumed the application's models
 matched the database
 (i.e. you haven't changed it since last syncdb); if you have, you should
 delete the polls/migrations
 directory, revert models.py so it matches the database, and try again.

 --
 and everytime I changed Poll model and migrate it always got this warning
 (mysite)$python manage.py schemamigration polls --auto
 (mysite)$python manage.py migrate polls
 --
 Running migrations for polls:
  - Migrating forwards to 0002_auto__add_field_poll_name.
  > polls:0002_auto__add_field_poll_name
 /Users/don/.virtualenvs/mysite/lib/python2.7/site-
 packages/django/db/models/fields/__init__.py:808: RuntimeWarning:
 DateTimeField received a naive datetime (2012-03-21 02:05:13.321314) while
 time zone support is active.
   RuntimeWarning)
  - Loading initial data for polls.
 Installed 0 object(s) from 0 fixture(s)
 --
 I pip install pytz got nothing help.
 But when I created a new virtualenv with django1.3.1, there is no warning
 at all.
 like this
 --
 (mysite2)don$ python manage.py schemamigration polls --auto
  + Added field title on polls.Poll
 Created 0002_auto__add_field_poll_title.py. You can now apply this
 migration with: ./manage.py migrate polls
 (mysite2)don$ python manage.py migrate pollsRunning migrations for polls:
  - Migrating forwards to 0002_auto__add_field_poll_title.
  > polls:0002_auto__add_field_poll_title
  - Loading initial data for polls.
 No fixtures found.

 --

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

-- 
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 g

Re: [Django] #11277: Hidden fields in Inlines are displayed as empty rows

[Django]

#11277: Hidden fields in Inlines are displayed as empty rows
-+-
 Reporter:  bartTC   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  admin inlines| Triage Stage:  Accepted
  hiddeninput|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by thepapermen):

 * cc: thepapermen (added)


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

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

[Django]

#14030: Use F() objects in aggregates(), annotates() and values()
-+
 Reporter:  delfick  |Owner:  nate_b
 Type:  New feature  |   Status:  assigned
Component:  ORM aggregation  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by nate_b):

 The patches posted here are insufficient to effectively solve this
 problem.

 I have come up with a better solution: refactoring of Aggregate into
 ExpressionNode.

 I have uploaded my branch; it can be found here:

 https://github.com/NateBragg/django/tree/14030

 Some particular points of note:
 * I tried to preserve as much interface as possible; I didn't know how
 much was considered to be more public, so generally I tried to add rather
 than subtract.  However, I did remove a couple things - if you see
 something missing that shouldn't be, let me know.
 * Currently, I'm getting the entire test suite passed on sqlite, postgres,
 mysql, oracle, and postgis.  I was unable to test on oracle spatial - any
 help with that would be appreciated.
 * When fields are combined, they are coerced to a common type;
 IntegerFields are coerced to FloatFields, which are coerced into
 DecimalFields as needed.  Any other kinds of combinations must be of the
 same types.  Also, when coerced to a DecimalField, the precision is
 limited by the original DecimalField.  If this is not correct, or other
 coercions should be added, I'd like to correct that.
 * When joins are required, they tend to be LEFT OUTER; I'd like some
 feedback on this, as I'm not 100% sure its always the best behavior.
 * As the aggregates are a little more complicated, on trivial cases there
 is a minor reduction in performance; using djangobench, I measured
 somewhere between a 3% and 8% increase in runtime.
 * I don't have enough tests - mostly for a lack of creativity.  What kind
 of composed aggregates and expressions would you like to see?  I'll add
 tests for them.

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

-- 
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] #10315: objects.inv not available for intersphinx

[Django]

#10315: objects.inv not available for intersphinx
---+
 Reporter:  awatts |Owner:  jacob
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.0
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by guettli):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Here is a working sphinx config.py snippet:
 {{{
 # Add any Sphinx extension module names here, as strings. They can be
 extensions
 # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
 extensions = ["sphinx.ext.intersphinx"]
 intersphinx_mapping = {
 'python': ('http://docs.python.org/2.7', None),
 'sphinx': ('http://sphinx.pocoo.org/', None),
 'django': ('http://docs.djangoproject.com/en/dev/',
 'http://docs.djangoproject.com/en/dev/_objects/'),
 }
 }}}

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

-- 
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] #17943: Too many open file descriptors while using memcache

[Django]

#17943: Too many open file descriptors while using memcache
-+-
 Reporter:   |  Owner:  nobody
  m.gajda@…  | Status:  new
 Type:  Bug  |Version:  1.3
Component:  Core |   Keywords:  cache memcache open file
  (Cache system) |  descriptors
 Severity:  Normal   |  Has patch:  1
 Triage Stage:   |  UI/UX:  0
  Unreviewed |
Easy pickings:  0|
-+-
 Hi all,

 I am using Django 1.3.1 with memcached server under Linux (PLD distro).
 Django application is run with runfcgi command (maxspare set to 20). After
 switching to Django 1.3.1 (from line 1.2.x) I encountered very strange
 behaviour -- the app became crashing after some time.

 What I have discovered is very large number of open socket connections
 made by the Django app to the memcached server (lsof show hundrets of open
 descriptors). After some time the app process had been killed by the
 system, due to exceeded number of opened file descriptors.

 Look at Google pointed me to the ticket #15324. Since that patch has been
 incorporated in the Django 1.3.1, I have started digging into memcached
 Django wrapper over the pyton-memcached module
 (django.core.cache.backends.memcached). What I found is that Django app
 run in multithreaded mode creates new cache object for every thread. This
 is probably good information, since it has allowed avoid difficult race
 conditions. What is sad - after closing/releasing the thread, the cache
 object is somehow not deleted properly. I mean it seems that it does not
 clean up all gathered resources properly. This lasts with large number of
 opened file descriptors in the memcached case.

 I have added simple patch fixing said behaviour. It works quite well for
 me, thus I assume I could be considered to be improved and somehow merged
 with the Django sources. I have not created any tests, I am sorry for
 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.

[Changeset] r17771 - django/trunk/django/contrib/auth/tests

[noreply]

Author: aaugustin
Date: 2012-03-20 14:04:57 -0700 (Tue, 20 Mar 2012)
New Revision: 17771

Modified:
   django/trunk/django/contrib/auth/tests/models.py
Log:
Fixed a typo in my previous commit. Apologies.


Modified: django/trunk/django/contrib/auth/tests/models.py
===
--- django/trunk/django/contrib/auth/tests/models.py2012-03-20 20:51:16 UTC 
(rev 17770)
+++ django/trunk/django/contrib/auth/tests/models.py2012-03-20 21:04:57 UTC 
(rev 17771)
@@ -1,7 +1,7 @@
 from django.conf import settings
 from django.test import TestCase
 from django.test.utils import override_settings
-svn from django.contrib.auth.models import (Group, User,
+from django.contrib.auth.models import (Group, User,
 SiteProfileNotAvailable, UserManager)
 
 

-- 
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] #17940: RuntimeWarning when running the test suite on a new project

[Django]

#17940: RuntimeWarning when running the test suite on a new project
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  SVN
 Severity:  Release blocker  |   Resolution:  fixed
 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 slacy):

 * cc: slacy@… (added)


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

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

Re: [Django] #17940: RuntimeWarning when running the test suite on a new project

[Django]

#17940: RuntimeWarning when running the test suite on a new project
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  SVN
 Severity:  Release blocker  |   Resolution:  fixed
 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 aaugustin):

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


Comment:

 In [17770]:
 {{{
 #!CommitTicketReference repository="" revision="17770"
 Fixed #17940 -- Enforced USE_TZ = False in contrib apps tests that use
 fixtures containing datetimes.
 }}}

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

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

[noreply]

Author: aaugustin
Date: 2012-03-20 13:51:16 -0700 (Tue, 20 Mar 2012)
New Revision: 17770

Modified:
   django/trunk/django/contrib/auth/tests/context_processors.py
   django/trunk/django/contrib/auth/tests/forms.py
   django/trunk/django/contrib/auth/tests/models.py
   django/trunk/django/contrib/auth/tests/signals.py
   django/trunk/django/contrib/auth/tests/views.py
Log:
Fixed #17940 -- Enforced USE_TZ = False in contrib apps tests that use fixtures 
containing datetimes.


Modified: django/trunk/django/contrib/auth/tests/context_processors.py
===
--- django/trunk/django/contrib/auth/tests/context_processors.py
2012-03-19 21:02:35 UTC (rev 17769)
+++ django/trunk/django/contrib/auth/tests/context_processors.py
2012-03-20 20:51:16 UTC (rev 17770)
@@ -97,7 +97,8 @@
 self.assertEqual(user, response.context['user'])
 
 AuthContextProcessorTests = override_settings(
-TEMPLATE_DIRS = (
+TEMPLATE_DIRS=(
 os.path.join(os.path.dirname(__file__), 'templates'),
-)
+),
+USE_TZ=False,   # required for loading the fixture
 )(AuthContextProcessorTests)

Modified: django/trunk/django/contrib/auth/tests/forms.py
===
--- django/trunk/django/contrib/auth/tests/forms.py 2012-03-19 21:02:35 UTC 
(rev 17769)
+++ django/trunk/django/contrib/auth/tests/forms.py 2012-03-20 20:51:16 UTC 
(rev 17770)
@@ -1,10 +1,12 @@
 from __future__ import with_statement
 import os
+from django.contrib.auth.models import User
+from django.contrib.auth.forms import (UserCreationForm, AuthenticationForm,
+PasswordChangeForm, SetPasswordForm, UserChangeForm, PasswordResetForm)
 from django.core import mail
 from django.forms.fields import Field, EmailField
-from django.contrib.auth.models import User
-from django.contrib.auth.forms import UserCreationForm, AuthenticationForm,  
PasswordChangeForm, SetPasswordForm, UserChangeForm, PasswordResetForm
 from django.test import TestCase
+from django.test.utils import override_settings
 from django.utils.encoding import force_unicode
 from django.utils import translation
 
@@ -74,7 +76,9 @@
 u = form.save()
 self.assertEqual(repr(u), '')
 
+UserCreationFormTest = override_settings(USE_TZ=False)(UserCreationFormTest)
 
+
 class AuthenticationFormTest(TestCase):
 
 fixtures = ['authtestdata.json']
@@ -125,7 +129,9 @@
 self.assertTrue(form.is_valid())
 self.assertEqual(form.non_field_errors(), [])
 
+AuthenticationFormTest = 
override_settings(USE_TZ=False)(AuthenticationFormTest)
 
+
 class SetPasswordFormTest(TestCase):
 
 fixtures = ['authtestdata.json']
@@ -151,7 +157,9 @@
 form = SetPasswordForm(user, data)
 self.assertTrue(form.is_valid())
 
+SetPasswordFormTest = override_settings(USE_TZ=False)(SetPasswordFormTest)
 
+
 class PasswordChangeFormTest(TestCase):
 
 fixtures = ['authtestdata.json']
@@ -198,7 +206,9 @@
 self.assertEqual(PasswordChangeForm(user, {}).fields.keys(),
  ['old_password', 'new_password1', 'new_password2'])
 
+PasswordChangeFormTest = 
override_settings(USE_TZ=False)(PasswordChangeFormTest)
 
+
 class UserChangeFormTest(TestCase):
 
 fixtures = ['authtestdata.json']
@@ -226,7 +236,9 @@
 # Just check we can create it
 form = MyUserForm({})
 
+UserChangeFormTest = override_settings(USE_TZ=False)(UserChangeFormTest)
 
+
 class PasswordResetFormTest(TestCase):
 
 fixtures = ['authtestdata.json']
@@ -304,3 +316,5 @@
 self.assertFalse(form.is_valid())
 self.assertEqual(form["email"].errors,
  [u"The user account associated with this e-mail 
address cannot reset the password."])
+
+PasswordResetFormTest = override_settings(USE_TZ=False)(PasswordResetFormTest)

Modified: django/trunk/django/contrib/auth/tests/models.py
===
--- django/trunk/django/contrib/auth/tests/models.py2012-03-19 21:02:35 UTC 
(rev 17769)
+++ django/trunk/django/contrib/auth/tests/models.py2012-03-20 20:51:16 UTC 
(rev 17770)
@@ -1,6 +1,7 @@
 from django.conf import settings
 from django.test import TestCase
-from django.contrib.auth.models import (Group, User,
+from django.test.utils import override_settings
+svn from django.contrib.auth.models import (Group, User,
 SiteProfileNotAvailable, UserManager)
 
 
@@ -37,7 +38,9 @@
 settings.AUTH_PROFILE_MODULE = 'foo.bar'
 self.assertRaises(SiteProfileNotAvailable, user.get_profile)
 
+ProfileTestCase = override_settings(USE_TZ=False)(ProfileTestCase)
 
+
 class NaturalKeysTestCase(TestCase):
 fixtures = ['authtestdata.json']
 
@@ -50,7 +53,9 @@
 users_group = Group.objects.create(name='users')
 self.assertEquals(Group.objects.get_by_natural_key('users'), 
users_group)
 
+NaturalKeysTe

Re: [Django] #17941: Value request.META["HTTP_HOST"] was lost

[Django]

#17941: Value request.META["HTTP_HOST"] was lost
-+--
 Reporter:  Pajinek  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.3
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by claudep):

 Forgot to mention the get_host method:
 https://docs.djangoproject.com/en/dev/ref/request-
 response/#django.http.HttpRequest.get_host

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

-- 
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] #17941: Value request.META["HTTP_HOST"] was lost

[Django]

#17941: Value request.META["HTTP_HOST"] was lost
-+--
 Reporter:  Pajinek  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.3
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by claudep):

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


Old description:

> I found problem - I hope, that is a bug. I don't know how, but sometimes
> (one times from ten)  the value `request.META["HTTP_HOST"]` was lost.
> It's possible? I trust that this value must exist always.
>
> There is report:
>
> ===
>
> Traceback (most recent call last):
>
>   File "/usr/local/lib/python2.6/dist-
> packages/django/core/handlers/base.py", line 89, in get_response
> response = middleware_method(request)
>
>   File "/var/www/hlplyn_cz/www/./middleware.py", line 18, in
> process_request
> if not request.META["HTTP_HOST"] in
> ("www.","localhost:8000",):
>
> KeyError: 'HTTP_HOST'
>

>  GET:,
> POST:,
> COOKIES:{},
> META:{'DOCUMENT_ROOT': '/',
>  'GATEWAY_INTERFACE': 'CGI/1.1',
>  'HTTP_USER_AGENT': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
> rv:8.0.1) Gecko/20100101 Firefox/8.0.1',
>  'PATH_INFO': u'/',
>  'PATH_TRANSLATED': '/.run.wsgi/',
>  'QUERY_STRING': '',
>  'REMOTE_ADDR': '85.17.213.242',
>  'REMOTE_PORT': '55876',
>  'REQUEST_METHOD': 'GET',
>  'REQUEST_URI': 'http://www.DOMENA.NET/',
>  'SCRIPT_FILENAME': '/.run.wsgi',
>  'SCRIPT_NAME': u'',
>  'SERVER_ADDR': '',
>  'SERVER_ADMIN': '[no address given]',
>  'SERVER_NAME': '',
>  'SERVER_PORT': '80',
>  'SERVER_PROTOCOL': 'HTTP/1.0',
>  'SERVER_SIGNATURE': 'Apache/2.2.16 (Debian) Server at 
> Port 80\n',
>  'SERVER_SOFTWARE': 'Apache/2.2.16 (Debian)',
>  'mod_wsgi.application_group': '|',
>  'mod_wsgi.callable_object': 'application',
>  'mod_wsgi.handler_script': '',
>  'mod_wsgi.input_chunked': '0',
>  'mod_wsgi.listener_host': '',
>  'mod_wsgi.listener_port': '80',
>  'mod_wsgi.process_group': 'wsgi_',
>  'mod_wsgi.request_handler': 'wsgi-script',
>  'mod_wsgi.script_reloading': '1',
>  'mod_wsgi.version': (3, 3),
>  'wsgi.errors': ,
>  'wsgi.file_wrapper':  object at 0x7f84a311eeb8>,
>  'wsgi.input': ,
>  'wsgi.multiprocess': True,
>  'wsgi.multithread': True,
>  'wsgi.run_once': False,
>  'wsgi.url_scheme': 'http',
>  'wsgi.version': (1, 1)}>

New description:

 I found problem - I hope, that is a bug. I don't know how, but sometimes
 (one times from ten)  the value `request.META["HTTP_HOST"]` was lost. It's
 possible? I trust that this value must exist always.

 There is report:
 {{{
 ===

 Traceback (most recent call last):

   File "/usr/local/lib/python2.6/dist-
 packages/django/core/handlers/base.py", line 89, in get_response
 response = middleware_method(request)

   File "/var/www/hlplyn_cz/www/./middleware.py", line 18, in
 process_request
 if not request.META["HTTP_HOST"] in
 ("www.","localhost:8000",):

 KeyError: 'HTTP_HOST'


 ,
 POST:,
 COOKIES:{},
 META:{'DOCUMENT_ROOT': '/',
  'GATEWAY_INTERFACE': 'CGI/1.1',
  'HTTP_USER_AGENT': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:8.0.1) Gecko/20100101 Firefox/8.0.1',
  'PATH_INFO': u'/',
  'PATH_TRANSLATED': '/.run.wsgi/',
  'QUERY_STRING': '',
  'REMOTE_ADDR': '85.17.213.242',
  'REMOTE_PORT': '55876',
  'REQUEST_METHOD': 'GET',
  'REQUEST_URI': 'http://www.DOMENA.NET/',
  'SCRIPT_FILENAME': '/.run.wsgi',
  'SCRIPT_NAME': u'',
  'SERVER_ADDR': '',
  'SERVER_ADMIN': '[no address given]',
  'SERVER_NAME': '',
  'SERVER_PORT': '80',
  'SERVER_PROTOCOL': 'HTTP/1.0',
  'SERVER_SIGNATURE': 'Apache/2.2.16 (Debian) Server at 
 Port 80\n',
  'SERVER_SOFTWARE': 'Apache/2.2.16 (Debian)',
  'mod_wsgi.application_group': '|',
  'mod_wsgi.callable_object': 'application',
  'mod_wsgi.handler_script': '',
  'mod_wsgi.input_chunked': '0',
  'mod_wsgi.listener_host': '',
  'mod_wsgi.listener_port': '80',
  'mod_wsgi.process_group': 'wsgi_',
  'mod_wsgi.request_handler': 'wsgi-script',
  'mod_wsgi.script_reloading': '1',
  'mod_wsgi.version': (3, 3),
  'wsgi.errors': ,
  'wsgi.file_wrapper': ,
  'wsgi.input': ,
  'wsgi.multiprocess': True,
  'wsgi.multithread': True,
  'wsgi.run_once': False,
  'wsgi.url_scheme': 'http',
  'wsgi.version': (1, 1)}>
 }}}

--

Comment:

 The Host header is mandatory in HTTP 1.1
 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23), however
 it might happ

Re: [Django] #17940: RuntimeWarning when running the test suite on a new project

[Django]

#17940: RuntimeWarning when running the test suite on a new project
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 Severity:  Release blocker  |   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 aaugustin):

 * has_patch:  0 => 1


Comment:

 The root cause of the problem lies in the
 
[https://code.djangoproject.com/browser/django/trunk/django/contrib/auth/fixtures
 fixtures] used by the tests of `django.contrib.auth`. As explained in
 [https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#fixtures the
 docs] (once again!) it isn't possible to write fixtures that work both
 with and without `USE_TZ`.

 The easiest solution is to `override_settings(USE_TZ=False)` in all tests
 that use fixtures.

 

 This problem only affects contrib apps, whose tests are likely to be run
 with non-default settings.

 A quick `find` shows that `auth`, `flatpages` and `gis` use fixtures and
 may suffer from the problem:

 {{{
 % find django -name .svn -prune -o -path \*/fixtures/\* -type f -print
 django/contrib/auth/fixtures/authtestdata.json
 django/contrib/auth/fixtures/context-processors-users.xml
 django/contrib/auth/fixtures/natural.json
 django/contrib/auth/fixtures/regular.json
 django/contrib/flatpages/fixtures/sample_flatpages.json
 django/contrib/gis/tests/distapp/fixtures/initial_data.json.gz
 django/contrib/gis/tests/geoapp/fixtures/initial_data.json.gz
 django/contrib/gis/tests/geogapp/fixtures/initial_data.json
 django/contrib/gis/tests/relatedapp/fixtures/initial_data.json.gz
 }}}

 Upon closer inspection, only the `auth` fixtures contain serialized
 `datetime` objects, so the fix only needs to be applied to `auth`.

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

-- 
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] #17940: RuntimeWarning when running the test suite on a new project

[Django]

#17940: RuntimeWarning when running the test suite on a new project
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 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):

 FYI the easiest way to debug this is to turn warning into exceptions as
 explained in
 [https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#code the
 docs].

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

-- 
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] #17942: JSONResponse class for API responses

[Django]

#17942: JSONResponse class for API responses
---+--
 Reporter:  leahculver |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by coderanger):

 * cc: noah@… (added)


Comment:

 Additional notes: should include {{{ensure_ascii=False}}} in the dumps
 call. Should use DjangoJSONEncoder by default to get datetime/decimal
 serialization.

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

-- 
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] #17942: JSONResponse class for API responses

[Django]

#17942: JSONResponse class for API responses
---+--
 Reporter:  leahculver |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by leahculver):

 * version:  1.3 =>


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17942: JSONResponse class for API responses

[Django]

#17942: JSONResponse class for API responses
---+--
 Reporter:  leahculver |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by leahculver):

 * needs_docs:   => 1
 * needs_tests:   => 1
 * 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] #17942: JSONResponse class for API responses

[Django]

#17942: JSONResponse class for API responses
---+
 Reporter:  leahculver |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 To make APIs, many developers have created their own JSONResponse classes
 which are subclasses of Response but returning JSON and with the proper
 mimetype ("application/json").

 Some examples:

 * https://gist.github.com/1265346
 *
 https://github.com/coderanger/statusboard/blob/master/statusboard/utils/json.py
 * http://chronosbox.org/blog/jsonresponse-in-django
 * http://djangosnippets.org/search/?q=jsonresponse

 Related to this wiki page: https://code.djangoproject.com/wiki/AJAX

 This patch should include:

 * mimetype "application/json"

 Optional ideas:

 * support for a callback parameter for JSON-P style responses (see
 https://gist.github.com/1265346)
 * more status codes (see https://gist.github.com/1265346)
 * option to pass a model with a "to_dict", "to_list", or "to_json"
 function (see
 
https://github.com/coderanger/statusboard/blob/master/statusboard/utils/json.py)
 * support for XML, if anyone likes to make XML APIs anymore?

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

-- 
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] #6378: Capture arbitrary output as a template variable

[Django]

#6378: Capture arbitrary output as a template variable
-+
 Reporter:  kcarnold |Owner:  carljm
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by charettes):

 * cc: charette.s@… (added)


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

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

[Django] #17941: Value request.META["HTTP_HOST"] was lost

[Django]

#17941: Value request.META["HTTP_HOST"] was lost
-+
 Reporter:  Pajinek  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (URLs)  |Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I found problem - I hope, that is a bug. I don't know how, but sometimes
 (one times from ten)  the value `request.META["HTTP_HOST"]` was lost. It's
 possible? I trust that this value must exist always.

 There is report:

 ===

 Traceback (most recent call last):

   File "/usr/local/lib/python2.6/dist-
 packages/django/core/handlers/base.py", line 89, in get_response
 response = middleware_method(request)

   File "/var/www/hlplyn_cz/www/./middleware.py", line 18, in
 process_request
 if not request.META["HTTP_HOST"] in
 ("www.","localhost:8000",):

 KeyError: 'HTTP_HOST'


 ,
 POST:,
 COOKIES:{},
 META:{'DOCUMENT_ROOT': '/',
  'GATEWAY_INTERFACE': 'CGI/1.1',
  'HTTP_USER_AGENT': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:8.0.1) Gecko/20100101 Firefox/8.0.1',
  'PATH_INFO': u'/',
  'PATH_TRANSLATED': '/.run.wsgi/',
  'QUERY_STRING': '',
  'REMOTE_ADDR': '85.17.213.242',
  'REMOTE_PORT': '55876',
  'REQUEST_METHOD': 'GET',
  'REQUEST_URI': 'http://www.DOMENA.NET/',
  'SCRIPT_FILENAME': '/.run.wsgi',
  'SCRIPT_NAME': u'',
  'SERVER_ADDR': '',
  'SERVER_ADMIN': '[no address given]',
  'SERVER_NAME': '',
  'SERVER_PORT': '80',
  'SERVER_PROTOCOL': 'HTTP/1.0',
  'SERVER_SIGNATURE': 'Apache/2.2.16 (Debian) Server at 
 Port 80\n',
  'SERVER_SOFTWARE': 'Apache/2.2.16 (Debian)',
  'mod_wsgi.application_group': '|',
  'mod_wsgi.callable_object': 'application',
  'mod_wsgi.handler_script': '',
  'mod_wsgi.input_chunked': '0',
  'mod_wsgi.listener_host': '',
  'mod_wsgi.listener_port': '80',
  'mod_wsgi.process_group': 'wsgi_',
  'mod_wsgi.request_handler': 'wsgi-script',
  'mod_wsgi.script_reloading': '1',
  'mod_wsgi.version': (3, 3),
  'wsgi.errors': ,
  'wsgi.file_wrapper': ,
  'wsgi.input': ,
  'wsgi.multiprocess': True,
  'wsgi.multithread': True,
  'wsgi.run_once': False,
  'wsgi.url_scheme': 'http',
  'wsgi.version': (1, 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.

Re: [Django] #17275: Fix RuntimeWarning in the Django test suite

[Django]

#17275: Fix RuntimeWarning in the Django test suite
-+-
 Reporter:  PaulM|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Testing framework|   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 This is a different issue, I've moved it to its own ticket: #17940.

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

-- 
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] #17940: RuntimeWarning when running the test suite on a new project

[Django]

#17940: RuntimeWarning when running the test suite on a new project
---+---
   Reporter:  aaugustin|  Owner:  aaugustin
   Type:  Bug  | Status:  new
  Component:  contrib.auth |Version:  SVN
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
 ''(reported on IRC)''

 {{{
 19-21:33:09  carljm mYk: is there already an open ticket about the
 fact that when you start a new project and run its tests, you get
 RuntimeWarnings about timezones?
 19-22:17:43  carljm mYk: it's in the contrib.auth tests
 19-22:17:48  carljm three occurrences
 19-22:17:57  carljm haven't tracked it down to the specific tests yet
 19-22:18:10  carljm reproduction is just "startproject, configure db,
 manage.py test auth"
 19-22:22:07   cramm carljm, mYk: /manage.py test -v2
 auth.AuthContextProcessorTests.test_message_attrs
 auth.AuthViewNamedURLTests.test_named_urls
 auth.LoadDataWithNaturalKeysTestCase.test_user_is_created_and_added_to_group
 19-22:22:28   cramm these are the three tests to run to reproduce what
 Carl reports
 }}}

 ''(reported in the comments of #17275)''

 I'm just switching our codebase to 1.4c2 and have run into this issue in
 the test suites.

 To make sure it wasn't something I was doing, I did the following:

 {{{
 $ django-admin.py startproject blank
 $ cd blank/blank
 $ https://code.djangoproject.com/ticket/17940>
Django 
The Web framework for perfectionists with deadlines.

-- 
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] #17275: Fix RuntimeWarning in the Django test suite

[Django]

#17275: Fix RuntimeWarning in the Django test suite
-+-
 Reporter:  PaulM|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Testing framework|   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by slacy):

 * cc: slacy@… (added)


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

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

Re: [Django] #17275: Fix RuntimeWarning in the Django test suite

[Django]

#17275: Fix RuntimeWarning in the Django test suite
-+-
 Reporter:  PaulM|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Testing framework|   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 I'm just switching our codebase to 1.4c2 and have run into this issue in
 the test suites.

 To make sure it wasn't something I was doing, I did the following:

 {{{
 $ django-admin.py startproject blank
 $ cd blank/blank
 $ https://code.djangoproject.com/ticket/17275#comment:12>
Django 
The Web framework for perfectionists with deadlines.

-- 
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] #6378: Capture arbitrary output as a template variable

[Django]

#6378: Capture arbitrary output as a template variable
-+
 Reporter:  kcarnold |Owner:  carljm
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by carljm):

 Replying to [comment:16 aaugustin]:
 > The use case doesn't seem that compelling to me — the logic calculating
 "subject" /could/ be handled in the view.

 It could be, but it shouldn't be. Display logic in the view is ugly, just
 like business logic in a template. And HTML in strings in the view is even
 uglier.

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

-- 
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] #17304: trans_real AttributeError __file__

[Django]

#17304: trans_real AttributeError __file__
-+-
 Reporter:  rwmcfa1@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Uncategorized|  Version:  SVN
 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
-+-

Comment (by jag@…):

 To explain why the __init__.py isn't there, since that seems to be a point
 of confusion, there isn't a flaw with piston's packaging. When you use pip
 to install piston, because of its use of namespace packaging, pip actually
 ignores the {{{ __init__.py }}} in the package and uses an nspkg pth file
 to handle the namespacing:

 {{{
 $ pip install django-piston
 Downloading/unpacking django-piston
   Downloading django-piston-0.2.3.tar.gz
   Running setup.py egg_info for package django-piston
 Installing collected packages: django-piston
   Running setup.py install for django-piston
 Skipping installation of $VIRTUAL_ENV/lib/python2.6/site-
 packages/piston/__init__.py (namespace package)
 Installing $VIRTUAL_ENV/lib/python2.6/site-
 packages/django_piston-0.2.3-py2.6-nspkg.pth
 Successfully installed django-piston
 Cleaning up...

 }}}

 This does not happen when installing using other methods. But as a
 consequence, when you try to access {{{ __file__ }}} on the piston module,
 the attribute does not exist.

 As carljm said, the bug is that Django should *not* be relying upon
 __file__ being there for its i18n functions. I'll evaluate the backward-
 incompatible b0rkage that would happen by making piston not a namespaced
 package, but Django should also do its part to DTRT.

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

-- 
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] #6378: Capture arbitrary output as a template variable

[Django]

#6378: Capture arbitrary output as a template variable
-+
 Reporter:  kcarnold |Owner:  carljm
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 The use case doesn't seem that compelling to me — the logic calculating
 "subject" /could/ be handled in the view.

 That said, I don't have a strong opinion on this feature.

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

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

[Django]

#17304: trans_real AttributeError __file__
-+-
 Reporter:  rwmcfa1@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Uncategorized|  Version:  SVN
 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
-+-

Comment (by rwmcfa1@…):

 django's use of __file__ seemed to be relatively prevalent when i looked
 around (been a while now.) better error message would be fine as it would
 of saved me time digging and tracking down what was going on. downside
 would be that it would prevent the use of such packages when it doesn't
 need to make use of locale, template, static, ... i don't have any solid
 use cases that make me lean one way or another. it seemed like it would be
 some work to get to rework the various places relying on __file__.

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

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

[Django]

#17304: trans_real AttributeError __file__
-+-
 Reporter:  rwmcfa1@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Uncategorized|  Version:  SVN
 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 carljm):

 * status:  closed => reopened
 * resolution:  needsinfo =>
 * stage:  Unreviewed => Design decision needed


Comment:

 Technically, this is a bug in Django; Python modules are not required to
 have the `__file__` attribute, so we shouldn't assume it is present.

 Practically speaking, it's unclear how Django should handle an app that is
 itself a namespace package, given that that means the package could be
 spread across several different directories. Should Django look for
 "locale", "templates", "static" etc in all of those directories? Or just
 arbitrarily pick one? (e.g. `module.__path__[0]`)? Or just document the
 fact that apps cannot be namespace packages, and provide a clearer error
 message?

 I think I lean towards the latter option; I haven't seen any good use case
 for an app itself being a namespace package (as opposed to being a package
 _within_ a namespace package, which works fine), and I'm worried that
 allowing for that would open up a whole range of new problematic edge
 cases.

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

-- 
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] #6378: Capture arbitrary output as a template variable

[Django]

#6378: Capture arbitrary output as a template variable
-+
 Reporter:  kcarnold |Owner:  carljm
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

 * stage:  Design decision needed => Accepted


Comment:

 I've changed my opinion on this; I do think there are cases where the
 "capture" model is the appropriate one, and it ought to be built-in.
 Particularly in cases like the above example, where a non-trivial block of
 template should be repeated. Inheritance doesn't support this. Includes
 could be used, but impose a significant performance penalty, both for
 doing the include and because the repeated block has to be evaluated
 multiple times. Otherwise you're reduced to a custom template tag.

 Marking accepted, pending any argument from other core 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] #6390: File storage backend for Amazon S3

[Django]

#6390: File storage backend for Amazon S3
-+-
 Reporter:  Gulopine |Owner:  david
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  fs-rf-docs   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Be careful to capture natural smiles when you photograph people. Often
 people will put on an obviously fake smile when they know you are trying
 to get a photo. Assure that their face is relaxed, that the smile is not
 forced, and the eyes reflect genuine emotion. Take several shots until it
 is right.   Amazon Coupon http://www.shoppingathome.net/

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

-- 
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] #6378: Capture arbitrary output as a template variable

[Django]

#6378: Capture arbitrary output as a template variable
-+-
 Reporter:  kcarnold |Owner:  carljm
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by anonymous):

 * owner:  nobody => carljm
 * status:  reopened => new


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

-- 
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] #6378: Capture arbitrary output as a template variable

[Django]

#6378: Capture arbitrary output as a template variable
-+-
 Reporter:  kcarnold |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by anonymous):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17899: EmailField invalid error message uses e-mail versus email

[Django]

#17899: EmailField invalid error message uses e-mail versus email
---+
 Reporter:  brosner|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+
Changes (by claudep):

 * needs_better_patch:  0 => 1


Comment:

 There are several other occurrences of [Ee]-mail elsewhere in the code. We
 should fix all of them in one shot. (If in a git checkout, use: {{{git
 grep -i -I "e-mail"|grep -v "django.po"}}})

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

-- 
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] #6378: Capture arbitrary output as a template variable

[Django]

#6378: Capture arbitrary output as a template variable
-+-
 Reporter:  kcarnold |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-

Comment (by anonymous):

 Does this justify as a general use-case?

 {{{
 {% capture as subject %}
 {% if user = request.user %}My{% else %}{{ user.first_name }}'s{%
 endif %}
 {% endcapture %}
 ...
 
 My Photo
 
 
 ...
 
 {{ subjects }} Friends
 List of friends...
 
 
 {{ subjects }} Groups
 List of groups...
 
 
 {{ subjects }} Friends
 List of friends...
 
 ...

 }}}

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

-- 
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] #11803: Admin does not update every ForeignKey select of the same model

[Django]

#11803: Admin does not update every ForeignKey select of the same model
-+-
 Reporter:  danilo   |Owner:  nobody
   |   Status:  new
 Type:  Bug  |  Version:  1.1
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  admin select |  Needs documentation:  0
  foreignkey |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by googol):

 I'd like to vote for this feature as it is crucial for our projects.
 Without it customers have to edit the entities first (City) they will
 refer to in other models (Person) which is very bad from a usability point
 of view!

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

-- 
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] #9071: Can't disable "add" popup links in the admin

[Django]

#9071: Can't disable "add" popup links in the admin
---+
 Reporter:  jacob  |Owner:  burzak
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.0
 Severity:  Normal |   Resolution:
 Keywords:  pyconuk| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+

Comment (by atkinsonr@…):

 At present this isn't possible in an InlineModelAdmin, however the patch
 in #17547 looks good as it is to BaseModelAdmin.

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

-- 
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] #17939: Staticfiles overwriting files incorrectly

[Django]

#17939: Staticfiles overwriting files incorrectly
-+-
 Reporter:  marc.tamlyn@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   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
-+-

Comment (by marc.tamlyn@…):

 That's good to know, thanks.

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

-- 
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] #17939: Staticfiles overwriting files incorrectly

[Django]

#17939: Staticfiles overwriting files incorrectly
-+-
 Reporter:  marc.tamlyn@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   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
-+-

Comment (by jezdez):

 FTR, it'll be fixed in an upcoming 1.3.2, too.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17939: Staticfiles overwriting files incorrectly

[Django]

#17939: Staticfiles overwriting files incorrectly
-+-
 Reporter:  marc.tamlyn@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   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 marc.tamlyn@…):

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


Comment:

 Running 1.3.1 at the moment. Looks like it is a duplicate, I was failing
 to find the relevant ticket sorry. Tried it on the trunk version and it
 works fine. Looking forward to 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] #17937: django.utils.timezone methods doesn't work with datetime.date objects

[Django]

#17937: django.utils.timezone methods doesn't work with datetime.date objects
-+-
 Reporter:   |Owner:  dreamiurg
  dmitry.guyvoronsky@…   |   Status:  assigned
 Type:  Bug  |  Version:
Component:  Template system  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by dreamiurg):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17937: django.utils.timezone methods doesn't work with datetime.date objects

[Django]

#17937: django.utils.timezone methods doesn't work with datetime.date objects
-+-
 Reporter:   |Owner:  dreamiurg
  dmitry.guyvoronsky@…   |   Status:  assigned
 Type:  Bug  |  Version:
Component:  Template system  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by dreamiurg):

 * owner:  aaugustin => dreamiurg
 * status:  new => assigned


Comment:

 Replying to [comment:4 aaugustin]:
 > Thanks for the patch. Unfortunately, I think it puts the check in the
 wrong layer -- `is_aware` and `is_naive` are only intended to receive
 `datetime` objects (or subclasses, or API-compatible classes).
 >
 > The check should be in `timesince` instead.
 >
 > The same bug probably exists in `timeuntil` and possibly in other
 filters.

 Please see second version of the patch, this one fixes problem on
 timeuntil() level + adds unittests.

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

-- 
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] #17939: Staticfiles overwriting files incorrectly

[Django]

#17939: Staticfiles overwriting files incorrectly
-+-
 Reporter:  marc.tamlyn@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  SVN
 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 jezdez):

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


Comment:

 Which version of Django are you using?

 I suspect this is a duplicate of #17737 which has been fixed in r17612
 (and r17613).

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

-- 
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] #17737: collectstatic copies wrong files to STATIC_ROOT

[Django]

#17737: collectstatic copies wrong files to STATIC_ROOT
-+
 Reporter:  pigletto |Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by jezdez):

 Yeah, I'll backport the change asap to the django-staticfiles apps.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17939: Staticfiles overwriting files incorrectly

[Django]

#17939: Staticfiles overwriting files incorrectly
-+
 Reporter:  marc.tamlyn@…|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.staticfiles  |Version:  SVN
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I believe there's an issue with the way {{{collectstatic}}} operates when
 the collected folder is not empty.

 Suppose I've got files like this:

 {{{
 my_first_app/static/base.css
 my_second_app/static/base.css
 }}}

 And {{{INSTALLED_APPS}}} places {{{my_first_app}}} above
 {{{my_second_app}}}, then {{{findstatic --first}}} will tell me that the
 file in {{{my_first_app}}} will be used. However if I run the following
 sequence, it gets overwritten with the file from {{{my_second_app}}}.

 {{{
 manage.py collectstatic
 touch my_second_app/static/base.css
 manage.py collectstatic
 }}}

 {{{collectstatic}}} seems to pick up the changed timestamp but ignores the
 fact that file should be overwritten. For the moment we've had to patch
 our deploy so that it deletes the collected static each time.

 It seems to me that this is not expected behaviour. I've not written an
 automated test case for it as yet but can try to if this is indeed broken.

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

-- 
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] #17899: EmailField invalid error message uses e-mail versus email

[Django]

#17899: EmailField invalid error message uses e-mail versus email
---+
 Reporter:  brosner|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.3
 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 Fandekasp):

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

Re: [Django] #17936: SimpleListFilter redirects to ?e=1

[Django]

#17936: SimpleListFilter redirects to ?e=1
-+--
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.4-beta-1
 Severity:  Release blocker  |   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 julien):

 * severity:  Normal => Release blocker


Comment:

 Thank you for providing this code sample.

 I confirm that something seems quite wrong here; either in the admin
 documentation, or in the ORM. I would have imagined that
 "`birthday__year__gte=1960`" would be a valid lookup, but maybe that isn't
 supported by the ORM; if it isn't supported, then the admin documentation
 sample should be fixed. If it should be supported then this would be a bug
 in the ORM. I thought this might have been a regression introduced by
 [17450], but reverting the change from that commit doesn't make this code
 sample work either.

 It's late and my brain is a little fried. As a cautionary measure, I'm
 marking this ticket as release blocker until we dig out the real nature of
 this potential bug.

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

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