Re: [Django] #15534: Oracle backend regex lookup broken if Oracle backend is not default

[Django]

#15534: Oracle backend regex lookup broken if Oracle backend is not default
-+-
   Reporter:  JirkaV |Owner:  nobody
 Status:  new|Milestone:
  Component:  Database   |  Version:  1.3-beta
  layer (models, ORM)| Keywords:  oracle, multi-db
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by ikelly):

 This point was also raised in #9405, which was closed wontfix at the time.
 This is something that we do need to fix one way or another, though.

-- 
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] #15537: allow the login_url accept a relative path

[Django]

#15537: allow the login_url accept a relative path
-+-
   Reporter:  lanyjie|Owner:  nobody
 Status:  closed |Milestone:
  Component: |  Version:  1.3-beta
  Authentication | Keywords:  relative path
 Resolution:  wontfix|  login_url
   Triage Stage: |Has patch:  1
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by russellm):

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


Comment:

 I'm not sure I agree that the proposed feature would be a good thing.
 Authentication shouldnt' be tightly coupled to application design, and the
 design your proposing would require either a tightly coupled design, or a
 large number of deployed login views. I'm not sure I want to encourage
 either of those practices.

 If you want to argue for this feature, please start a discussion on
 django-dev; my suggestion to you would be to try and explain why this sort
 of design is the right thing. i.e., provide a much better explanation of
 your use case.

-- 
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] #15546: Fields selected via extra() are omitted in ValuesQuerySet when fields are specified

[Django]

#15546: Fields selected via extra() are omitted in ValuesQuerySet when fields 
are
specified
-+-
   Reporter:  jnns   |Owner:  nobody
 Status:  closed |Milestone:
  Component:  Database   |  Version:  1.3-beta
  layer (models, ORM)| Keywords:  extra valuesqueryset
 Resolution:  invalid|Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by russellm):

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


Comment:

 Working as designed. You've explicitly specified the values you want to be
 returned; if you want the extra column to be returned, you need to include
 it in the values() clause.

-- 
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] #15547: Broken link on 1.2 "generic view" reference page

[Django]

#15547: Broken link on 1.2 "generic view" reference page
-+--
   Reporter:  anonymous  |Owner:  nobody
 Status:  new|Milestone:  1.3
  Component:  Documentation  |  Version:  1.2
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by russellm):

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


Comment:

 This only appears to affect the 1.2 docs; 1.3 docs have the right link.

-- 
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] #15551: adding model_dict['admin'] = model_admin is good idea?

[Django]

#15551: adding  model_dict['admin'] = model_admin  is good idea?
+--
   Reporter:  hdknr |Owner:  nobody
 Status:  closed|Milestone:
  Component:  django.contrib.admin  |  Version:  1.2
 Resolution:  invalid   | Keywords:
   Triage Stage:  Unreviewed|Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by lrekucki):

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


Comment:

 Please post questions about using Django to
 [http://groups.google.com/group/django-users django-users] mailing list.
 Trac is for reporting bugs.

-- 
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] #15551: adding model_dict['admin'] = model_admin is good idea?

[Django]

#15551: adding  model_dict['admin'] = model_admin  is good idea?
--+---
 Reporter:  hdknr | Owner:  nobody
   Status:  new   | Milestone:
Component:  django.contrib.admin  |   Version:  1.2
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 I'm customizing admin UI to add extra menus but I found it is not easy.
 So thinking of adding "admin" to model_dict in index() and app_index() (
 source:django/trunk/django/contrib/admin/sites.py ) to refere to ModeAdmin
 objects in templates.
 Is there any pitfall in the security 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] #13839: select_related caches None for non-existent objects in reverse one-to-one relations

[Django]

#13839: select_related caches None for non-existent objects in reverse 
one-to-one
relations
-+---
   Reporter:  shauncutts |Owner:
 Status:  new|Milestone:  1.3
  Component:  ORM aggregation|  Version:  1.2
 Resolution: | Keywords:
   Triage Stage:  Ready for checkin  |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+---
Changes (by anonymous):

 * stage:  Accepted => Ready for checkin


Comment:

 I have tested the attached patch and confirmed that it fixes the problem I
 have been encountering.

-- 
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] #15536: ModelForm validation regression in 1.2 when using TimeField with choices

[Django]

#15536: ModelForm validation regression in 1.2 when using TimeField with choices
+---
   Reporter:  3point2   |Owner:  nobody
 Status:  closed|Milestone:  1.3
  Component:  Forms |  Version:  1.2
 Resolution:  invalid   | Keywords:  blocker, regression
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---

