Re: [Django] #596: Allow Django to be packaged as a Python egg

[Django]

#596: Allow Django to be packaged as a Python egg
--+
 Reporter:  sil@… |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by bhuztez):

 * status:  closed => reopened
 * severity:  normal => Normal
 * type:  enhancement => Bug
 * version:  0.91 => SVN
 * easy:   => 0
 * needs_docs:  0 => 1
 * ui_ux:   => 0
 * resolution:  wontfix =>


Comment:

 add support for PEP 302 importers should fix this.
 some related tickets #294 #8238 #8280 #12206 #13334 #13587 #14087 #16718
 #17331

 I will move zip_egg_fixed patch here from #14087 and add PEP 302 importers
 support to the following components

  * templates
  * fixtures
  * static files
  * translations
  * django.db.utils.load_backend

-- 
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] #14087: django.core.management.get_commands only sees commands in the last package of a namespace package

[Django]

#14087: django.core.management.get_commands only sees commands in the last 
package
of a namespace package
--+
 Reporter:  KyleMac   |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by bhuztez):

 * needs_better_patch:  1 => 0
 * version:  1.2 => SVN


Comment:

 I found #596 is a better place for patch zip_egg_fixed. I will move it
 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.

Re: [Django] #5373: Field label for a ForeignKey not translated

[Django]

#5373: Field label for a ForeignKey not translated
-+-
 Reporter:  Szilveszter Farkas   |Owner:  Fandekasp
   |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:   |   Resolution:
  Internationalization   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  i18n foreignkey  |  Patch needs improvement:  0
  field label|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Fandekasp):

 I hope you'll be satisfied with this last 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.

Re: [Django] #6148: Add generic support for database schemas

[Django]

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

 * owner:   => akaariai
 * needs_docs:  0 => 1


Comment:

 Initial status report for the work on this ticket. Using Meta: db_schema
 is somewhat working on PostgreSQL. Other backends will not work at all
 currently (even without schemas). Lacks most tests and many features, and
 of course lacks all polish.

 Implementing the feature fully is much larger amount of work than one
 would expect. Luckily it seems there aren't any really hard problems left.

 I started from the latest patch in this ticket. There was one big mistake
 in that patch: there is no way to have a ._meta.qualified_name which would
 be directly usable in queries. Different backends need different quoting
 etc for the qualified_name, thus it can only be resolved at the
 compiler.py stage.

 To fix this, I change model._meta.qualified_name to a tuple (db_schema,
 db_table), where db_schema can be None. As a result of this, the patch
 implementation has a pretty big change to alias usage in queries: where
 currently first instance of each table will use the plain table name (ie.
 no alias at all), the schema support branch changes this in a way where
 even the first occurrence of the table will get an alias. There are two
 reasons:
   - The implementation would get somewhat nasty without this: for example
 any column could either have alias, or qualified_name as the prefix, and
 one would need to check this each time when quoting the name. Same for
 where clause entries, order_by entries, aggregates and so on.
   - I wonder if users really want to see queries like:
 {{{
 select "some_schema"."some_table"."col1",
 "some_schema"."some_table"."col2", "some_schema"."some_table"."col3"
 from "some_schema"."some_table"
 where "some_schema"."some_table"."col1" = 1
 }}}
 instead of:
 {{{
 select T1."col1", T1."col2", T1."col3"
 from "some_schema"."some_table" T1
 where T1."col1" = 1
 }}}

 In addition I believe the always-alias implementation will make SQL
 generation faster and cleaner. The downside? .extra() users will have a
 fun time rewriting every: "some_table"."col1" to T1."col1".

 So, the question is if the always-alias implementation has any chance of
 getting in. I really think it will result in cleaner queries in SQL, and
 it will simplify query generation. The generated query string should be an
 implementation detail, and .extra users will need to adapt to the changing
 queries.

 If the above is seen as backwards incompatible, I will have to think of a
 way to get the old behavior back. This will likely come with a performance
 penalty, which is unfortunate as generating the column list is even
 currently somewhat slow for wide tables.

 The work can be found from
 [https://github.com/akaariai/django/tree/schemas]. The bulk of the work
 resides in database introspection, and I haven't even touched oracle or
 mysql yet...

 Sidenote: sql/query.py rev_join_map is now removed. There wasn't enough
 usages for it to keep it around. It was used in .combine() where it is
 easily replaced by using alias_map directly, and in .relabel_aliases,
 where it gave a really small performance boost.

-- 
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] #17986: Links to offline documentation in ePub and PDF formats do not work on the documentation home page

