Re: [Django] #19274: Separate DB connection creation and session state initialization

[Django]

#19274: Separate DB connection creation and session state initialization
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 I have update the patch series at
 https://github.com/akaariai/django/compare/ticket_19274

 Gis isn't yet updated, though it seems the only change needed is in
 spatialite. In addition I would like to remove some checks done against
 the ENGINE string, this isn't nice for subclassers.

 The full test suite does pass using
 https://github.com/akaariai/django_pooled/. The implementation in
 django_pooled isn't meant for any kind of production use, but it does
 prove that creating a connection pool outside core is possible.

 I am planning to push the patch series as-is. The changes are mostly
 mechanical - moving code from ._cursor() to the new methods. Still, it
 would be great if somebody had the time to double-check my changes, I am
 pretty good at making stupid little mistakes in this sort of thing...

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19368: Custom User without username and with USERNAME_FIELD = 'email', but still see username error message at the admin login page

[Django]

#19368: Custom User without username and with USERNAME_FIELD = 'email', but 
still
see username error message at the admin login page
-+-
 Reporter:  un33k|  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  1.5-alpha-1
Component:  contrib.admin|   Keywords:  custom user,
 Severity:  Normal   |  USERNAME_FIELD, username
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  1
-+-
 Have a custom user with no username and have set USERNAME_FIELD = 'email'.
 All works great, however, the error messages are still pointing to the
 username even though the custom user had no username field.

 Here is where the error message comes from.
 ERROR_MESSAGE = ugettext_lazy("Please enter the correct username and
 password "
 "for a staff account. Note that both fields are case-sensitive.")

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #2492: Part II of the tutorial fails to load the admin site using SVN Rev. 3528

[Django]

#2492: Part II of the tutorial fails to load the admin site using SVN Rev. 3528
---+--
 Reporter:  jcruff@…   |Owner:  adrian
 Type:  defect |   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  major  |   Resolution:  worksforme
 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 anonymous):

 I had the same error. It was fixed when I added sudo:  'sudo python
 manage.py runserver'

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19365: Create a `NonNegativeIntegerField` alias for `PositiveIntegerField`

[Django]

#19365: Create a `NonNegativeIntegerField` alias for `PositiveIntegerField`
-+-
 Reporter:  Alex |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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:  1|
-+-

Comment (by charettes):

 What about naming the alias [https://en.wikipedia.org/wiki/Signedness
 UnsignedIntegerField].

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19366: GEOSIndexError when comparing geometries

[Django]

#19366: GEOSIndexError when comparing geometries
-+--
 Reporter:  cdestigter   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Release blocker  |   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 cdestigter):

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


Comment:

 simple fix:
 
https://github.com/koordinates/django/commit/751ebb7132de7d50a47114677892a3848de271b6

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19362: Recursion error when deleting model object through admin

[Django]

#19362: Recursion error when deleting model object through admin
---+---
 Reporter:  m3wolf |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.5-alpha-1
 Severity:  Normal |   Resolution:
 Keywords:  python2.7.3| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---

Comment (by m3wolf):

 Thanks, aaugustine. Applied your patch and it correctly identified the
 offending model. Defined `__str__` for that model and I can now delete the
 instance.

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

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

[Django] #19367: ContentFile fails to save with filesystem storage when initialized with unicode string

[Django]