Comment (by 3point2):

 It seems like setting the time to a valid string directly on the model
 works fine:

 {{{

 >>> t = TestModel()
 >>> t.time = "09:00:00"
 >>> t.save()
 >>>

 }}}

 This is what happens when I give an invalid time string:

 {{{

 >>> t.time = "09"
 >>> t.save()
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/vasili/.virtualenvs/testing/lib/python2.6/site-
 packages/django/db/models/base.py", line 431, in save
 self.save_base(force_insert=force_insert, force_update=force_update)
   File "/home/vasili/.virtualenvs/testing/lib/python2.6/site-
 packages/django/db/models/base.py", line 495, in save_base
 rows = manager.filter(pk=pk_val)._update(values)
   File "/home/vasili/.virtualenvs/testing/lib/python2.6/site-
 packages/django/db/models/query.py", line 446, in _update
 query.add_update_fields(values)
   File "/home/vasili/.virtualenvs/testing/lib/python2.6/site-
 packages/django/db/models/sql/subqueries.py", line 249, in
 add_update_fields
 val = field.get_db_prep_save(val)
   File "/home/vasili/.virtualenvs/testing/lib/python2.6/site-
 packages/django/db/models/fields/__init__.py", line 202, in
 get_db_prep_save
 return self.get_db_prep_value(value)
   File "/home/vasili/.virtualenvs/testing/lib/python2.6/site-
 packages/django/db/models/fields/__init__.py", line 920, in
 get_db_prep_value
 return connection.ops.value_to_db_time(self.to_python(value))
   File "/home/vasili/.virtualenvs/testing/lib/python2.6/site-
 packages/django/db/models/fields/__init__.py", line 908, in to_python
 _('Enter a valid time in HH:MM[:ss[.uu]] format.'))
 ValidationError: Enter a valid time in HH:MM[:ss[.uu]] format.

 }}}

-- 
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] #15536: ModelForm validation regression in 1.2 when using TimeField with choices

[Django]

#15536: ModelForm validation regression in 1.2 when using TimeField with choices
+---
   Reporter:  3point2   |Owner:  nobody
 Status:  closed|Milestone:  1.3
  Component:  Forms |  Version:  1.2
 Resolution:  invalid   | Keywords:  blocker, regression
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by russellm):

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


Comment:

 Apologies -- I mistyped in my explanation.

 No, "09:00:00" is not a valid value for a time. It's a valid *string* that
 can be converted into a Time value *on a form*, using the format you
 describe (which is, as you will note in the forms documentation). You're
 dealing with a Model. It's the model validation that is failing.

-- 
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] #15545: admin_filterspecs tests fail on PostgreSQL

[Django]

#15545: admin_filterspecs tests fail on PostgreSQL
-+-
   Reporter:  lrekucki   |Owner:  lrekucki
 Status:  new|Milestone:  1.3
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  postgresql blocker
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by lrekucki):

 * has_patch:  0 => 1


Comment:

 This and other failures result from false assumptions about primary keys
 and model ordering. This patch should make assertions db-independent.

-- 
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] #13917: Multiple popup window feature of related objects popup through id_to_windowname

[Django]

#13917: Multiple popup window feature of related objects popup through
id_to_windowname
--+--
   Reporter:  davidcooper |Owner:  nobody
 Status:  new |Milestone:
  Component:  django.contrib.admin|  Version:  1.2
 Resolution:  | Keywords:
   Triage Stage:  Design decision needed  |Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  1   |
--+--

Comment (by davidcooper):

 Sorry for ignoring this.  I can say that I have used it on my site for
 sometime now without problem.  I cannot imagine how any existing service
 would be impacted negatively, the change is pretty trivial and is
 isolated.

-- 
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] #15550: Some model form doctests fail on Postgresql

[Django]

#15550: Some model form doctests fail on Postgresql
+---
 Reporter:  bberes  | Owner:  nobody
   Status:  new | Milestone:  1.3
Component:  Forms   |   Version:  SVN
 Keywords:  postgresql blocker  |  Triage Stage:  Unreviewed
Has patch:  0   |
+---
 {{{
 ==
 FAIL: API_TESTS (modeltests.model_forms.models.__test__)
 Doctest: modeltests.model_forms.models.__test__.API_TESTS
 --
 Traceback (most recent call last):
   File "/home/botondus/Envs/django/lib/python2.6/site-
 packages/django/test/_doctest.py", line 2180, in runTest
 raise self.failureException(self.format_failure(new.getvalue()))
 AssertionError: Failed doctest test for
 modeltests.model_forms.models.__test__.API_TESTS
   File
 "/home/botondus/Envs/django/django/tests/modeltests/model_forms/models.py",
 line unknown line number, in API_TESTS

 --
 File
 "/home/botondus/Envs/django/django/tests/modeltests/model_forms/models.py",
 line ?, in modeltests.model_forms.models.__test__.API_TESTS
 Failed example:
 print f.as_ul()
 Expected:
 Headline: 
 Slug: 
 Pub date: 
 Writer: 
 -
 Mike Royko
 Bob Woodward
 Carl Bernstein
 
 Article: 
 Status: 
 -
 Draft
 Pending
 Live
 
 Categories: 
 Entertainment
 It's a test
 Third
 Fourth
   Hold down "Control", or "Command" on
 a Mac, to select more than one.
 Got:
 Headline: 
 Slug: 
 Pub date: 
 Writer: 
 -
 Mike Royko
 Carl Bernstein
 Bob Woodward
 
 Article: 
 Status: 
 -
 Draft
 Pending
 Live
 
 Categories: 
 Entertainment
 It's a test
 Third
 Fourth
   Hold down "Control", or "Command" on
 a Mac, to select more than one.
 --
 File
 "/home/botondus/Envs/django/django/tests/modeltests/model_forms/models.py",
 line ?, in modeltests.model_forms.models.__test__.API_TESTS
 Failed example:
 print form.as_p()
 Expected:
 Writer: 
 -
 Mike Royko
 Bob Woodward
 Carl Bernstein
 Joe Better
 
 Age: 
 Got:
 Writer: 
 -
 Mike Royko
 Carl Bernstein
 Bob Woodward
 Joe Better
 
 Age: 
 --
 File
 "/home/botondus/Envs/django/django/tests/modeltests/model_forms/models.py",
 line ?, in modeltests.model_forms.models.__test__.API_TESTS
 Failed example:
 print form.as_p()
 Expected:
 Writer: 
 -
 Mike Royko
 Bob Woodward
 Carl Bernstein
 Joe Better
 
 Age: 
 Got:
 Writer: 
 -
 Mike Royko
 Carl Bernstein
 Bob Woodward
 Joe Better
 
 Age: 
 --
 File
 "/home/botondus/Envs/django/django/tests/modeltests/model_forms/models.py",
 line ?, in modeltests.model_forms.models.__test__.API_TESTS
 Failed example:
 print form['parent']
 Expected:
 
 -
 Apple
 Pear
 Core
 
 Got:
 
 -
 Pear
 Apple
 Core
 


 }}}