[Django]

#17986: Links to offline documentation in ePub and PDF formats do not work on 
the
documentation home page
+
 Reporter:  Jarno Lamberg   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Djangoproject.com Web site  |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 On the documentation home page for 1.4, i.e.
 https://docs.djangoproject.com/en/1.4/, the links to the ePub and PDF
 formats on the right do not work.

 The links point to
 http://media.readthedocs.org/pdf/django/1.4.X/django.pdf and
 http://media.readthedocs.org/epub/django/1.4.X/django.epub, respectively,
 and they both give out a 404 Not Found error.

 The links work correctly on the development version, e.g.
 https://docs.djangoproject.com/en/dev/.

-- 
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] #12140: urlencode empty list encoding bug & fix

[Django]

#12140: urlencode empty list encoding bug & fix
---+
 Reporter:  aneil  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  urlencode  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #17973: Tag the 1.4 release in the repository

[Django]

#17973: Tag the 1.4 release in the repository
-+-
 Reporter:  creecode |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Uncategorized|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 The only official repository at this time is the SVN repository.

-- 
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] #17973: Tag the 1.4 release in the repository

[Django]

#17973: Tag the 1.4 release in the repository
-+-
 Reporter:  creecode |Owner:  nobody
 Type:   |   Status:  reopened
  Cleanup/optimization   |  Version:  1.4
Component:  Uncategorized|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by saippuakauppias):

 * status:  closed => reopened
 * resolution:  fixed =>
 * stage:  Ready for checkin => Unreviewed


Comment:

 At the moment, on github 1.4 tag not 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] #17980: Tests fail when i18n set to True.

[Django]

#17980: Tests fail when i18n set to True.
--+
 Reporter:  wassup|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 I fixed the issue about test_unusable_password. Now you should really find
 out why you obtain localized strings in assertContainsEscaped in your
 tests. I cannot reproduce 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.

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

[noreply]

Author: claudep
Date: 2012-03-26 13:22:02 -0700 (Mon, 26 Mar 2012)
New Revision: 17811

Modified:
   django/trunk/django/contrib/auth/tests/forms.py
Log:
Make auth test pass even when LANGUAGE_CODE is not 'en'. Refs #17980. Thanks 
wassup for the report.

Modified: django/trunk/django/contrib/auth/tests/forms.py
===
--- django/trunk/django/contrib/auth/tests/forms.py 2012-03-26 15:43:11 UTC 
(rev 17810)
+++ django/trunk/django/contrib/auth/tests/forms.py 2012-03-26 20:22:02 UTC 
(rev 17811)
@@ -9,6 +9,7 @@
 from django.test.utils import override_settings
 from django.utils.encoding import force_unicode
 from django.utils import translation
+from django.utils.translation import ugettext as _
 
 
 class UserCreationFormTest(TestCase):
@@ -333,6 +334,6 @@
 form = PasswordResetForm(data)
 self.assertFalse(form.is_valid())
 self.assertEqual(form["email"].errors,
- [u"The user account associated with this e-mail 
address cannot reset the password."])
+ [_(u"The user account associated with this e-mail 
address cannot reset the password.")])
 
 PasswordResetFormTest = override_settings(USE_TZ=False)(PasswordResetFormTest)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, 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] #17980: Tests fail when i18n set to True.

[Django]

#17980: Tests fail when i18n set to True.
--+
 Reporter:  wassup|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 In [17811]:
 {{{
 #!CommitTicketReference repository="" revision="17811"
 Make auth test pass even when LANGUAGE_CODE is not 'en'. Refs #17980.
 Thanks wassup for the report.
 }}}

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

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

Re: [Django] #16376: Support for database links

[Django]

#16376: Support for database links
-+-
 Reporter:   |Owner:  nobody
  stephane.benchimol@…   |   Status:  new
 Type:  New feature  |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  oracle postgres  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 I am currently working on #6148, and I think this could be relatively easy
 to support if the #6148 work gets completed. Just another syntax for the
 FROM entry.

 If this gets implemented, db_link should imply managed = False.

-- 
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] #16376: Support for database links

[Django]

#16376: Support for database links
-+-
 Reporter:   |Owner:  nobody
  stephane.benchimol@…   |   Status:  new
 Type:  New feature  |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  oracle postgres  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by diegobz):

 * cc: diegobz (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] #11485: sitemap.xml doesn't support https urls

[Django]

#11485: sitemap.xml doesn't support https urls
-+-
 Reporter:  sportsboy|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  sitemap, https, ssl  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 I think this has been resolved when fixing #8995.

-- 
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] #5929: Allow Fields to use multiple db columns (complex datatypes)

