Re: [Django] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   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 julien):

 The "model_tag" replacement is very elegant, well done! I'm just a bit
 ambivalent with the name between "admin_url" (shorter and sexier) and
 "admin_url_name" (more explicit and accurate) -- although it's no big deal
 either way.

 Unfortunately I still can't reproduce those test errors with any
 permutations of `generic_inline_admin`, `admin_views` and `comment_tests`.
 However, from what you've described in IRC it does feel like there could
 be some conflicts relating to the order in which the models are registered
 in the admin. Perhaps those errors could be avoided by using a context
 manager:

 {{{#!python
 def test_blah(self):
 with override_admin((MyModel, MyModelAdmin), (MyAwesomeModel,
 MyAwesomeModelAdmin),):
 # Tests go here
 ...
 }}}

 On `__enter__()` the CM would back up potential modeladmins that are
 already registered, then unregister them, then register the ones provided
 as arguments. And on `__exit__()` the CM would re-register the backed up
 modeladmins.

 Just a thought!

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

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

Re: [Django] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
   Reporter: |  Owner:  Honza_Kral
  Rick.van.Hattem@…  | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  database, postgres,
   Triage Stage:  Accepted   |  postgresql, connection, closed
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by Rick van Hattem ):

 For the record, I have had the code running in production since opening
 this ticket and I have not seen any problems yet.

 So as far as empirical evidence goes, it is safe to commit a patch like
 that.

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

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

Re: [Django] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
   Reporter: |  Owner:  Honza_Kral
  Rick.van.Hattem@…  | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  database, postgres,
   Triage Stage:  Accepted   |  postgresql, connection, closed
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by russellm):

 I agree with Malcolm. Checking exception messages is fragile, and I can't
 think of an obvious downside to just treating a closed connection as
 closed, especially if we log/report the fact that we tried and failed to
 close the connection (so the process isn't completely transparent).

-- 
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] #13296: order_with_respect_to fails to correctly track _order after deleting entries

[Django]

#13296: order_with_respect_to fails to correctly track _order after deleting
entries
-+-
   Reporter:  krijesta   |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by DrMeers):

 I was steering away from making the tests '''too''' explicit, particularly
 in regard to the value of the `_order` field -- I'd prefer to test the
 behaviour rather than the implementation. Currently, for efficiency's
 sake, if you delete an item you'll get a "gap" in the `_order` sequence. I
 don't actually ''want'' the "gap" so much that I want to test for it, and
 would like the tests to continue to pass even if someone later decides to
 trigger reordering upon modification, or even if they wanted to switch
 between zero/one-based indexing.

 Another test or two based on delete/add/move operations wouldn't hurt,
 though those I'd written were enough to convince me there were no logic
 holes.

-- 
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] #11603: Add an assertFormSetError function to django.test.TestCase

[Django]