-- 
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] #15549: Model formset regressions tests fail on Postgresql

[Django]

#15549: Model formset regressions tests fail on Postgresql
+---
 Reporter:  bberes  | Owner:  nobody
   Status:  new | Milestone:  1.3
Component:  Forms   |   Version:  SVN
 Keywords:  postgresql blocker  |  Triage Stage:  Unreviewed
Has patch:  0   |
+---
 {{{
 ==
 FAIL: test_custom_delete
 (regressiontests.model_formsets_regress.tests.FormfieldShouldDeleteFormTests)
 Verify DeleteFormset ignores DELETE field and uses form method
 --
 Traceback (most recent call last):
   File
 
"/home/botondus/Envs/django/django/tests/regressiontests/model_formsets_regress/tests.py",
 line 401, in test_custom_delete
 self.assertTrue(formset.is_valid())
 AssertionError: False is not True

 ==
 FAIL: test_no_delete
 (regressiontests.model_formsets_regress.tests.FormfieldShouldDeleteFormTests)
 Verify base formset doesn't modify database
 --
 Traceback (most recent call last):
   File
 
"/home/botondus/Envs/django/django/tests/regressiontests/model_formsets_regress/tests.py",
 line 370, in test_no_delete
 self.assertTrue(formset.is_valid())
 AssertionError: False is not True

 }}}

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

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

[Django] #15548: ModelAdmin regression test fails on Postgresql

[Django]

#15548: ModelAdmin regression test fails on Postgresql
--+---
 Reporter:  bberes| Owner:  nobody
   Status:  new   | Milestone:  1.3
Component:  django.contrib.admin  |   Version:  SVN
 Keywords:  postgresql blocker|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 {{{
 ==
 FAIL: test_queryset_override
 (regressiontests.modeladmin.tests.ModelAdminTests)
 --
 Traceback (most recent call last):
   File
 "/home/botondus/Envs/django/django/tests/regressiontests/modeladmin/tests.py",
 line 159, in test_queryset_override
 '' % (self.band.id, band2.id))
 AssertionError: '\n-\nThe
 Beatles\nThe Doors\n' !=
 '\n-\nThe
 Doors\nThe Beatles\n'
 }}}

-- 
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] #15545: admin_filterspecs tests fail on PostgreSQL

[Django]

#15545: admin_filterspecs tests fail on PostgreSQL
-+-
   Reporter:  lrekucki   |Owner:  lrekucki
 Status:  new|Milestone:  1.3
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  postgresql blocker
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by bberes):

 * needs_better_patch:   => 0
 * component:  Uncategorized => django.contrib.admin
 * needs_tests:   => 0
 * milestone:   => 1.3
 * keywords:  postgresql => postgresql blocker
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #15544: test_update_get_object (regressiontests.generic_views.edit.UpdateViewTests) fails on PostgreSQL

[Django]

#15544: test_update_get_object 
(regressiontests.generic_views.edit.UpdateViewTests)
fails on PostgreSQL
-+-
   Reporter:  lrekucki   |Owner:  nobody
 Status:  new|Milestone:  1.3
  Component:  Generic|  Version:  SVN
  views  | Keywords:  postgresql blocker
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by bberes):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Generic views
 * needs_tests:   => 0
 * milestone:   => 1.3
 * keywords:   => postgresql blocker
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


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

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

[Django] #15547: Broken link on 1.2 "generic view" reference page

[Django]

#15547: Broken link on 1.2 "generic view" reference page
---+---
 Reporter:  anonymous  | Owner:  nobody
   Status:  new| Milestone:
Component:  Documentation  |   Version:  1.2
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 http://docs.djangoproject.com/en/1.2/ref/generic-views/
 contains a broken link to the generic view topic guide: "A general
 introduction to generic views can be found in the topic guide." The link
 is to
  http://docs.djangoproject.com/en/1.2/topics/http/generic-views/
 but should presumably link to:
  http://docs.djangoproject.com/en/1.2/topics/generic-views/

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

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

Re: [Django] #15536: ModelForm validation regression in 1.2 when using TimeField with choices

[Django]

#15536: ModelForm validation regression in 1.2 when using TimeField with choices
+---
   Reporter:  3point2   |Owner:  nobody
 Status:  reopened  |Milestone:  1.3
  Component:  Forms |  Version:  1.2
 Resolution:| Keywords:  blocker, regression
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by 3point2):

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


Comment:

 I hope I'm not going to get on anyone's nerves by reopening this, but I
 think you misunderstood something: Of course "09:00:00" isn't a valid
 value for a Date. However, my example uses a '''Time'''Field, not a
 '''Date'''Field. As far as I can tell
 