[Django]

#5929: Allow Fields to use multiple db columns (complex datatypes)
-+-
 Reporter:  poelzi   |Owner:
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Any update? I need pseudo-tz-aware field for date time, as anything but
 PostgreSQL supports timezone aware. I plan to use one column for date time
 and another for timezone name.

-- 
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] #17985: Add additional lookup_allowed whitelist functionality to ModelAdmin

[Django]

#17985: Add additional lookup_allowed whitelist functionality to ModelAdmin
---+--
 Reporter:  3point2|Owner:  nobody
 Type:  New feature|   Status:  reopened
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by 3point2):

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


Comment:

 Sorry to re-open. I'm fine with overriding lookup_allowed, but I opened
 this ticket because I feel like this is a feature that is generally
 useful, and lookup_allowed is undocumented. I feel like this functionality
 should be officially supported, and overriding an undocumented method is
 more of a work-around. Also see http://www.hoboes.com/Mimsy/hacks/fixing-
 django-124s-suspiciousoperation-filtering/lookup_allowed-gets-new-
 parameter-value/

 At the very least, documenting lookup_allowed would be helpful.

 If on the other hand you feel that this functionality is not a common use
 case, I'm fine with closing the ticket and sticking with the work around.

-- 
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] #17611: django.contrib.gis raises exception on ./manage.py test

[Django]

#17611: django.contrib.gis raises exception on ./manage.py test
--+--
 Reporter:  andrey@…  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  GIS   |  Version:  SVN
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by geoffhing@…):

 I ran into this issue when switching from Django 1.3.1 to 1.4.0

 I wanted to add this comment to clarify the reason for getting the
 exception and my fix.

 The exception is thrown because I had set the test runner to the GeoDjango
 like this:

 {{{
 TEST_RUNNER='django.contrib.gis.tests.run_tests'
 }}}

 According to the
 [https://docs.djangoproject.com/en/dev/ref/contrib/gis/testing/#testing-
 geodjango-apps Testing GeoDjango Apps documentation]:

 In Django 1.2, the addition of Spatial Backends simplified the process
 of testing GeoDjango applications. The process is now the same as Testing
 Django applications.

 So, specifying the GeoDjango test runner is no longer required and now
 seems to break things.

-- 
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] #17973: Tag the 1.4 release in the repository

[Django]

#17973: Tag the 1.4 release in the repository
-+-
 Reporter:  creecode |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Uncategorized|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Fixed, thanks to Aymeric.

 https://code.djangoproject.com/browser/django/tags/releases/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.

[Changeset] r17810 - django/tags/releases

[noreply]

Author: aaugustin
Date: 2012-03-26 08:43:11 -0700 (Mon, 26 Mar 2012)
New Revision: 17810

Added:
   django/tags/releases/1.4/
Log:
Tag 1.4


-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, 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] #17984: admin list_filter security fix doesn't allow 'pk' lookups in query string

[Django]

#17984: admin list_filter security fix doesn't allow 'pk' lookups in query 
string
---+--
 Reporter:  3point2|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by 3point2):

 * needs_better_patch:   => 0
 * component:  Uncategorized => contrib.admin
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #17985: Add additional lookup_allowed whitelist functionality to ModelAdmin

[Django]

#17985: Add additional lookup_allowed whitelist functionality to ModelAdmin
---+
 Reporter:  3point2|  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Right now, as a result of the security fix introduced in r15031, the only
 way to allow querystring lookups across relationships in the admin is to
 whitelist them by including them in list_filter.

 However, in my application the lookup that needs to be whitelisted
 generates a huge filter widget as it contains thousands of instances.

 It would be helpful if I could whitelist the exact lookup I need to link
 to without having to generate the filter widget itself.

 Something like
 {{{
 class MyModelAdmin(ModelAdmin):
 allow_lookup = ["fieldname__id__exact"]
 }}}

 would do. If the developers agree this is useful functionality, I could
 write 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.