#19367: ContentFile fails to save with filesystem storage when initialized with
unicode string
--+
 Reporter:  void  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  File uploads/storage  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Attached test fails for me on python 2.7 with the following traceback:

 {{{
 Traceback (most recent call last):
   File "/Users/voidus/Documents/workspace/django-
 trunk/tests/regressiontests/file_storage/tests.py", line 590, in
 test_content_saving
 self.storage.save('unicode.txt', ContentFile("español"))
   File "/Users/voidus/Documents/workspace/django-
 trunk/django/core/files/storage.py", line 48, in save
 name = self._save(name, content)
   File "/Users/voidus/Documents/workspace/django-
 trunk/django/core/files/storage.py", line 206, in _save
 _file.write(chunk)
 UnicodeEncodeError: 'ascii' codec can't encode character u'\xf1' in
 position 4: ordinal not in range(128)

 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19366: GEOSIndexError when comparing geometries

[Django]

#19366: GEOSIndexError when comparing geometries
-+
 Reporter:  cdestigter   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  GIS  |Version:  master
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 In 1.5 (latest master) I get the following when comparing geometries of
 different lengths:

 {{{
 from django.contrib.gis.geos import *
 a = Polygon(((0, 0), (0, 1), (1, 1), (1, 0), (0, 0)))
 b = Polygon(((0, 0), (0, 1), (1, 0), (0, 0)))

 a < b

 Traceback (most recent call last):
   File "", line 6, in 
   File
 "/home/cdestigter/checkout/django/django/contrib/gis/geos/mutable_list.py",
 line 164, in __lt__
 c = self[i] < other[i]
   File
 "/home/cdestigter/checkout/django/django/contrib/gis/geos/mutable_list.py",
 line 164, in __lt__
 c = self[i] < other[i]
   File
 "/home/cdestigter/checkout/django/django/contrib/gis/geos/mutable_list.py",
 line 80, in __getitem__
 index = self._checkindex(index)
   File
 "/home/cdestigter/checkout/django/django/contrib/gis/geos/mutable_list.py",
 line 245, in _checkindex
 raise self._IndexError('invalid index: %s' % str(index))
 django.contrib.gis.geos.error.GEOSIndexError: 'invalid index: 4'

 }}}

 This does not occur on django 1.4.x.

 `git bisect` tracks it down to this commit:
 
https://github.com/django/django/commit/d04f72fb31bab43386e12963c1c6dec23ae16143
 ("Got rid of old __cmp__methods replaced by rich comparison.")

 python 2.6.5, GEOS 3.3.3-CAPI-1.7.4

 marking as release blocker since it's a regression 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19362: Recursion error when deleting model object through admin

[Django]

#19362: Recursion error when deleting model object through admin
---+---
 Reporter:  m3wolf |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.5-alpha-1
 Severity:  Normal |   Resolution:
 Keywords:  python2.7.3| 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):

 Here's what happens when a subclass of `models.Model` that doesn't define
 `__str__` is decorated with `python_2_unicode_compatible`:
 - when the decorator is executed:
   - its `__unicode__` method points to the `__str__` method from
 `models.Model` — which returns a `str` and not a `unicode` as expected by
 `python_2_unicode_compatible`
   - its `__str__` method is a new method that calls `__unicode__` and
 returns the result encoded as utf-8
 - when attempting to create the unicode representation of an instance,
 say, `obj`:
   - the interpreter treats `unicode(obj)` as `type(obj).__unicode__(obj)`
   - in this case, that's actually `models.Model.__str__(obj)`
   - this function calls `force_text(obj)`, which calls`obj.__unicode__()`
 — and that's also `models.Model.__str__(obj)`, hence the infinite
 recursion.

 

 I wish I could just remove the definition of `models.Model.__str__`, but
 after having spent years educating developers to write a `__unicode__`
 method for their models, this isn't a viable option.

 It's possible to catch this programming mistake and raise an explicit
 exception at runtime like this:
 {{{
 --- a/django/db/models/base.py
 +++ b/django/db/models/base.py
 @@ -416,6 +416,11 @@ class Model(six.with_metaclass(ModelBase, object)):

  def __str__(self):
  if not six.PY3 and hasattr(self, '__unicode__'):
 +if type(self).__unicode__ == Model.__str__:
 +klass_name = type(self).__name__
 +raise RuntimeError("%s.__unicode__ is aliased to __str__.
 Did"
 +   " you apply
 @python_2_unicode_compatible"
 +   " without defining __str__?" %
 klass_name)
  return force_text(self).encode('utf-8')
  return '%s object' % self.__class__.__name__

 }}}

 That ugly, but it works... It's more difficult to catch the exception at
 compile time because `python_2_unicode_compatible` is defined in
 `django.utils.encoding`, and I don't want to import
 `django.db.models.Model` there.

 

 m3wolf, I have an explanation for why you can delete one instance and not
 another of the same model.

 You probably have a foreign key pointing from an instance of another model
 to the instance you can't delete, and that other model has
 `@python_2_unicode_compatible` but no `__str__` method. When Django tries
 to display that instance to warn you about the cascade deletion, it enters
 the infinite loop.

 If you apply the patch above, Django should tell you which model has this
 issue. Could you test that and report your results 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 https://groups.google.com/groups/opt_out.

[Django] #19365: Create a `NonNegativeIntegerField` alias for `PositiveIntegerField`

[Django]

#19365: Create a `NonNegativeIntegerField` alias for `PositiveIntegerField`
-+-
   Reporter:  Alex   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.4
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 The current name is totally bogus, we should at least have an alias that's
 correct.

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

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

Re: [Django] #19362: Recursion error when deleting model object through admin

[Django]

#19362: Recursion error when deleting model object through admin
---+---
 Reporter:  m3wolf |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.5-alpha-1
 Severity:  Normal |   Resolution:
 Keywords:  python2.7.3| 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):

 Indeed, replacing `force_text(self)` with `self.__unicode__()` makes the
 recursion go away. But replacing it with `unicode(self)`
 (or`type(self).__unicode__(self)`, which is how the interpreter computes
 `unicode(self)`) brings it back.

 In the situation explained just above, it seems that Django will run the
 tests from the stale `.pyc` in `modeltests`, but the `Article` model from
 `regressiontests` is also loaded in the app cache, and that causes
 problems.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19362: Recursion error when deleting model object through admin

[Django]

#19362: Recursion error when deleting model object through admin
---+---
 Reporter:  m3wolf |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.5-alpha-1
 Severity:  Normal |   Resolution:
 Keywords:  python2.7.3| 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):

 Anssi first encountered the problem by checking out stable/1.4.x, running
 the pagination tests, checking out master, and running the pagination
 tests again.

 (The pagination tests were moved from `modeltests` to `regressiontests`;
 the sequence above leaves stale `.pyc` files in `modeltests/pagination`.)

 At least, that gives us a reproducible way to trigger this infinite
 recursion.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19363: Admin pages no longer validate as XHTML