(http://docs.djangoproject.com/en/1.2/ref/forms/fields/#django.forms.TimeField.input_formats),
 "09:00:00" '''is''' a valid value for a time. Thoughts?

-- 
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] #15522: delete_model on admin delete action

[Django]

#15522: delete_model on admin delete action
-+-
   Reporter:  Divad  |Owner:  nobody
 Status:  reopened   |Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  delete_model
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  1  |
Patch needs improvement:  1  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * needs_docs:  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] #15522: delete_model on admin delete action

[Django]

#15522: delete_model on admin delete action
-+-
   Reporter:  Divad  |Owner:  nobody
 Status:  reopened   |Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  delete_model
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the details. I can see the use of knowing which user has
 performed the bulk delete. However `delete_model(self, request, obj)`
 cannot be used since that method is for one specific object.

 As you mentioned, an easy workaround would be to define your own delete
 action, which you could then wrap around the built-in one.

 I agree that it would be nice to have an easier way of achieving that in
 core, so I'm marking as Accepted.

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

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

Re: [Django] #14175: Comment object's user_name field too short for User.get_full_name

[Django]

#14175: Comment object's user_name field too short for User.get_full_name
---+--
   Reporter:  gravm|Owner:  nobody
 Status:  new  |Milestone:
  Component:  django.contrib.comments  |  Version:  SVN
 Resolution:   | Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--

Comment (by julien):

 If we are to keep using the full name, then I think the best approach is
 to augment the character limit to 61 (see patch). However, this would be
 backwards incompatible...

-- 
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] #15546: Fields selected via extra() are omitted in ValuesQuerySet when fields are specified

[Django]

#15546: Fields selected via extra() are omitted in ValuesQuerySet when fields 
are
specified
--+---
 Reporter:  jnns  | Owner:  nobody
   Status:  new   | Milestone:
Component:  Database layer (models, ORM)  |   Version:  1.3-beta
 Keywords:  extra valuesqueryset  |  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 `Books.objects.values().extra(select={'price_per_page': 'price / page'})`
 works fine.

 `Books.objects.values('book_id').extra(select={'price_per_page': 'price /
 page'})` however, does not.

-- 
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] #15545: admin_filterspecs tests fail on PostgreSQL

[Django]

#15545: admin_filterspecs tests fail on PostgreSQL
---+---
 Reporter:  lrekucki   | Owner:  lrekucki
   Status:  new| Milestone:
Component:  Uncategorized  |   Version:  SVN
 Keywords:  postgresql |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 {{{

 ==
 FAIL: test_RelatedFilterSpec_ForeignKey
 (regressiontests.admin_filterspecs.tests.FilterSpecsTests)
 --
 Traceback (most recent call last):
   File "/home/lrekucki/django/django-
 gh/tests/regressiontests/admin_filterspecs/tests.py", line 85, in
 test_RelatedFilterSpec_ForeignKey
 self.assertEqual(choices[1]['selected'], True)
 AssertionError: False != True

 ==
 FAIL: test_RelatedFilterSpec_ManyToMany
 (regressiontests.admin_filterspecs.tests.FilterSpecsTests)
 --
 Traceback (most recent call last):
   File "/home/lrekucki/django/django-
 gh/tests/regressiontests/admin_filterspecs/tests.py", line 111, in
 test_RelatedFilterSpec_ManyToMany
 self.assertEqual(choices[2]['selected'], True)
 AssertionError: False != True

 ==
 FAIL: test_RelatedFilterSpec_reverse_relationships
 (regressiontests.admin_filterspecs.tests.FilterSpecsTests)
 --
 Traceback (most recent call last):
   File "/home/lrekucki/django/django-
 gh/tests/regressiontests/admin_filterspecs/tests.py", line 139, in
 test_RelatedFilterSpec_reverse_relationships
 self.assertEqual(choices[1]['selected'], True)
 AssertionError: False != True

 --
 }}}

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

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

[Django] #15544: test_update_get_object (regressiontests.generic_views.edit.UpdateViewTests) fails on PostgreSQL

[Django]

#15544: test_update_get_object 
(regressiontests.generic_views.edit.UpdateViewTests)
fails on PostgreSQL
---+---
 Reporter:  lrekucki   | Owner:  nobody
   Status:  new| Milestone:
Component:  Uncategorized  |   Version:  SVN
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 {{{

 Traceback (most recent call last):
   File "/home/lrekucki/django/django-
 gh/tests/regressiontests/generic_views/edit.py", line 209, in
 test_update_get_object
 res = self.client.get('/edit/author/update/')
   File "/home/lrekucki/django/django-gh/django/test/client.py", line 445,
 in get
 response = super(Client, self).get(path, data=data, **extra)
   File "/home/lrekucki/django/django-gh/django/test/client.py", line 229,
 in get
 return self.request(**r)
   File "/home/lrekucki/django/django-gh/django/core/handlers/base.py",
 line 111, in get_response
 response = callback(request, *callback_args, **callback_kwargs)
   File "/home/lrekucki/django/django-gh/django/views/generic/base.py",
 line 47, in view
 return self.dispatch(request, *args, **kwargs)
   File "/home/lrekucki/django/django-gh/django/views/generic/base.py",
 line 68, in dispatch
 return handler(request, *args, **kwargs)
   File "/home/lrekucki/django/django-gh/django/views/generic/edit.py",
 line 195, in get
 self.object = self.get_object()
   File "/home/lrekucki/django/django-
 gh/tests/regressiontests/generic_views/views.py", line 121, in get_object
 return Author.objects.get(pk=1)
   File "/home/lrekucki/django/django-gh/django/db/models/manager.py", line
 132, in get
 return self.get_query_set().get(*args, **kwargs)
   File "/home/lrekucki/django/django-gh/django/db/models/query.py", line
 348, in get
 raise self.model.DoesNotExist("%s matching query does not exist."
 DoesNotExist: Author matching query does not exist.
 }}}

-- 
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] #14646: django.contrib.comments is missing default template for comment_notification_email.txt, and has no documentation of template context