[Django] #17984: admin list_filter security fix doesn't allow 'pk' lookups in query string

[Django]

#17984: admin list_filter security fix doesn't allow 'pk' lookups in query 
string
---+
 Reporter:  3point2|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Let's say I have a Payment model containing a received_by field that is a
 !ForeignKey to a Customer model.

 Now I add this to my Payment !ModelAdmin:
 {{{
 list_filter = ["received_by"]
 }}}

 If I use a query string like "?received_by!__id!__exact=2" on the payment
 changelist view, there is no problem. This is the form that the admin
 itself uses for the filter. Using something more implicit like
 "?received_by!__id=2" works fine too.

 However, using "?received_by!__pk=2" raises !SuspiciousOperation. This was
 introduced by the security fix in r15031.

 The lookup_allowed method in admin/options.py explicitly makes an
 exception for "!__id" (or whatever the primary key attribute of the model
 is explicitly called), but it doesn't allow direct use of the 'pk'
 shortcut.

 The point of the security fix was to only allow lookups specified by
 list_filter. However, in its current form it also causes the query string
 syntax to diverge from the documented lookup syntax
 https://docs.djangoproject.com/en/1.4/topics/db/queries/#the-pk-lookup-
 shortcut . I suggest allowing use of the pk shortcut in the query string.

 I would be happy to write a patch for this if the developers agree it
 should be 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] #17733: Default timezone settings are different from the operating systems'

[Django]

#17733: Default timezone settings are different from the operating systems'
-+-
 Reporter:  berdario |Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.4-alpha-1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  timezone | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17809]:
 {{{
 #!CommitTicketReference repository="" revision="17809"
 Fixed #17733 -- Discouraged setting TIME_ZONE to None when USE_TZ is True.
 Thanks berdario for the report.
 }}}

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

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

[Changeset] r17809 - in django/trunk: django/conf/project_template/project_name docs/ref

[noreply]

Author: aaugustin
Date: 2012-03-26 07:17:13 -0700 (Mon, 26 Mar 2012)
New Revision: 17809

Modified:
   django/trunk/django/conf/project_template/project_name/settings.py
   django/trunk/docs/ref/settings.txt
Log:
Fixed #17733 -- Discouraged setting TIME_ZONE to None when USE_TZ is True. 
Thanks berdario for the report.


Modified: django/trunk/django/conf/project_template/project_name/settings.py
===
--- django/trunk/django/conf/project_template/project_name/settings.py  
2012-03-25 19:04:11 UTC (rev 17808)
+++ django/trunk/django/conf/project_template/project_name/settings.py  
2012-03-26 14:17:13 UTC (rev 17809)
@@ -23,10 +23,7 @@
 # Local time zone for this installation. Choices can be found here:
 # http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
 # although not all choices may be available on all operating systems.
-# On Unix systems, a value of None will cause Django to use the same
-# timezone as the operating system.
-# If running in a Windows environment this must be set to the same as your
-# system time zone.
+# In a Windows environment this must be set to your system time zone.
 TIME_ZONE = 'America/Chicago'
 
 # Language code for this installation. All choices can be found here:

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2012-03-25 19:04:11 UTC (rev 17808)
+++ django/trunk/docs/ref/settings.txt  2012-03-26 14:17:13 UTC (rev 17809)
@@ -2131,8 +2131,10 @@
   :ref:`manually configuring settings
   `, or
 
-* If you specify ``TIME_ZONE = None``. This will cause Django to fall
-  back to using the system time zone.
+* If you specify ``TIME_ZONE = None``. This will cause Django to fall back to
+  using the system timezone. However, this is discouraged when :setting:`USE_TZ
+  = True `, because it makes conversions between local time and UTC
+  less reliable.
 
 If Django doesn't set the ``TZ`` environment variable, it's up to you
 to ensure your processes are running in the correct environment.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, 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] #17419: JSON template tag

[Django]

#17419: JSON template tag
-+-
 Reporter:  lau  |Owner:  aaugustin
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  json template tag| Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * easy:  1 => 0
 * stage:  Accepted => Design decision needed