#11603: Add an assertFormSetError function to django.test.TestCase
-+-
   Reporter: |  Owner:  martin_speleo
  martin_speleo  | Status:  new
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  formset
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by russellm):

 As requested in a private chat, here are the errors I see running against
 r16707, Python 2.6.1, under OSX Snow Leopard.
 {{{

 django)kronkite:tests rkm$ ./runtests.py --settings=sqlite test_client
 test_client_regress
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 
.FF...F..FF..
 ==
 FAIL: test_no_nonfield_error
 (regressiontests.test_client_regress.models.AssertFormsetErrorTests)
 An assertion is raised if the formsets non-field errors doesn't contain
 any errors.
 --
 Traceback (most recent call last):
   File
 
"/Users/rkm/projects/django/hg/tests/regressiontests/test_client_regress/models.py",
 line 606, in test_no_nonfield_error
 prefix + "The formset 'my_formset', form 1 in "
 AssertionError: "True is not False : The formset 'my_formset', form 1 in
 context 0 does not contain any non-field errors." != "The formset
 'my_formset', form 1 in context 0 does not contain any non-field errors."

 ==
 FAIL: test_no_nonform_error
 (regressiontests.test_client_regress.models.AssertFormsetErrorTests)
 An assertion is raised if the formsets non-form errors doesn't contain any
 errors.
 --
 Traceback (most recent call last):
   File
 
"/Users/rkm/projects/django/hg/tests/regressiontests/test_client_regress/models.py",
 line 647, in test_no_nonform_error
 "The formset 'my_formset' in context 0 "
 AssertionError: "True is not False : The formset 'my_formset' in context 0
 does not contain any non-form errors." != "The formset 'my_formset' in
 context 0 does not contain any non-form errors."

 ==
 FAIL: test_unknown_error
 (regressiontests.test_client_regress.models.AssertFormsetErrorTests)
 An assertion is raised if the field doesn't contain the specified error
 --
 Traceback (most recent call last):
   File
 
"/Users/rkm/projects/django/hg/tests/regressiontests/test_client_regress/models.py",
 line 579, in test_unknown_error
 prefix + "The field 'email' "
 AssertionError: "False is not True : The field 'email' on formset
 'my_formset', form 0 in context 0 does not contain the error 'Some error.'
 (actual errors: [u'Enter a valid e-mail address.'])" != "The field 'email'
 on formset 'my_formset', form 0 in context 0 does not contain the error
 'Some error.' (actual errors: [u'Enter a valid e-mail address.'])"

 ==
 FAIL: test_unknown_nonfield_error
 (regressiontests.test_client_regress.models.AssertFormsetErrorTests)
 An assertion is raised if the formsets non-field errors doesn't contain
 the provided error.
 --
 Traceback (most recent call last):
   File
 
"/Users/rkm/projects/django/hg/tests/regressiontests/test_client_regress/models.py",
 line 621, in test_unknown_nonfield_error
 prefix + "The formset 'my_formset', form 0 in "
 AssertionError: "False is not True : The formset 'my_formset', form 0 in
 context 0 does not contain the non-field error 'Some error.' (actual
 errors: [u'Non-field error.'])" != "The formset 'my_formset', form 0 in
 context 0 does not contain the non-field error 'Some error.' (actual
 errors: [u'Non-field error.'])"

 ==
 FAIL: test_unknown_nonform_error
 (regressiontests.test_client_regress.models.AssertFormsetErrorTests)
 An assertion is raised if the formsets non-form errors doesn't contain the
 provided error.
 --
 Traceback (most recent call last):
   File
 
"/Users/rkm/projects/django/hg/tes

Re: [Django] #15237: Django generated Atom/RSS feeds don't specify charset=utf8 in their Content-Type

[Django]

#15237: Django generated Atom/RSS feeds don't specify charset=utf8 in their
Content-Type
+-
   Reporter:  simon |  Owner:  jasonkotenko
   Type:  Bug   | Status:  reopened
  Milestone:  1.3   |  Component:  contrib.syndication
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+-
Changes (by aaugustin):

 * ui_ux:   => 0
 * easy:   => 1


Comment:

 Bug confirmed: http://tools.ietf.org/html/rfc3023#section-3.2 (link given
 in a previous comment) says `'utf-8'` and not `'utf8'`.

 While investigating this problem, I noticed that the codebase consistently
 uses `.encode('utf-8')`, except one instance in
 `tests/regressiontests/signing/tests.py`, where the dash is missing. The
 `codecs` module defines `utf8` as an alias of `utf-8`, so the code works,
 but there's no reason to keep this exception. I included that fix in the
 patch too — feel free to commit it separately or not commit it at all.

 PS : you could have opened a new ticket instead of reopening this one,
 because strictly speaking, it's a different 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] #6148: Add generic support for database schemas

[Django]

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

Comment (by shaun.stanworth@…):

 Pretty nasty bug in this still - if you run tests which are left
 incomplete, Django will ask 'if you would like to try deleting the test
 database 'TEST DATABASE'' - the problem is that the _destroy_test_schemas
 method is connecting using your normal alias, which will hit your working
 database.

-- 
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] #15802: Django stops functioning when the database (PostgreSQL) closes the connection

[Django]

#15802: Django stops functioning when the database (PostgreSQL) closes the
connection
-+-
   Reporter: |  Owner:  Honza_Kral
  Rick.van.Hattem@…  | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  database, postgres,
   Triage Stage:  Accepted   |  postgresql, connection, closed
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by Honza_Kral):

 * owner:  nobody => Honza_Kral
 * status:  new => assigned