[Django]

#14646: django.contrib.comments is missing default template for
comment_notification_email.txt, and has no documentation of template
context
-+-
   Reporter:  tpherndon  |Owner:  tzulberti
 Status:  new|Milestone:
  Component: |  Version:  SVN
  django.contrib.comments| Keywords:  email, template
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by julien):

 * needs_tests:  0 => 1


Comment:

 The template needs to be localized and tests need to be 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] #12441: Delegate module permissions check to AdminSite

[Django]

#12441: Delegate module permissions check to AdminSite
+--
   Reporter:  alexkoshelev  |Owner:  nobody
 Status:  new   |Milestone:  1.3
  Component:  django.contrib.admin  |  Version:  1.1
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by alexkoshelev):

 * component:  Contrib apps => django.contrib.admin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14434: AdminSite should check self.has_permission in self.login

[Django]

#14434: AdminSite should check self.has_permission in self.login
-+-
   Reporter:  bkonkle|Owner:  nobody
 Status:  closed |Milestone:
  Component: |  Version:  1.2
  django.contrib.admin   | Keywords:  admin views
 Resolution:  fixed  |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 This has been fixed as a side effect of [14769].

-- 
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] #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
 Status:  reopened   |Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  admin inlines
 Resolution: |  hiddeninput
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by julien):

 #14372 was closed as dupe and contains a patch.

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

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

Re: [Django] #14372: Admin shouldn't render label tags on hidden fields

[Django]

#14372: Admin shouldn't render label tags on hidden fields
-+-
   Reporter:  Mnewman|Owner:  nobody
 Status:  closed |Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  admin hiddenfields
 Resolution:  duplicate  |  forms
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  1
Patch needs improvement:  1  |
-+-
Changes (by julien):

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


Comment:

 This is effectively a dupe of #11277.

-- 
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] #12241: Admin forgets URL used for prefilling forms when hitting Save and add another

[Django]

#12241: Admin forgets URL used for prefilling forms when hitting Save and add
another
+---
   Reporter:  velmont   |Owner:  batiste
 Status:  new   |Milestone:
  Component:  django.contrib.admin  |  Version:  SVN
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+---

Comment (by batiste):

 Merged latest Django with chris changes, fix tests, added documentation on
 the test that was missing, removed parse_qs

 
https://github.com/batiste/django/commit/af3285ca12604ddde1b7f2af65fed1f8634e340c
 
https://github.com/batiste/django/commit/90708a9b162d7c6c2f48afe8a32a7e5e42b91e54

 What else can I 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15518: Separate CSRF checks to function

[Django]

#15518: Separate CSRF checks to function
-+--
   Reporter:  vzima  |Owner:  nobody
 Status:  reopened   |Milestone:
  Component:  Documentation  |  Version:  1.2
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--

Comment (by lukeplant):

 An alternative way to do this is to split your view function into several
 views, or into a closures, and decorate with @csrf_protect:

 {{{
 #!python

 @csrf_view_exempt
 def some_view(request):

 # Any setup here, including vars that may be referenced in path_1 or
 path_2

 @requires_csrf_token
 def path_1(request):
 # ...

 @csrf_protect
 def path_2(request):
 # ...

 if (...some_condition...):
 return path_1(request)
 else:
 return path_2(request)
 }}}

 This seems like a reasonable solution to me, especially for something
 which is very definitely an edge case. If you have things that you need to
 do instead of immediately returning the 403 failure view, you can:

 * subclass `CsrfViewMiddleware`
 * override the `_reject` method
 * make your own version of `csrf_protect` using
 `decorator_from_middleware`.

 This suggests we should make `_reject` public by calling it `reject`.

-- 
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] #15543: SyntaxError in utils/http.py on Python 2.4

[Django]

#15543: SyntaxError in utils/http.py on Python 2.4
-+---
   Reporter:  anonymous  |Owner:  nobody
 Status:  new|Milestone:  1.3
  Component:  Uncategorized  |  Version:  SVN
 Resolution: | Keywords:  blocker
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+---
Changes (by ramiro):

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


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

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

[Django] #15543: SyntaxError in utils/http.py on Python 2.4

[Django]

#15543: SyntaxError in utils/http.py on Python 2.4
---+---
 Reporter:  anonymous  | Owner:  nobody
   Status:  new| Milestone:  1.3
Component:  Uncategorized  |   Version:  SVN
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 od_python error: "PythonHandler django.core.handlers.modpython"

 Traceback (most recent call last):

   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 287,
 in HandlerDispatch
 log=debug)

   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 464,
 in import_module
 module = imp.load_module(mname, f, p, d)

   File "/usr/lib/python2.4/site-
 packages/django/core/handlers/modpython.py", line 6, in ?
 from django import http

   File "/usr/lib/python2.4/site-packages/django/http/__init__.py", line
 122, in ?
 from django.utils.http import cookie_date

   File "/usr/lib/python2.4/site-packages/django/utils/http.py", line 108

 year += 2000 if year < 70 else 1900

   ^

 SyntaxError: invalid syntax