[Django]

#19363: Admin pages no longer validate as XHTML
---+---
 Reporter:  gcc|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.5-alpha-1
 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 aaugustin):

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


Comment:

 Indeed, best practices for web development have evolved since #544 was
 fixed 7 years ago, and the admin templates
 [https://docs.djangoproject.com/en/dev/releases/1.4/#html5-doctype were
 changed to HTML5 in Django 1.4] (not in 1.5). They aren't intended to
 validate as XHTML any longer.

 Since they used to be valid XHTML, they still mostly are, but that will be
 less and less true as HTML5 code that isn't valid XHTML, such as single
 unclosed tags, is introduced by new commits. Allowing to override just the
 doctype won't help in the long term. It would set false expectations.

 To sum up, XHTML validity isn't guaranteed by Django any longer. If you
 need it, you should maintain your own templates.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19364: Wrong exception raised at django/db/models/fields/related.py:343? (DoesNotExist instead of AttributeError)

[Django]

#19364: Wrong exception raised at django/db/models/fields/related.py:343?
(DoesNotExist instead of AttributeError)
-+-
 Reporter:  lbragues@…   |Owner:  lbragues
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  DoesNotExist,|  Unreviewed
  django.db, getattr,|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by lbragues@…):

 * owner:  nobody => lbragues
 * needs_docs:   => 0
 * 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 https://groups.google.com/groups/opt_out.

[Django] #19364: Wrong exception raised at django/db/models/fields/related.py:343? (DoesNotExist instead of AttributeError)

[Django]