Comment:

 Replying to [comment:5 mtredinnick]:
 > That SQLAlchemy code looks fragile in the medium-term. I tend to agree
 with comment 4: we make a decent attempt to close the connection and then
 call it "closed" anyway. Before committing something along those lines,
 can anybody think of a case where that is going to bite us (I can't)?

 Neither can I, I have been thinking about it since I wrote that ugly hack
 of a patch and I cannot think of anything going wrong. We could be leaking
 open connections, but those should get garbage collected and even that
 would be better than disabling that process/thread forever (for example
 gunicorn can't recover from this so this can kill production alltogether).

 I will wait one more day for someone to speak up and then I will commit
 the patch (just connection = None, not the pseudo detection).

-- 
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] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   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|
---+---
Changes (by jezdez):

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


Comment:

 This looks great, yay for not needing a `model_url` tag!

-- 
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] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
---+---
   Reporter:  julien   |  Owner:  ramiro
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by apollo13):

 Attached a new diff with the new proposed syntax, needs docs for the new
 filter.

-- 
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] #14571: Update jQuery

[Django]

#14571: Update jQuery
-+-
   Reporter:  robhudson  |  Owner:  dArignac
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:  jquery sprintnov13
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-
Changes (by julien):

 * stage:  Ready for checkin => Accepted
 * milestone:  1.4 =>


Comment:

 I've just talked to jezdez on IRC and we agree that it is too risky to
 upgrade jQuery at this stage, now that we're approaching the end of the
 1.4 release cycle. Where it may bring negligible performance improvements,
 it may also break existing code. In the absence of a proper JS testing
 framework we're not willing to take that risk for the moment. The
 situation can be reassessed after 1.4 ships.

-- 
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] #16700: The request_started signal is not called for the first request a newly-initialized webserver receives.

[Django]

#16700: The request_started signal is not called for the first request a newly-
initialized webserver receives.
+---
   Reporter:  etianen   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by aaugustin):

 * component:  Core (Other) => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 If you declare your signals in the models.py of an application, this
 problem is reproducible with any server that uses `WSGIHandler` —
 '''except the dev server''', because it imports all the models and
 validates them before starting. This might affect signals other than
 `request_started`, depending on where they're connected.

 A workaround is to connect the `request_started` signal in your settings
 module.

 Attached project demonstrates the problem with the WSGI server of the
 standard library. Unpack it and run: `PYTHONPATH=. python
 bug16700/run_me.py`

 I suggest documenting this problem and the workaround as a known pitfall.

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

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

[Changeset] r16707 - django/trunk/docs/internals/contributing

[noreply]

Author: idangazit
Date: 2011-08-28 07:43:51 -0700 (Sun, 28 Aug 2011)
New Revision: 16707

Modified:
   django/trunk/docs/internals/contributing/bugs-and-features.txt
Log:
Added guidelines for reporting UI-related bugs & feature requests.

Modified: django/trunk/docs/internals/contributing/bugs-and-features.txt
===
--- django/trunk/docs/internals/contributing/bugs-and-features.txt  
2011-08-28 13:51:28 UTC (rev 16706)
+++ django/trunk/docs/internals/contributing/bugs-and-features.txt  
2011-08-28 14:43:51 UTC (rev 16707)
@@ -89,6 +89,32 @@
   go-public date. This will probably mean a new release of Django, but
   in some cases it may simply be patches against current releases.
 
+Reporting user interface bugs and features
+--
+
+If your bug or feature request touches on anything visual in nature, there
+are a few additional guidelines to follow:
+
+* Include screenshots in your ticket which are the visual equivalent of a
+  minimal testcase. Show off the issue, not the crazy customizations
+  you've made to your browser.
+
+* If the issue is difficult to show off using a still image, consider
+  capturing a *brief* screencast. If your software permits it, capture only
+  the relevant area of the screen.
+
+* If you're offering a patch which changes the look or behavior of Django's
+  UI, you **must** attach before *and* after screenshots/screencasts.
+  Tickets lacking these are difficult for triagers and core developers to
+  assess quickly.
+
+* Screenshots don't absolve you of other good reporting practices. Make 
sure
+  to include URLs, code snippets, and step-by-step instructions on how to
+  reproduce the behavior visible in the screenshots.
+
+* Make sure to set the UI/UX flag on the ticket so interested parties can
+  find your ticket.
+
 Requesting features
 ---
 