-- 
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] #15542: When postgres autocommit is set contenttype test cause sites tests failures

[Django]

#15542: When postgres autocommit is set contenttype test cause sites tests 
failures
--+---
 Reporter:  jasonculverhouse  | Owner:  nobody
   Status:  new   | Milestone:
Component:  Contrib apps  |   Version:  1.2
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 It seems that the contenttype framework and the sites contribs
 conflict with using the autocommit:True database option.  I'm not
 really sure what happens but here is a simple test case that shows
 that the order of the tests causes a failure.  It looks like from the
 SQL that the save point is being rolled back in a new transaction, not
 the transaction that the savepoint was created.

 If I create a new django tests site
 with
 {{{
 django-admin-2.6.py startproject sitecontenttypebug
 }}}

 Modify settings.py to use postgres autocommit

 {{{
 DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
...
'OPTIONS': {
"autocommit": True,
}
}
 }
 }}}

 The minimum required to have the django tests fail is:
 {{{
 python manage.py test contenttypes
 sites.SitesFrameworkTests.test_get_current_site
 }}}

 Switching the order causes no failure
 {{{
 python manage.py test sites.SitesFrameworkTests.test_get_current_site
 contenttypes
 }}}

 Stack trace from the failure
 {{{
 ==
 ERROR: test_get_current_site
 (django.contrib.sites.tests.SitesFrameworkTests)
 --
 Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/test/testcases.py", line 257, in
 __call__
self._pre_setup()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/test/testcases.py", line 224, in
 _pre_setup
self._fixture_setup()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/test/testcases.py", line 515, in
 _fixture_setup
return super(TestCase, self)._fixture_setup()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/test/testcases.py", line 236, in
 _fixture_setup
call_command('flush', verbosity=0, interactive=False, database=db)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/core/management/__init__.py", line
 166, in call_command
return klass.execute(*args, **defaults)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/core/management/base.py", line 220,
 in execute
output = self.handle(*args, **options)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/core/management/base.py", line 351,
 in handle
return self.handle_noargs(**options)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/core/management/commands/flush.py",
 line 75, in handle_noargs
emit_post_sync_signal(all_models, verbosity, interactive, db)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/core/management/sql.py", line 182,
 in emit_post_sync_signal
interactive=interactive, db=db)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/dispatch/dispatcher.py", line 172,
 in send
response = receiver(signal=self, sender=sender, **named)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/contrib/auth/management/
 __init__.py", line 28, in create_permissions
defaults={'name': name, 'content_type': ctype})
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/db/models/manager.py", line 135, in
 get_or_create
return self.get_query_set().get_or_create(**kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/db/models/query.py", line 387, in
 get_or_create
transaction.savepoint_rollback(sid, using=self.db)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/db/transaction.py", line 242, in
 savepoint_rollback
connection._savepoint_rollback(sid)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/db/backends/__init__.py", line 61,
 in _savepoint_rollback
self.cursor().execute(self.ops.savepoint_rollback_sql(sid))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/
 lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/
 base.

Re: [Django] #15522: delete_model on admin delete action

[Django]

#15522: delete_model on admin delete action
-+-
   Reporter:  Divad  |Owner:  nobody
 Status:  reopened   |Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  delete_model
 Resolution: |Has patch:  1
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by Divad ):

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


Comment:

 I have defined historic models with three states Current / Changed /
 Deleted, t\
 agged with user and timestamp of operation.
 so i have defined "delete_model" as:

 {{{
 def delete_model(self, request, obj):
 obj.user = request.user
 super(HistoricModelAdmin,self).delete_model(request, obj)
 }}}

 this allows to track the user who deletes an object.

 On the other end when bulk delete is triggered with delete action, I do
 not kno\
 w the user who triggered the action, resulting in two different results.

 I suppose there could be other users unaware of this two different results
 to t\
 he same action.

 But someone could argue that I should define my own delete action instead
 of us\
 ing the default one.

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

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

[Django] #15541: FAQ should reference http://www.djangosites.org/ directly instead of retired wiki page

[Django]

#15541: FAQ should reference http://www.djangosites.org/ directly instead of
retired wiki page
---+---
 Reporter:  aaugustin  | Owner:  nobody
   Status:  new| Milestone:
Component:  Documentation  |   Version:  1.2
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  1  |
---+---


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

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

[Django] #15540: Meta Widgets doesn't work in form.Form

[Django]

#15540: Meta Widgets doesn't work in form.Form
--+---
 Reporter:  silent1mezzo  | Owner:  nobody
   Status:  new   | Milestone:
Component:  Forms |   Version:  1.2
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 You can't change the widget in the Meta.widgets for a regular form.

 {{{

 #Doesn't work
 class SearchForm(forms.Form):
search = forms.CharField(max_length=100)

class Meta:
widgets = {
'search': forms.TextInput(attrs={'class': 'class_name'}),
}

 #Works Fine
 class SearchForm(forms.Form):
search = forms.CharField(max_length=100,
 widget=forms.TextInput(attrs={'class': 'class_name'}))

 }}}

 I feel that this could be extremely confusing for people.

-- 
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] #15518: Separate CSRF checks to function

[Django]

#15518: Separate CSRF checks to function
-+--
   Reporter:  vzima  |Owner:  nobody
 Status:  reopened   |Milestone:
  Component:  Documentation  |  Version:  1.2
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--