#19364: Wrong exception raised at django/db/models/fields/related.py:343?
(DoesNotExist instead of AttributeError)
-+-
 Reporter:  lbragues@…   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.4
  (models, ORM)  |   Keywords:  DoesNotExist,
 Severity:  Normal   |  django.db, getattr,
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+-
 My problem is at the admin models when calling a getattr from the
 save_module function using the object being saved, instead of returning
 the default value it raises a DoesNotExist exception, failing the python
 manual specification for getattr.
 I'm wondering if the exception thrown shouldn't be AttributeError instead
 of DoesNotExist...
 If I make a getattr call to that object and that exception is thrown my
 program will exit instead of being catched by the getattr method and the
 default value returned.

 '''Reproducing:'''
 ''models.py''
 {{{
 class GroupProperty(models.Model):
 CHOICES = (
 ('disk_quota','Disk Quota'),
 ('n_backups','Number of Backups'),
 )
 group = models.ForeignKey(Group)
 key = models.CharField(max_length=200,choices=CHOICES)
 value = models.CharField(max_length=200)
 start = models.DateTimeField()
 end = models.DateTimeField()
 description = models.TextField()
 author = models.ForeignKey(User)
 edit = models.DateTimeField(default=datetime.now())
 creation = models.DateTimeField(default=datetime.now())

 # na alteracao actualiza data
 def save(self):
 self.edit = datetime.now()
 super(GroupProperty, self).save()

 class Meta:
 verbose_name_plural = "Group Properties"
 }}}

 ''admin.py''
 {{{
 class GroupPropertyAdmin(admin.ModelAdmin):
 fieldsets = [
 (None,   {'fields':
 ['group','key','value','start','end',"description"]}),
 ('Auto generated fields',
 {'fields':['author','edit','creation']})
 ]
 list_display = ('group', 'key','value','start','end')
 readonly_fields = ('edit','author','creation')
 list_filter = ['key','group']
 search_fields = ['key','value','group','description']
 ordering = ('-creation',)

 def save_model(self, request, obj, form, change):
 #Error here
 if getattr(obj, 'author', 'None') is 'None':
 obj.author = request.user
 obj.save()

 admin.site.register(GroupProperty, GroupPropertyAdmin)
 }}}

 '''Django stacktrace:'''

 {{{
 Environment:


 Request Method: POST
 Request URL: http://localhost:8080/admin/core/groupproperty/add/

 Django Version: 1.4.2
 Python Version: 2.7.3
 Installed Applications:
 ('django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'django.contrib.messages',
  'django.contrib.staticfiles',
  'django.contrib.admin',
  '*.core')
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware')


 Traceback:
 File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4.2-py2.7.egg/django/core/handlers/base.py" in
 get_response
   111. response = callback(request,
 *callback_args, **callback_kwargs)
 File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4.2-py2.7.egg/django/contrib/admin/options.py" in
 wrapper
   366. return self.admin_site.admin_view(view)(*args,
 **kwargs)
 File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4.2-py2.7.egg/django/utils/decorators.py" in
 _wrapped_view
   91. response = view_func(request, *args, **kwargs)
 File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4.2-py2.7.egg/django/views/decorators/cache.py" in
 _wrapped_view_func
   89. response = view_func(request, *args, **kwargs)
 File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4.2-py2.7.egg/django/contrib/admin/sites.py" in inner
   196. return view(request, *args, **kwargs)
 File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4.2-py2.7.egg/django/utils/decorators.py" in _wrapper
   25. return bound_func(*args, **kwargs)
 File "/usr/local/lib/python2.7/dist-
 packages/Django-1.4.2-py2.7.egg/django/utils/decorators.py" in
 _wrapped_view
   91. response = view_func(request, *args, **kwargs)
 File "/usr/local/lib/pyth

Re: [Django] #19076: TemplateView does not support setting mime type, like views.generic.simple.direct_to_template did

[Django]

#19076: TemplateView does not support setting mime type, like
views.generic.simple.direct_to_template did
---+
 Reporter:  gwahl@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Gavin Wahl ):

 I added docs to the pull 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 https://groups.google.com/groups/opt_out.

Re: [Django] #15861: No way to reset a file in Admin section

[Django]

#15861: No way to reset a file in Admin section
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.2
Component:  contrib.admin|   Resolution:  fixed
 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 anonymous):

 * ui_ux:   => 0
 * easy:   => 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 https://groups.google.com/groups/opt_out.

[Django] #19363: Admin pages no longer validate as XHTML

[Django]

#19363: Admin pages no longer validate as XHTML
---+-
 Reporter:  gcc|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5-alpha-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 The Admin pages used to validate as XHTML, and it seems that that was
 intended, as the validation failure pointed out in #544 was fixed.

 However it is now broken again, because the doctype in the header has
 changed from:

 {{{
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
 }}}

 to just:

 {{{
 
 }}}

 which does not declare any entities, and therefore validation fails when
 it encounters › entities in the breadcrumbs in `admin/base.html`:

 {{{
 
 Home
 › Users
 › ISchool Users
 › john
 
 }}}

 I'd be OK with a more relaxed doctype, but if that's the intention, please
 can you at least wrap it in a block so that we can override it without
 copying and pasting the whole of `admin/base.html` just to change one
 line?

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19362: Recursion error when deleting model object through admin

[Django]

#19362: Recursion error when deleting model object through admin
---+---
 Reporter:  m3wolf |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.5-alpha-1
 Severity:  Normal |   Resolution:
 Keywords:  python2.7.3| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by akaariai):

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