-- 
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] #15004: Fix for Django Tutorial (part 2), getting admin-site show CSS correctly with development server

[Django]

#15004: Fix for Django Tutorial (part 2), getting admin-site show CSS correctly
with development server
-+-
   Reporter:  psgg1981   |  Owner:  nobody
   Type: | Status:  closed
  Uncategorized  |  Component:  Djangoproject.com
  Milestone: |  Web site
Version: |   Severity:  Normal
 Resolution:  fixed  |   Keywords:  tutorial
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by rk.aranas@…):

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


Comment:

 Encountered the same problem. Am on Windows XP and using the Django 1.3
 that came with the DjangoStack installer by Bitnami. It seems Django
 couldn't find the media files. Fixed it by creating a /static/admin/media
 directory inside the polls app directory and placing the contents of
 /django/contrib/admin/media there.

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

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

[Changeset] r16706 - in django/trunk: django/contrib/localflavor django/contrib/localflavor/si docs/ref/contrib tests/regressiontests/localflavor tests/regressiontests/localflavor/si

[noreply]

Author: julien
Date: 2011-08-28 06:51:28 -0700 (Sun, 28 Aug 2011)
New Revision: 16706

Added:
   django/trunk/django/contrib/localflavor/si/
   django/trunk/django/contrib/localflavor/si/__init__.py
   django/trunk/django/contrib/localflavor/si/forms.py
   django/trunk/django/contrib/localflavor/si/si_postalcodes.py
   django/trunk/tests/regressiontests/localflavor/si/
   django/trunk/tests/regressiontests/localflavor/si/__init__.py
   django/trunk/tests/regressiontests/localflavor/si/tests.py
Modified:
   django/trunk/docs/ref/contrib/localflavor.txt
   django/trunk/tests/regressiontests/localflavor/tests.py
Log:
Fixed #16202 -- Added a Slovenian localflavor. Thanks to Jure Cuhalev < 
gand...@owca.info>, Gasper Zejn and Domen Kozar for the patch.