Comment:

 When the output isn't marked safe, indeed, `{{ foobar|json }}` will fail
 whenever `foobar` contains strings. But I don't think Django can or should
 do something about this fact. If the output were arbitrarily (and wrongly)
 marked safe, that would defeat Django's anti-XSS protection.

 Let's just try this with some interesting values of `a`:
 {{{
 var a = {{ a|json }};
 }}}

 For instance:
 {{{
 var a =
 "fooalert('pwnd!');bar;"
 }}}

 Wrapping with CDATA doesn't help:
 {{{
 alert('pwnd!');
 }}}

 Per the "Don't Give Users Guns Aimed At Feet", this isn't possible.

 

 So I hesitate between two alternatives at this point:
 - add the filter with safety-by-default, and explain in the docs that if
 you have a problem with quotes being escaped, you should use another
 technique — like loading the data via AJAX — or carefully escape all the
 strings that end up in you data structure and add `|safe` in your
 template.
 - not add the filter at all, because the only implementation we can afford
 (the safe one) isn't useful enough.

 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] #17980: Tests fail when i18n set to True.

[Django]

#17980: Tests fail when i18n set to True.
--+
 Reporter:  wassup|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by wassup):

 It spits out 'en'. Additionally, I thought it shall be fixed in one place,
 but apparently we're progressing on the bug by bug way. Thus, there are a
 couple of more to go that also fail on an already translated string:

 {{{
 ==
 FAIL: test_password_change_fails_with_invalid_old_password
 (django.contrib.auth.tests.views.ChangePasswordTest)
 --
 Traceback (most recent call last):
   File "/usr/lib/python2.7/site-
 packages/django/contrib/auth/tests/views.py", line 209, in
 test_password_change_fails_with_invalid_old_password
 self.assertContainsEscaped(response,
 PasswordChangeForm.error_messages['password_incorrect'])
   File "/usr/lib/python2.7/site-
 packages/django/contrib/auth/tests/views.py", line 54, in
 assertContainsEscaped
 return self.assertContains(response, escape(force_unicode(text)),
 **kwargs)
   File "/usr/lib/python2.7/site-packages/django/test/testcases.py", line
 637, in assertContains
 msg_prefix + "Couldn't find '%s' in response" % text)
 AssertionError: Couldn't find 'Podane stare hasło jest niepoprawne. Proszę
 podać je jeszcze raz.' in response

 ==
 FAIL: test_password_change_fails_with_mismatched_passwords
 (django.contrib.auth.tests.views.ChangePasswordTest)
 --
 Traceback (most recent call last):
   File "/usr/lib/python2.7/site-
 packages/django/contrib/auth/tests/views.py", line 219, in
 test_password_change_fails_with_mismatched_passwords
 self.assertContainsEscaped(response,
 SetPasswordForm.error_messages['password_mismatch'])
   File "/usr/lib/python2.7/site-
 packages/django/contrib/auth/tests/views.py", line 54, in
 assertContainsEscaped
 return self.assertContains(response, escape(force_unicode(text)),
 **kwargs)
   File "/usr/lib/python2.7/site-packages/django/test/testcases.py", line
 637, in assertContains
 msg_prefix + "Couldn't find '%s' in response" % text)
 AssertionError: Couldn't find 'Hasła się nie zgadzają.' in response

 ==
 FAIL: test_password_change_succeeds
 (django.contrib.auth.tests.views.ChangePasswordTest)
 --
 Traceback (most recent call last):
   File "/usr/lib/python2.7/site-
 packages/django/contrib/auth/tests/views.py", line 230, in
 test_password_change_succeeds
 self.fail_login()
   File "/usr/lib/python2.7/site-
 packages/django/contrib/auth/tests/views.py", line 196, in fail_login
 self.assertContainsEscaped(response,
 AuthenticationForm.error_messages['invalid_login'])
   File "/usr/lib/python2.7/site-
 packages/django/contrib/auth/tests/views.py", line 54, in
 assertContainsEscaped
 return self.assertContains(response, escape(force_unicode(text)),
 **kwargs)
   File "/usr/lib/python2.7/site-packages/django/test/testcases.py", line
 637, in assertContains
 msg_prefix + "Couldn't find '%s' in response" % text)
 AssertionError: Couldn't find 'Proszę wpisać poprawną nazwę użytkownika i
 hasło. Uwaga: wielkość liter ma znaczenie.' in response


 }}}

-- 
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] #17982: please unbundle jquery

[Django]