Comment:

 I was able to reproduce similar stack trace with:
 {{{
 from django.db import models
 from django.utils.encoding import python_2_unicode_compatible
 @python_2_unicode_compatible
 class Foof(models.Model):
 def __unicode__(self):
 return unicode(self.id)
 repr(Foof())
 }}}
 I don't get a similar stack trace if I define `__str__` instead of
 `__unicode__` or if I don't have python_2_unicode_compatible.

 I have also seen the same stack trace somewhere else, don't remember where
 and why.

 There seems to be something strange going on. In the following code
 {{{
 def __str__(self):
 if not six.PY3 and hasattr(self, '__unicode__'):
 return force_text(self).encode('utf-8')

 }}}
 if I replace the force_text(self) with `self.__unicode__()` then the
 recursion goes away. But to me it seems calling the `__unicode__` method
 is the only thing that force_text is actually doing (apart of a couple of
 isinstance checks).

 In any case it seems the `__unicode__` + force_text() form an endless loop
 in some cases. I am marking this as accepted as it seems likely there is
 something strange going on in here. Although it is possible this is some
 kind of user error after all.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19362: Recursion error when deleting model object through admin

[Django]

#19362: Recursion error when deleting model object through admin
---+-
 Reporter:  m3wolf |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.5-alpha-1
 Severity:  Normal |   Keywords:  python2.7.3
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 When I try to delete a specific object using the admin interface I get an
 error:
 {{{
 RuntimeError at /admin/gtd/node/1470/delete/
 maximum recursion depth exceeded while calling a Python object
 }}}
 It appears to be trying to convert something to unicode but I don't know
 what. From the Django error message I can see that the object appears as
 {{{DFRD] Test todo item>}}}, which doesn't seem
 to have any weird characters in it. The title is what I expect to be
 return from `__str__(self)` as described below.

 If I delete a different object (which has similar HTML markup in it) from
 the same model it works with no errors. The model in question defines
 `__str__(self)` which returns the value from a models.TextField()
 attribute wrapped in some HTML () which is passed
 through mark_safe() before being returned. The model is decorated with
 `@python_2_unicode_compatible`. Following the python3 migration guide, I
 added `from __future__ import unicode_literals` at the top of my models.py
 and removed `__unicode__(self)` but no difference.

 The stacktrace doesn't seem to go through my code anywhere.

 I git-pulled the latest changes to stable/1.5.x from github and
 reinstalled Django after removed the previous installation from dist-
 packages but the problem persists.

 I have not tried deleting this object pythonically; I figured I'd keep
 that object for now in case anyone needs me to reproduce the problem.

 Stacktrace: https://gist.github.com/4148524

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #9207: Failing test code when using contenttypes app.

[Django]

#9207: Failing test code when using contenttypes app.
--+
 Reporter:  oliverandrich |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.contenttypes  |  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
--+

Comment (by akaariai):

 Hmmh. As an idea: would it be possible to call the permission creation
 from contenttype creation? You can't sync the permissions if contenttypes
 aren't installed.

 Another solution is to turn off foreign key checks before the signals,
 then validate the db state afterwards. But this is likely going to be
 somewhat expensive to do...

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19361: Link to object in message after creating/updating object in django admin

[Django]

#19361: Link to object in message after creating/updating object in django admin
-+-
 Reporter:  anonymous|Owner:  bak1an
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, messages, | Triage Stage:  Accepted
  update_object, create_object   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bak1an):

 * version:  1.5-alpha-1 => master


-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19361: Link to object in message after creating/updating object in django admin

[Django]

#19361: Link to object in message after creating/updating object in django admin
-+-
 Reporter:  anonymous|Owner:  bak1an
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:
 Severity:  Normal   |  1.5-alpha-1
 Keywords:  admin, messages, |   Resolution:
  update_object, create_object   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bak1an):

 * owner:  nobody => bak1an
 * status:  new => assigned
 * stage:  Unreviewed => Accepted


Comment:

 this will be usable

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #9207: Failing test code when using contenttypes app.

[Django]

#9207: Failing test code when using contenttypes app.
--+
 Reporter:  oliverandrich |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.contenttypes  |  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
--+