Added: django/trunk/django/contrib/localflavor/si/__init__.py
===
Added: django/trunk/django/contrib/localflavor/si/forms.py
===
--- django/trunk/django/contrib/localflavor/si/forms.py 
(rev 0)
+++ django/trunk/django/contrib/localflavor/si/forms.py 2011-08-28 13:51:28 UTC 
(rev 16706)
@@ -0,0 +1,164 @@
+"""
+Slovenian specific form helpers.
+"""
+
+import datetime
+import re
+
+from django.forms.fields import CharField, Select, ChoiceField
+from django.core.validators import EMPTY_VALUES
+from django.forms import ValidationError
+from django.utils.translation import ugettext_lazy as _
+
+
+class SIEMSOField(CharField):
+"""A form for validating Slovenian personal identification number.
+
+Additionally stores gender, nationality and birthday to self.info 
dictionary.
+"""
+
+default_error_messages = {
+'invalid': _(u'This field should contain exactly 13 digits.'),
+'date': _(u'The first 7 digits of the EMSO must represent a valid past 
date.'),
+'checksum': _(u'The EMSO is not valid.'),
+}
+emso_regex = re.compile('^(\d{2})(\d{2})(\d{3})(\d{2})(\d{3})(\d)$')
+
+def clean(self, value):
+super(SIEMSOField, self).clean(value)
+if value in EMPTY_VALUES:
+return u''
+
+value = value.strip()
+
+m = self.emso_regex.match(value)
+if m is None:
+raise ValidationError(self.default_error_messages['invalid'])
+
+# Validate EMSO
+s = 0
+int_values = [int(i) for i in value]
+for a, b in zip(int_values, range(7, 1, -1) * 2):
+s += a * b
+chk = s % 11
+if chk == 0:
+K = 0
+else:
+K = 11 - chk
+
+if K == 10 or int_values[-1] != K:
+raise ValidationError(self.default_error_messages['checksum'])
+
+# Extract extra info in the identification number
+day, month, year, nationality, gender, chksum = [int(i) for i in 
m.groups()]
+
+if year < 890:
+year += 2000
+else:
+year += 1000
+
+# validate birthday
+try:
+birthday = datetime.date(year, month, day)
+except ValueError:
+raise ValidationError(self.error_messages['date'])
+if datetime.date.today() < birthday:
+raise ValidationError(self.error_messages['date'])
+
+self.info = {
+'gender': gender < 500 and 'male' or 'female',
+'birthdate': birthday,
+'nationality': nationality,
+}
+return value
+
+
+class SITaxNumberField(CharField):
+"""Slovenian tax number field.
+
+Valid input is SI or  where X is a number.
+"""
+
+default_error_messages = {
+'invalid': _(u'Enter a valid tax number in form SI'),
+}
+sitax_regex = re.compile('^(?:SI)?([1-9]\d{7})$')
+
+def clean(self, value):
+super(SITaxNumberField, self).clean(value)
+if value in EMPTY_VALUES:
+return u''
+
+value = value.strip()
+
+m = self.sitax_regex.match(value)
+if m is None:
+raise ValidationError(self.default_error_messages['invalid'])
+value = m.groups()[0]
+
+# Validate Tax number
+s = 0
+int_values = [int(i) for i in value]
+for a, b in zip(int_values, range(8, 1, -1)):
+s += a * b
+chk = 11 - (s % 11)
+if chk == 10:
+chk = 0
+
+if int_values[-1] != chk:
+raise ValidationError(self.default_error_messages['invalid'])
+
+return value
+
+
+class SIPostalCodeField(ChoiceField):
+"""Slovenian post codes field.
+"""
+
+def __init__(self, *args, **kwargs):
+from si_postalcodes import SI_POSTALCODES_CHOICES
+kwargs.setdefault('choices', SI_POSTALCODES_CHOICES)
+super(SIPostalCodeField, self).__init__(*args, **kwargs)
+
+
+class SIPostalCodeSelect(Select):
+"""A Select widget that uses Slovenian postal codes as its choices.
+"""
+def __init__(self, attr

Re: [Django] #16202: Localflavor support for Slovenia (si)

[Django]

#16202: Localflavor support for Slovenia (si)
-+-
   Reporter:  Jure   |  Owner:  nobody
  Cuhalev | Status:  closed
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 In [16706]:
 {{{
 #!CommitTicketReference repository="" revision="16706"
 Fixed #16202 -- Added a Slovenian localflavor. Thanks to Jure Cuhalev <
 gand...@owca.info>, Gasper Zejn and Domen Kozar for the patch.
 }}}

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

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

Re: [Django] #16202: Localflavor support for Slovenia (si)

[Django]

#16202: Localflavor support for Slovenia (si)
-+-
   Reporter:  Jure   |  Owner:  nobody
  Cuhalev | Status:  reopened
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 Thanks!

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

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

Re: [Django] #13296: order_with_respect_to fails to correctly track _order after deleting entries

[Django]

#13296: order_with_respect_to fails to correctly track _order after deleting
entries
-+-
   Reporter:  krijesta   |  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by julien):

 Thanks for the patch, Simon! It looks pretty good to me. I'm just
 wondering if the tests could be made a little more thorough by adding more
 items, by doing more delete/add/move operations and by asserting the
 actual values of each item's `_order` field. What do you think?

-- 
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] #16028: Consolidate default template filters' tests

[Django]

#16028: Consolidate default template filters' tests
-+-
   Reporter:  julien |  Owner:  julien
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 Replying to [comment:12 julien]:
 > Is that a real issue? Should I keep going this way or is that a bad
 idea?

 I don't think it's a big deal, but if you want to be totally safe, you
 could add a separate test to check the type of the result of each filter
 that can return something other than a string.

-- 
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] #16028: Consolidate default template filters' tests

[Django]

#16028: Consolidate default template filters' tests
-+-
   Reporter:  julien |  Owner:  julien
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 I have posted a work in progress (about 1/3rd of the way there) but before
 I go any further I'd like to get some feedback on one particular concern I
 have. I'm porting the tests from the `defaultfilters` module to match the
 majority of other tests in the `templates.filters` module. However, this
 way of testing tests the results as strings. For example, even though the
 `wordcount` filter returns integers, the tests check results like `u'3'`.

 Is that a real issue? Should I keep going this way or is that a bad idea?