#17982: please unbundle jquery
---+--
 Reporter:  mrunge@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 Not having external dependencies is a design choice of Django.

 This has been discussed in the utmost detail in the past. Like jezdez, the
 decision is to keep jQuery bundled in the admin, and namespace it.

 I'm sorry, but this isn't going to change.

-- 
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] #17980: Tests fail when i18n set to True.

[Django]

#17980: Tests fail when i18n set to True.
--+
 Reporter:  wassup|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 OK, now the question is which language is active when the proxy string is
 translated to the real string. It should be 'en' and apparently it is not.
 Could you also debug the current language in the test ({{{from
 django.utils.translation import get_language; print get_language()}}})?

 If it is not 'en', it may be that you are modifying the current language
 somewhere in your code, either in a view or in a middleware.

-- 
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] #17983: Command line example for symbolic link may cause problems

[Django]

#17983: Command line example for symbolic link may cause problems
---+
 Reporter:  Anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 On this page: https://docs.djangoproject.com/en/1.4/topics/install/

 The command line "ln -s WORKING-DIR/django-trunk/django/bin/django-
 admin.py /usr/local/bin"
 is suggested. This creates a linked file named "bin" inside /usr/local/,
 instead of creating a link inside the directory /usr/local/bin/.

 The suggested command line should be "ln -s WORKING-DIR/django-
 trunk/django/bin/django-admin.py /usr/local/bin/"
 (slash on the end).

-- 
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] #17926: XMLField removed in 1.4 but still documented

[Django]

#17926: XMLField removed in 1.4 but still documented
---+--
 Reporter:  aburgel|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 See comment:1, removal of deprecated objects are not in release notes.

-- 
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] #17982: please unbundle jquery

[Django]

#17982: please unbundle jquery
---+--
 Reporter:  mrunge@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Kudlaty):

 with that system, i think we need to add some django core settings or
 smth' like that, to mark django-jquery package as required...

 problems also can occur when we upgrade jquery package, and admin panel
 will get bugged cos new jquery remove or changed some function that we use
 in admin panel...

-- 
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] #17982: please unbundle jquery

[Django]

#17982: please unbundle jquery
---+--
 Reporter:  mrunge@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by mrunge@…):

 Replying to [comment:2 Kudlaty]:
 > maybe we should create something like stand alone package django-jquery,
 > wich will be pre-installed.
 >
 > so, with that we will get possibility to upgrade jquery package, and not
 django :)
 > but, ofc django-jquery package should be on djangoproject repository
 > and cos of that, we need to add command to check for upgrade and upgrade
 package
 >
 >
 > For futher, this system can be used to split django into small packages
 like jquery, orm, auth, and more :)

 something like this was my intention. Another point: when there is a
 security flaw, you just have to update one package, not a bunch of
 packages.

-- 
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] #17982: please unbundle jquery

[Django]

#17982: please unbundle jquery
---+--
 Reporter:  mrunge@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Kudlaty):

 maybe we should create something like stand alone package django-jquery,
 wich will be pre-installed.

 so, with that we will get possibility to upgrade jquery package, and not
 django :)
 but, ofc django-jquery package should be on djangoproject repository
 and cos of that, we need to add command to check for upgrade and upgrade
 package


 For futher, this system can be used to split django into small packages
 like jquery, orm, auth, and more :)

-- 
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] #17980: Tests fail when i18n set to True.

[Django]

#17980: Tests fail when i18n set to True.
--+
 Reporter:  wassup|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by wassup):

 Again a formatting problem. I meant:
 {{{
 SetPasswordForm.error_messages['password_mismatch']
 }}}

-- 
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] #17980: Tests fail when i18n set to True.

[Django]

#17980: Tests fail when i18n set to True.
--+
 Reporter:  wassup|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by wassup):

 @jezdez: Sorry - tried to edit it after posting, but it was not possible.
 My fault.

 @claudep: SetPasswordForm.error_messages['password_mismatch'] beffore
 assert is a proxy object: . When I treat it with a loop to get the content, the string is
 already translated to: 'Hasła się nie zgadzają.'

-- 
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] #16250: Error with new pyscopg2 2.4.2 release and tests

[Django]

#16250: Error with new pyscopg2 2.4.2 release and tests
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by anonymous):

 This is a psycopg2 bug:
 http://psycopg.lighthouseapp.com/projects/62710/tickets/53

-- 
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] #16250: Error with new pyscopg2 2.4.2 release and tests

[Django]