Comment (by nicpottier@…):

 I ran into this as well against Django 1.4.2 and MySQL using InnoDB.  It
 seems very specific to machines.

 I tracked it down a bit and the error for me is the same as in Comment 13,
 it is failing when trying to create the permissions for Auth because the
 content type for User wasn't yet created.  This only occurs when running
 unit tests, and only against InnoDB.

 Changing the order of content_type and auth in INSTALLED_APPS did fix the
 problem.  The error itself does make sense, in that Signals aren't
 guaranteed to happen in order, and both Auth and ContentType are using
 them to do their work after models are synced.  It seems like the
 workaround is not guaranteed to be reliable since there is no contract on
 signal call order.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19360: annotate the sum of related TimeField

[Django]

#19360: annotate the sum of related TimeField
-+-
 Reporter:  lsaffre  |Owner:
 Type:  Bug  |  chrismedrela
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  master
 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 chrismedrela):

 * owner:  nobody => chrismedrela


Comment:

 The problem is that `django.utils.dateparse.parse_time` function is called
 with float argument instead of string. Then the argument is passed on to
 `re_pattern.match` 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19360: annotate the sum of related TimeField

[Django]

#19360: annotate the sum of related TimeField
-+-
 Reporter:  lsaffre  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 chrismedrela):

 * cc: chrismedrela (added)
 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * version:  1.4 => master
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * 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 https://groups.google.com/groups/opt_out.

Re: [Django] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+

Comment (by akaariai):

 I added some comments to the compare view.

 For the committer of this: I am not sure if the check that the return url
 must start with '/' is the right one - so this check should be verified.
 (Not saying it is the wrong one either - just want to make sure this will
 be double checked).

 I don't think I am the right committer for this, there are committers who
 know this area of Django way better than 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19349: admin/auth/user throws TypeError on save with invalid email address

[Django]

#19349: admin/auth/user throws TypeError on save with invalid email address
-+-
 Reporter:  tim.bowden@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:
 Severity:  Normal   |  1.5-alpha-1
 Keywords:  user email   |   Resolution:
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by bak1an):

 * stage:  Accepted => Ready for checkin


Comment:

 it's ready

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+

Comment (by revolunet):

 Adressed the two issues in a new path improvements.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19361: Link to object in message after creating/updating object in django admin

[Django]

#19361: Link to object in message after creating/updating object in django admin
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:
 Severity:  Normal   |  1.5-alpha-1
 Keywords:  admin, messages, |   Resolution:
  update_object, create_object   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by BozeWolf):

 * cc: BozeWolf (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I forgot to login when posting this ticket. But i'm the owner. I added
 myself to Cc.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19361: Link to object in message after creating/updating object in django admin

[Django]

#19361: Link to object in message after creating/updating object in django admin
-+-
 Reporter:   |  Owner:  nobody
  anonymous  | Status:  new
 Type:  New  |Version:  1.5-alpha-1
  feature|   Keywords:  admin, messages, update_object,
Component:   |  create_object
  contrib.admin  |  Has patch:  0
 Severity:  Normal   |  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 When you have a lot of objects listed in the admin, like items in a shop,
 it is hard to find the object after you created/updated it. Obviously
 there is an option "Save and continue editing" but in practice it happens
 that after saving users suddenly realize there are not finished yet.

 For example: If i clicked an item in app shop in the middle of the items
 list,  or in search results, I have to find it manually or by using the
 search-on-page in the browser after saving the object. This problem can
 easily be solved by adding a link in the message to the object, which
 appears on top of the page after creating/updating. The title is already
 in there, so it should not be that hard to resolve the url to the admin
 page.

 Example message: The item "Vintage Star Trek action figure" was changed
 successfully.
 New message: The item "__Vintage Star Trek action figure__" was changed
 successfully.


 Of course there are some cases, like when the change page ({{ app_label
 }}_{{ model_name }}_change) is not used or overriden or whatever the coder
 did to break the url structure and not using the correct names 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 https://groups.google.com/groups/opt_out.

Re: [Django] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
---+
 Reporter:  jarrow |Owner:
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+

Comment (by akaariai):

 Two comments:
   1. Is there possibility of malicious use of the RETURN_GET_PARAM, that
 is you could send a link of edit_something?_return_to=evil.com
   2. There is some repeating of this:
 {{{
 if RETURN_GET_PARAM in request.GET:
 url += '?%s=%s' % (RETURN_GET_PARAM,
 urlquote(request.GET.get(RETURN_GET_PARAM, '')))
 }}}
 seems like a little helper method could make this a little more DRY.

 This is just after quick skimming, no full review done.

-- 
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 https://groups.google.com/groups/opt_out.