Comment (by vzima):

 That is what I needed, but still there is no common way how to call CSRF
 check, if you want to do it manually.

 Code for view with CSRF check not provided by middleware/decorator looks
 {{{
 #!python
 from django.middleware.csrf import CsrfViewMiddleware, _get_new_csrf_key,
 _sanitize_token
 from django.views.decorators.csrf import csrf_view_exempt

 @csrf_view_exempt
 def some_view(request):
 if (...some_conditions...):
 result = CsrfViewMiddleware().process_view(request, lambda: None,
 None, None)
 # if None is returned, than it is OK
 if result:
 # Store data back to session to prevent their loss
 return result
 return ...some other response...
 }}}

 We have view like this at endpoint for OpenID provider, but I do not like
 the way I have to call CSRF check.

-- 
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] #9213: PasswordResetForm should not reset passwords for inactive users

[Django]

#9213: PasswordResetForm should not reset passwords for inactive users
--+-
   Reporter:  john_scott  |Owner:  anonymous
 Status:  assigned|Milestone:  1.3
  Component:  Authentication  |  Version:  1.3-alpha
 Resolution:  | Keywords:
   Triage Stage:  Accepted|Has patch:  1
Needs documentation:  1   |  Needs tests:  1
Patch needs improvement:  0   |
--+-
Changes (by jezdez):

 * component:  Contrib apps => Authentication


-- 
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] #15539: Django shows traceback even when debug is false

[Django]

#15539: Django shows traceback even when debug is false
-+-
   Reporter:  phektus@…  |Owner:  Arbie Samong
 Status:  closed |Milestone:
  Component: |  Version:  1.2
  Uncategorized  | Keywords:  exception 500 debug
 Resolution:  needsinfo  |Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 I actually tested it off the default vanilla server (manage.py runserver),
 not sure of any other production setups that would do a similar behavior.
 I think you're right, apache would handle this well as compared to the
 default server, which shouldn't be used in a production space in the first
 place.

-- 
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] #15539: Django shows traceback even when debug is false

[Django]

#15539: Django shows traceback even when debug is false
-+-
   Reporter:  phektus@…  |Owner:  Arbie Samong
 Status:  closed |Milestone:
  Component: |  Version:  1.2
  Uncategorized  | Keywords:  exception 500 debug
 Resolution:  needsinfo  |Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by kmtracey):

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


Comment:

 What are you using for your production server? If I put an error in base
 urls.py on a test Apache/mod_wsgi served project, I get Apache's "Internal
 Server Error" page (the traceback is logged in the Apache error log, not
 shown on the requesting browser). I've seen more sophisticated wsgi
 scripts for production which catch any exceptions raised by the wsgi
 application and present a pretty error page in place of Apache's plain
 Internal Server Error page. Essentially there are always going to be cases
 of errors thrown that are not covered by Django's 500 handler...and your
 production server configuration needs to be set up properly to ensure that
 what's sent back to the browser in that case is what you want.

 Removing the 2.0 milestone because that's meant for stuff that we'd like
 to do at some point but will cause backwards-compatibility problems, and
 this issue wouldn't have backwards compatibility problems. There's no
 reason improvements to error handling would need to wait until 2.0
 timeframe. Closing needsinfo because maybe there is a case to be made that
 the 500 handler should be covering cases like errors in urls.py, but
 someone would need to investigate whether that's feasible. My first
 thought is that's a case that needs to be handled by the production server
 config.

-- 
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] #15536: ModelForm validation regression in 1.2 when using TimeField with choices

[Django]

#15536: ModelForm validation regression in 1.2 when using TimeField with choices
+---
   Reporter:  3point2   |Owner:  nobody
 Status:  closed|Milestone:  1.3
  Component:  Forms |  Version:  1.2
 Resolution:  invalid   | Keywords:  blocker, regression
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by russellm):

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


Comment:

 Ok - after a closer look, this is a case of an error in your code that is
 now being caught.

 This change was introduced by r12098 -- the introduction of model-based
 validation. This improved the validation of inputs across the board,
 including the case that you have described.

 In your specific example, the error that has been caught is the fact that
 "09:00:00" *isn't* a valid value for a Date. It may be a valid form input,
 but it isn't a valid database value. As you suspect, this same change will
 affect other fields -- because a string isn't a valid value for a date
 field of any stripe.

 Django's backwards compatibility guarantee doesn't apply to bugs -- it
 only applies to features when used correctly (or as documented). In this
 case, it appears that you were relying on an undocumented looseness in
 Django's handling of dates. r12098 improved the validation of these
 values, and your code has been caught in the crossfire.

-- 
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] #15539: Django shows traceback even when debug is false

[Django]

#15539: Django shows traceback even when debug is false
-+-
 Reporter:  phektus@…| Owner:  Arbie Samong
   Status:  new  | Milestone:  2.0
Component:  Uncategorized|   Version:  1.2
 Keywords:  exception 500 debug  |  Triage Stage:  Unreviewed
Has patch:  0|
-+-
 I had an error in urls.py, which threw an exception. Now the site is in
 production, and debug is set to false. I have custom 400 and 500 pages.
 Now I know I can easily check that sort of error in a local setup, but
 shouldn't there be no traceback information whatsoever when debug is
 false?

 Just put some erroneous code or throw and exception in urls.py to
 reproduce.

-- 
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] #6750: Invalid xhtml in AdminFileWidget (target="_blank")

[Django]