#16250: Error with new pyscopg2 2.4.2 release and tests
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by zap.aibulatov@…):

 I have installed psycopg2==2.4.1 via pip on my virtualenv, and now i have
 this error:

 {{{
 Traceback (most recent call last):
   File "./manage.py", line 9, in 
 execute_from_command_line(sys.argv)
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 429, in
 execute_from_command_line
 utility.execute()
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 261, in fetch_command
 klass = load_command_class(app_name, subcommand)
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 67, in
 load_command_class
 module = import_module('%s.management.commands.%s' % (app_name, name))
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/utils/importlib.py", line 35, in import_module
 __import__(name)
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/south/management/commands/__init__.py", line 10, in 
 import django.template.loaders.app_directories
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/template/loaders/app_directories.py", line 21, in 
 mod = import_module(app)
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/utils/importlib.py", line 35, in import_module
 __import__(name)
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/contrib/admin/__init__.py", line 3, in 
 from django.contrib.admin.helpers import ACTION_CHECKBOX_NAME
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/contrib/admin/helpers.py", line 3, in 
 from django.contrib.admin.util import (flatten_fieldsets,
 lookup_field,
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/contrib/admin/util.py", line 1, in 
 from django.db import models
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/db/__init__.py", line 78, in 
 connection = connections[DEFAULT_DB_ALIAS]
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/db/utils.py", line 93, in __getitem__
 backend = load_backend(db['ENGINE'])
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/db/utils.py", line 33, in load_backend
 return import_module('.base', backend_name)
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/utils/importlib.py", line 35, in import_module
 __import__(name)
   File "/home/set/Envs/ruelsoft.com/local/lib/python2.7/site-
 packages/django/db/backends/postgresql_psycopg2/base.py", line 24, in
 
 raise ImproperlyConfigured("Error loading psycopg2 module: %s" % e)
 django.core.exceptions.ImproperlyConfigured: Error loading psycopg2
 module: can't import mx.DateTime module
 }}}

-- 
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] #15013: Add Russian (ru) local flavour

[Django]

#15013: Add Russian (ru) local flavour
-+-
 Reporter:  blackraven   |Owner:
 Type:  New feature  |  blackraven
Component:  contrib.localflavor  |   Status:  closed
 Severity:  Normal   |  Version:  SVN
 Keywords:  localflavor russian  |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Cjkjvfnby@…):

 * ui_ux:   => 0


Comment:

 It is strange field name: "alien passport".
 Propably it is should be "foreign passport". (This is second passport of
 russian sitizen. It is used to cross borders and outside Russia)

-- 
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] #17980: Tests fail when i18n set to True.

[Django]

#17980: Tests fail when i18n set to True.
--+
 Reporter:  wassup|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Old description:

> Hi,
>
> When i18n is set to True and project language is not English, some of the
> default django tests do not pass (it worked fine in 1.3). I believe the
> reason is that the messages get translated and localized before the tests
> are run, which results in e.g.:
>