-- 
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] #16202: Localflavor support for Slovenia (si)

[Django]

#16202: Localflavor support for Slovenia (si)
-+-
   Reporter:  Jure   |  Owner:  nobody
  Cuhalev | Status:  reopened
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by iElectric):

 Patch updated to current trunk.

 BTW, Domen Kozar and iElectric are the same person :)

-- 
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] #16504: PROJECT_ROOT ought to be in the generated project settings module

[Django]

#16504: PROJECT_ROOT ought to be in the generated project settings module
-+-
   Reporter:  pydanny|  Owner:  rvanhoepen
   Type:  New| Status:  closed
  feature|  Component:  Core (Other)
  Milestone:  1.4|   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Design |Needs tests:  1
  decision needed|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 FTR, this has been proposed before and proven to be counter-productive.
 The "project" metaphor is only temporary and shouldn't be fortified in yet
 another setting.

-- 
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] #16703: collectstatic management command looks in current working dir instead of project root

[Django]

#16703: collectstatic management command looks in current working dir instead of
project root
-+-
   Reporter: |  Owner:  nobody
  danielnaab | Status:  reopened
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 Replying to [comment:2 danielnaab]:
 > Some more details:  On a clean `django-admin.py` created project, I
 tracked it down to
 `django.contrib.staticfiles.finders.DefaultStorageFinder`.
 STATICFILES_DIRS is empty, STATIC_ROOT is an arbitrary absolute path.

 For the record, the `DefaultStorageFinder` has nothing to do with
 `STATICFILES_DIRS`. It's the empty `MEDIA_ROOT` setting which is the
 problem.

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

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

Re: [Django] #16703: collectstatic management command looks in current working dir instead of project root

[Django]

#16703: collectstatic management command looks in current working dir instead of
project root
-+-
   Reporter: |  Owner:  nobody
  danielnaab | Status:  reopened
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 Yeah, the `DefaultStorageFinder` finder is the compatibility layer between
 the file upload system and staticfiles. If you set MEDIA_ROOT and upload
 there, you might (!) want to include those files when collecting files.

-- 
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] #16703: collectstatic management command looks in current working dir instead of project root

[Django]

#16703: collectstatic management command looks in current working dir instead of
project root
-+-
   Reporter: |  Owner:  nobody
  danielnaab | Status:  reopened
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 The default value `MEDIA_ROOT = ''` had a role in this problem, see
 https://code.djangoproject.com/ticket/16504#comment:6

-- 
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] #16504: PROJECT_ROOT ought to be in the generated project settings module

[Django]

#16504: PROJECT_ROOT ought to be in the generated project settings module
-+-
   Reporter:  pydanny|  Owner:  rvanhoepen
   Type:  New| Status:  assigned
  feature|  Component:  Core (Other)
  Milestone:  1.4|   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  1
  decision needed|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 With this addition, we could provide more sensible defaults: `MEDIA_ROOT =
 os.path.join(PROJECT_ROOT, 'media')` and `STATIC_ROOT =
 os.path.join(PROJECT_ROOT, 'static')`.

 This would have prevented #16703.

-- 
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] #16703: collectstatic management command looks in current working dir instead of project root

[Django]

#16703: collectstatic management command looks in current working dir instead of
project root
-+-
   Reporter: |  Owner:  nobody
  danielnaab | Status:  reopened
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Design decision needed


Comment:

 `DefaultStorageFinder` is disabled by default.

 Indeed, when you enable it, with everything else set to the default
 values, it will find every files inside `MEDIA_ROOT` (the default
 `location` of `FileSystemStorage`). If you haven't set `MEDIA_ROOT` to
 something other than the empty string, it will find every file in the
 current directory!

 The docs are a bit short on explanations on the purpose of this finder:

 https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles
 /#staticfiles-finders:
 > One finder is disabled by default:
 `django.contrib.staticfiles.finders.DefaultStorageFinder`. If added to
 your `STATICFILES_FINDERS` setting, it will look for static files in the
 default file storage as defined by the `DEFAULT_FILE_STORAGE` setting.

 https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-
 DEFAULT_FILE_STORAGE:
 > Default: `django.core.files.storage.FileSystemStorage`
 > Default file storage class to be used for any file-related operations
 that don't specify a particular storage system. See Managing files.

 

 There are several things we can do:
 - remove `DefaultStorageFinder` from the default project template, or add
 a warning;
 - better explain the purpose of this finder in the docs — defaulting to
 listing all media files in particularly confusing — unless it's a media =>
 static compatibility tool?