#6750: Invalid xhtml in AdminFileWidget (target="_blank")
-+-
   Reporter: |Owner:
  garcia_marc|Milestone:
 Status:  closed |  Version:  newforms-admin
  Component: | Keywords:  admin invalid xhtml
  django.contrib.admin   |  AdminFileWidget nfa-someday
 Resolution:  fixed  |Has patch:  1
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by lrekucki):

 Just for reference, (x)HTML 5 no longer deprecates {{{target="blank"}}}.

-- 
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] #7309: NFA: Don't override order_by if no default ordering is specified

[Django]

#7309: NFA: Don't override order_by if no default ordering is specified
-+-
   Reporter:  lukas@…|Owner:  nobody
 Status:  new|Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  order_by nfa-someday
 Resolution: |Has patch:  0
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by julien):

 #10212 is a dupe and has a patch.

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

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

Re: [Django] #10212: Admin ChangeList doesn't apply 'order_by' clause specified by ModelAdmin.queryset

[Django]

#10212: Admin ChangeList doesn't apply 'order_by' clause specified by
ModelAdmin.queryset
-+-
   Reporter: |Owner:  nobody
  kyle.fox@… |Milestone:
 Status:  closed |  Version:  1.0
  Component: | Keywords:  ChangeList, admin,
  django.contrib.admin   |  ordering, queryset
 Resolution:  duplicate  |Has patch:  1
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 This is a dupe of #7309.

-- 
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] #6750: Invalid xhtml in AdminFileWidget (target="_blank")

[Django]

#6750: Invalid xhtml in AdminFileWidget (target="_blank")
-+-
   Reporter: |Owner:
  garcia_marc|Milestone:
 Status:  closed |  Version:  newforms-admin
  Component: | Keywords:  admin invalid xhtml
  django.contrib.admin   |  AdminFileWidget nfa-someday
 Resolution:  fixed  |Has patch:  1
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 Things have changed since 3 years ago and I now can't find any occurrence
 of `target="_blank"` in the code, so let's consider this as 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] #8190: Utilise help_text for TabularInline in Admin

[Django]

#8190: Utilise help_text for TabularInline in Admin
+--
   Reporter:  glenjamin |Owner:  nobody
 Status:  new   |Milestone:  1.4
  Component:  django.contrib.admin  |  Version:  SVN
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by julien):

 * milestone:   => 1.4


Comment:

 I'd like to see this in 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] #11383: Admin action 'Delete selected' check only global model delete permission

[Django]

#11383: Admin action 'Delete selected' check only global model delete permission
-+-
   Reporter:  krejcik@…  |Owner:  nobody
 Status:  new|Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  delete permission
 Resolution: |  admin
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by julien):

 Check #10609 for yet another related 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] #10609: Permissions on admin actions

[Django]

#10609: Permissions on admin actions
+--
   Reporter:  leitjohn  |Owner:  leitjohn
 Status:  assigned  |Milestone:
  Component:  django.contrib.admin  |  Version:  1.1-beta-1
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--

Comment (by julien):

 #11383 is a related 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] #12241: Admin forgets URL used for prefilling forms when hitting Save and add another

[Django]

#12241: Admin forgets URL used for prefilling forms when hitting Save and add
another
+---
   Reporter:  velmont   |Owner:  batiste
 Status:  new   |Milestone:
  Component:  django.contrib.admin  |  Version:  SVN
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+---
Changes (by julien):

 * needs_tests:  1 => 0


Comment:

 #10824 was closed as a dupe. Note that Malcolm and Chris had triaged the
 ticket differently than this one (i.e. considered as a new feature with
 DDN).

-- 
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] #10824: GET infos is lost

[Django]

#10824: GET infos is lost
+
   Reporter:  roboter |Owner:  nobody
 Status:  closed|Milestone:
  Component:  django.contrib.admin  |  Version:  SVN
 Resolution:  duplicate | Keywords:  GET info
   Triage Stage:  Someday/Maybe |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+
Changes (by julien):

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


Comment:

 This is a dupe of #12241 which, although it is more recent, contains more
 thorough discussions and has patches.

-- 
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] #13539: The delete confirmation page does not check for object-level permissions when building the related list

[Django]

#13539: The delete confirmation page does not check for object-level permissions
when building the related list
-+-
   Reporter: |Owner:  nobody
  delinhabit |Milestone:
 Status:  new|  Version:  1.2-beta
  Component: | Keywords:  delete object-level
  django.contrib.admin   |  permissions
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-

Comment (by julien):

 Related issue: #11383.

-- 
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] #11383: Admin action 'Delete selected' check only global model delete permission

[Django]

#11383: Admin action 'Delete selected' check only global model delete permission
-+-
   Reporter:  krejcik@…  |Owner:  nobody
 Status:  new|Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  delete permission
 Resolution: |  admin
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by julien):

 Related issue: #13539.

-- 
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] #15522: delete_model on admin delete action

[Django]

#15522: delete_model on admin delete action
-+-
   Reporter:  Divad  |Owner:  nobody
 Status:  closed |Milestone:
  Component: |  Version:  SVN
  django.contrib.admin   | Keywords:  delete_model
 Resolution:  invalid|Has patch:  1
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 I don't think this is relevant as the delete action performs a
 
[http://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.QuerySet.delete
 bulk delete on the queryset] instead of calling `delete()` for each
 object.

 If you think I'm mistaken, please reopen but also provide more detailed
 information (e.g. description of a use case or code samples) about what
 you're trying to achieve.

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