> ==
> FAIL: test_unusable_password
> (django.contrib.auth.tests.forms.PasswordResetFormTest)
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-
> packages/django/contrib/auth/tests/forms.py", line 336, in
> test_unusable_password
> [u"The user account associated with this e-mail address cannot reset
> the password."])
> AssertionError: [u'U\u017cytkownik, kt\xf3rego konto powi\u0105zane jest
> z tym adresem e-mail nie mo\u017ce zresetowa\u0107 has\u0142a.'] !=
> [u'The user account associated with this e-mail address cannot reset the
> password.']
>
> ==
> FAIL: test_confirm_different_passwords
> (django.contrib.auth.tests.views.PasswordResetTest)
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-
> packages/django/contrib/auth/tests/views.py", line 184, in
> test_confirm_different_passwords
> self.assertContainsEscaped(response,
> SetPasswordForm.error_messages['password_mismatch'])
>   File "/usr/lib/python2.7/site-
> packages/django/contrib/auth/tests/views.py", line 54, in
> assertContainsEscaped
> return self.assertContains(response, escape(force_unicode(text)),
> **kwargs)
>   File "/usr/lib/python2.7/site-packages/django/test/testcases.py", line
> 637, in assertContains
> msg_prefix + "Couldn't find '%s' in response" % text)
> AssertionError: Couldn't find 'Hasła się nie zgadzają.' in response
>
> ==
> FAIL: test_email_not_found
> (django.contrib.auth.tests.views.PasswordResetTest)
> Error is raised if the provided email address isn't currently registered
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-
> packages/django/contrib/auth/tests/views.py", line 91, in
> test_email_not_found
> self.assertContainsEscaped(response,
> PasswordResetForm.error_messages['unknown'])
>   File "/usr/lib/python2.7/site-
> packages/django/contrib/auth/tests/views.py", line 54, in
> assertContainsEscaped
> return self.assertContains(response, escape(force_unicode(text)),
> **kwargs)
>   File "/usr/lib/python2.7/site-packages/django/test/testcases.py", line
> 637, in assertContains
> msg_prefix + "Couldn't find '%s' in response" % text)
> AssertionError: Couldn't find 'Ten adres e-mail nie ma przypisanego
> konta. Jesteś pewien, że zarejestrowałeś się?' in response
>
> --
>
> I believe the default django tests should not be run against the
> localized strings or am I missing something?
>
> Regards,
>
> wassup

New description:

 Hi,

 When i18n is set to True and project language is not English, some of the
 default django tests do not pass (it worked fine in 1.3). I believe the
 reason is that the messages get translated and localized before the tests
 are run, which results in e.g.:

 {{{
 ==
 FAIL: test_unusable_password
 (django.contrib.auth.tests.forms.PasswordResetFormTest)
 --
 Traceback (most recent call last):
   File "/usr/lib/python2.7/site-
 packages/django/contrib/auth/tests/forms.py", line 336, in
 test_unusable_password
 [u"The user account associated with this e-mail address cannot reset
 the password."])
 AssertionError: [u'U\u017cytkownik, kt\xf3rego konto powi\u0105zane jest z
 tym adresem e-mail nie mo\u017ce zresetowa\u0107 has\u0142a.'] != [u'The
 user account associated with this e-mail address cannot reset the
 password.']

 ==
 FAIL: test_confirm_different_passwords

Re: [Django] #17982: please unbundle jquery

[Django]

#17982: please unbundle jquery
---+--
 Reporter:  mrunge@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by jezdez):

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


Comment:

 jQuery is used internally in the admin only and is properly namespaced as
 `django.jQuery`. Django relies on it as a library for some of the admin
 widgets, so unbundling would make using the Django admin much harder than
 it should be.

-- 
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] #17982: please unbundle jquery

[Django]

#17982: please unbundle jquery
---+
 Reporter:  mrunge@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 There's jquery 1.4.2 included for admin-interface. Current jquery is
 version 1.7.2. I guess, most django sites already have jquery in modern
 versions included, there's no need for django to bundle this.

 From a system integration point of view: I'd like to update/patch jquery
 by updating one package and don't want to know, framework a includes
 jquery, framework ... uses it, too. As a conclusion, this is a nice
 feature, one wants to have.

-- 
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] #5373: Field label for a ForeignKey not translated

[Django]

#5373: Field label for a ForeignKey not translated
-+-
 Reporter:  Szilveszter Farkas   |Owner:  Fandekasp
   |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:   |   Resolution:
  Internationalization   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  i18n foreignkey  |  Patch needs improvement:  0
  field label|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by claudep):

 Thanks. Now even if it might not be broken currently, I think it would
 still be worth to test when the ForeignKey definition has a verbose_name
 (should have priority over related model verbose_name).

-- 
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] #17980: Tests fail when i18n set to True.

[Django]

#17980: Tests fail when i18n set to True.
--+
 Reporter:  wassup|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_better_patch:   => 0
 * component:  Testing framework => contrib.auth
 * needs_tests:   => 0
 * keywords:   => tests
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I can confirm the bug in test_unusable_password (the tested string should
 be translated itself).

 However I'm unable to reproduce the !PasswordResetTest errors, as the
 !AuthViewsTestCase parent test case is setting 'en' as default language.
 Could you debug `test_confirm_different_passwords` and check if
 `SetPasswordForm.error_messages['password_mismatch']` is a proxy string
 before the assert statement?

-- 
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] #17926: XMLField removed in 1.4 but still documented

[Django]

#17926: XMLField removed in 1.4 but still documented
---+--
 Reporter:  aburgel|Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Documentation  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Bradley Ayers ):

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


Comment:

 This hasn't resolved the issue of it not being mentioned in the Django 1.4
 release notes.

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