-- 
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] #16516: Blocktrans should tolerate bad locale data

[Django]

#16516: Blocktrans should tolerate bad locale data
-+-
   Reporter:  simon29|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 Looks good.

-- 
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] #16713: Fixture loading for tests ignore database specific names

[Django]

#16713: Fixture loading for tests ignore database specific names
+---
   Reporter:  brent@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  fixtures, multidb
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by aaugustin):

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


Comment:

 This test shows how this feature works:
 
https://code.djangoproject.com/browser/django/trunk/tests/regressiontests/multiple_database/tests.py#L1621

 With the following changes, your tests pass:
 {{{

 --- testapp/tests.py.orig   2011-08-28 12:11:44.0 +0200
 +++ testapp/tests.py2011-08-28 12:11:02.0 +0200
 @@ -12,7 +12,7 @@
  """
  multi_db = True

 -fixtures = ['people.default.json']
 +fixtures = ['people']

  def test_fixtures_loaded_to_default(self):
  """
 @@ -35,7 +35,7 @@
  This should load the one into default only.
  """

 -fixtures = ['people.default.json']
 +fixtures = ['people']

  def test_fixtures_loaded_to_default(self):
  """
 @@ -61,7 +61,7 @@
  """
  multi_db = True

 -fixtures = ['people.default.json', 'morepeople.core.json']
 +fixtures = ['people', 'morepeople']

  def test_fixtures_loaded_to_default(self):
  """
 }}}

 I think it's a bug. The docs say it's possible to pass only the "base
 name" of the fixture and let Django figure out the rest (database, format,
 compression); they don't say it's mandatory.

-- 
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] #16715: Wrong JOIN with nested null-able foreign keys

[Django]

#16715: Wrong JOIN with nested null-able foreign keys
-+-
   Reporter:  sebastian  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  join, values,
Needs documentation:  0  |  nested, foreign key, null-able
Patch needs improvement:  1  |  Has patch:  1
  UI/UX:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #11603: Add an assertFormSetError function to django.test.TestCase

[Django]

#11603: Add an assertFormSetError function to django.test.TestCase
-+-
   Reporter: |  Owner:  martin_speleo
  martin_speleo  | Status:  new
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  formset
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by martin.speleo@…):

 * cc: martin.speleo@… (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] #11603: Add an assertFormSetError function to django.test.TestCase

[Django]

#11603: Add an assertFormSetError function to django.test.TestCase
-+-
   Reporter: |  Owner:  martin_speleo
  martin_speleo  | Status:  new
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  formset
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by anonymous):

 Replying to [comment:9 russellm]:
 > I just tried to apply this patch, and it failed 4 of its own tests.

 I am unable to reproduce these test failures, could you send me the errors
 that you get, and any relevant version information.

 Thanks,
 Martin

-- 
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] #16716: Regression in admin changelist with failing related admin filters

[Django]

#16716: Regression in admin changelist with failing related admin filters
+-
   Reporter:  julien|  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  contrib.admin
Version:  1.3   |   Severity:  Release blocker
 Resolution:  fixed |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by julien):

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


Comment:

 In [16705]:
 {{{
 #!CommitTicketReference repository="" revision="16705"
 Fixed #16716 -- Fixed two small regressions in the development version
 introduced in r16144 where the changelist crashed with a 500 error instead
 of nicely operating a 302 redirection back to the changelist.

 The two specific cases were:

 * a lookup through a non-existing field and apparently spanning multiple
 relationships (e.g. "?nonexistant__whatever=").
 * a proper list_filter's queryset failing with an exception. In Django 1.3
 the queryset was only directly manipulated by the changelist, whereas in
 1.4 the list_filters may manipulate the queryset themselves. The fix here
 implies catching potential failures from the list_filters too.
 }}}

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

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

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

[noreply]

Author: julien
Date: 2011-08-28 00:57:56 -0700 (Sun, 28 Aug 2011)
New Revision: 16705

Modified:
   django/trunk/django/contrib/admin/views/main.py
   django/trunk/tests/regressiontests/admin_filters/tests.py
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Fixed #16716 -- Fixed two small regressions in the development version 
introduced in r16144 where the changelist crashed with a 500 error instead of 
nicely operating a 302 redirection back to the changelist.

The two specific cases were:

* a lookup through a non-existing field and apparently spanning multiple 
relationships (e.g. "?nonexistant__whatever=").
* a proper list_filter's queryset failing with an exception. In Django 1.3 the 
queryset was only directly manipulated by the changelist, whereas in 1.4 the 
list_filters may manipulate the queryset themselves. The fix here implies 
catching potential failures from the list_filters too.

Modified: django/trunk/django/contrib/admin/views/main.py
===
--- django/trunk/django/contrib/admin/views/main.py 2011-08-28 06:49:29 UTC 
(rev 16704)
+++ django/trunk/django/contrib/admin/views/main.py 2011-08-28 07:57:56 UTC 
(rev 16705)
@@ -267,6 +267,7 @@
 del lookup_params[key]
 lookup_params[smart_str(key)] = value
 
+field = None
 if not use_distinct:
 # Check if it's a relationship that might return more than one
 # instance
@@ -291,7 +292,7 @@
 value = True
 lookup_params[key] = value
 
-if not self.model_admin.lookup_allowed(key, value):
+if field and not self.model_admin.lookup_allowed(key, value):
 raise SuspiciousOperation("Filtering by %s not allowed" % key)
 
 return lookup_params, use_distinct
@@ -300,28 +301,30 @@
 lookup_params, use_distinct = 
self.get_lookup_params(use_distinct=False)
 self.filter_specs, self.has_filters = self.get_filters(request, 
use_distinct)
 
-# Let every list filter modify the qs and params to its liking
-qs = self.root_query_set
-for filter_spec in self.filter_specs:
-new_qs = filter_spec.queryset(request, qs)
-if new_qs is not None:
-qs = new_qs
-for param in filter_spec.used_params():
-try:
-del lookup_params[param]
-except KeyError:
-pass
+try:
+# First, let every list filter modify the qs and params to its
+# liking.
+qs = self.root_query_set
+for filter_spec in self.filter_specs:
+new_qs = filter_spec.queryset(request, qs)
+if new_qs is not None:
+qs = new_qs
+for param in filter_spec.used_params():
+try:
+del lookup_params[param]
+except KeyError:
+pass
 
-# Apply the remaining lookup parameters from the query string (i.e.
-# those that haven't already been processed by the filters).
-try:
+# Then, apply the remaining lookup parameters from the query string
+# (i.e. those that haven't already been processed by the filters).
 qs = qs.filter(**lookup_params)
-# Naked except! Because we don't have any other way of validating 
"params".
-# They might be invalid if the keyword arguments are incorrect, or if 
the
-# values are not in the correct type, so we might get FieldError, 
ValueError,
-# ValicationError, or ? from a custom field that raises yet something 
else
-# when handed impossible data.
 except Exception, e:
+# Naked except! Because we don't have any other way of validating
+# "lookup_params". They might be invalid if the keyword arguments
+# are incorrect, or if the values are not in the correct type, so
+# we might get FieldError, ValueError, ValicationError, or ? from a
+# custom field that raises yet something else when handed
+# impossible data.
 raise IncorrectLookupParameters(e)
 
 # Use select_related() if one of the list_display options is a field

Modified: django/trunk/tests/regressiontests/admin_filters/tests.py
===
--- django/trunk/tests/regressiontests/admin_filters/tests.py   2011-08-28 
06:49:29 UTC (rev 16704)
+++ django/trunk/tests/regressiontests/admin_filters/tests.py   2011-08-28 
07:57:56 UTC (rev 16705)
@@ -1,9 +1,9 @@
 import datetime
 
+from django.contrib.admin.options import IncorrectLookupParameters
 from django.core.exceptions import ImproperlyConfigured
 from django.test import TestCase, RequestFactory