Re: [Django] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
---+
 Reporter:  minarets   |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  contrib.admin  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by anonymous):

 * version:  1.2 => 1.3


Comment:

 The above fix (13614.filterselect-webkit-bug.2.diff) does not work for
 Chrome 15.0.874.121 and Django 1.3.1.
 If you navigate from the admin page, that contains SelectFilter2, to some
 other page and than click 'back' button - SelectFilter2 preserves values -
 this is good. But if you decide to change SelectFilter2 values and hit
 'save' - it does not save changes. Am I the only 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] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
--+
 Reporter:  etianen   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  SVN
 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
--+

Comment (by Kronuz):

 I'm working in polymorphic models (django_polymorphic) and I'm adding
 proxied polymorphic models... this is also a problem in this case, where
 I'm in the need to have content types for proxied models as well.

-- 
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] #17251: select_for_update tests threads should close connections manually

[Django]

#17251: select_for_update tests threads should close connections manually
--+
 Reporter:  akaariai  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Uncategorized |  Version:
 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 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] #17289: mysql 'commands out of sync' error when calling stored procedure

[Django]

#17289: mysql 'commands out of sync' error when calling stored procedure
---+--
 Reporter:  candlerb   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 This is a documented behavior of MySQLdb:
 > Compatibility note: It appears that the mere act of executing the CALL
 statement produces an empty result set, which appears after any result
 sets which might be generated by the stored procedure. Thus, you will
 always need to use nextset() to advance result sets.
 (http://mysql-python.sourceforge.net/MySQLdb.html)

 So, even though an exception was raised in Django when it tried to use the
 database connection again, the bug was in your application code, and you
 found the correct fix.

-- 
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] #3011: Allow for extendable auth_user module

[Django]

#3011: Allow for extendable auth_user module
---+
 Reporter:  nowell strite  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:
 Severity:  Normal |   Resolution:
 Keywords:  auth_user  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 #17254 was a duplicate.

-- 
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] #17254: ModelBackend should have a get_anonymous_user method

[Django]

#17254: ModelBackend should have a get_anonymous_user method
+--
 Reporter:  riccardodivirgilio  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by aaugustin):

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


Comment:

 I confirm that introducing a customizable User, Permission, or
 !AnonymousUser model is in the realm of #3011. Some comments on that
 ticket discuss !AnonymousUser specifically.

 The fact that #3011 is still open means that the community agrees that
 Django should let developers use a custom class instead of User and
 !AnonymousUser, and possibly customize other parts of
 `django.contrib.auth`. We just haven't figured out a complete solution
 without unacceptable drawbacks yet.

 On a side note, please upload patches in unified diff format (that's what
 `svn diff` or `diff -u` produces) — it's much easier to read in Trac.

-- 
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] #17286: All cache backends need to call its 'close' function

[Django]

#17286: All cache backends need to call its 'close' function
-+
 Reporter:  jifeng.yin@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  SVN
 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):

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


Comment:

 Like all database connections are closed at the end of each request, all
 cache connections should be closed.

-- 
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] #17151: Rename 'wizard_prev_step' in NamedUrlWizardView

[Django]

#17151: Rename 'wizard_prev_step' in NamedUrlWizardView
-+-
 Reporter:  Bradley Ayers|Owner:  nobody
|   Status:  new
 Type:   |  Version:  SVN
  Cleanup/optimization   |   Resolution:
Component:  contrib.formtools| Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * easy:  1 => 0


Comment:

 `wizard_next_step` seems confusing to me too, because the primary use of
 this feature is to return to a previous step. I believe that in the vast
 majority of cases, users will fill in a form wizard linearly, even if the
 order isn't enforce by the application.

 One could make an argument for `wizard_goto_step`. I can't really convince
 myself that it's a better name. In this case, a name that describes the
 most common case feels more appropriate than a technically accurate 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] #17219: Add a more precise description to some db fields.

[Django]

#17219: Add a more precise description to some db fields.
--+
 Reporter:  charettes |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Translations  |  Version:
 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):

 * stage:  Unreviewed => Accepted


Comment:

 I confirm that `description` is only used by the `admindocs` contrib app —
 at least, as far as I can tell. This app is targeted at developers, not
 end users.

-- 
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] #14757: Add An Example For .extra(tables=[])

[Django]

#14757: Add An Example For .extra(tables=[])
-+-
 Reporter:  mikeshultz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  documentation extra  | Triage Stage:  Accepted
  tables |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by krzysiumed):

 Is this note necessary? I can't find any useful example of using
 `extra(where=...)` - everything can be done with `objects.filter`. I
 suggest to close this ticket.

-- 
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] #17149: MediaDefiningClass not used as base class for other form meta classes

[Django]

#17149: MediaDefiningClass not used as base class for other form meta classes
--+
 Reporter:  bradley.ayers@…   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  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):

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


Comment:

 This code is duplicated in the `__new__` method of these classes:

 {{{
 if 'media' not in attrs:
 new_class.media = media_property(new_class)
 }}}

-- 
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] #17066: Exception TypeError when using GeoIP

[Django]

#17066: Exception TypeError when using GeoIP
+
 Reporter:  mitar   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  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):

 * 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] #16454: sequence for AUTH_PERMISSION.ID

[Django]

#16454: sequence for AUTH_PERMISSION.ID
-+-
 Reporter:  alexei.vlassov@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  needsinfo
 Severity:  Release blocker  | Triage Stage:
 Keywords:  oracle   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 This was reported again and diagnosed in #17015.

-- 
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] #17015: IntegrityError: ORA-01400: cannot insert NULL into (...."AUTH_PERMISSION"."ID") when running syncdb with Oracle

[Django]

#17015: IntegrityError: ORA-01400: cannot insert NULL into
("AUTH_PERMISSION"."ID")  when running syncdb with Oracle
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle, trigger  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Accepting ticket based on Ian's comment.

-- 
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] #17237: Format {% debug %} tag output as JSON

[Django]

#17237: Format {% debug %} tag output as JSON
-+-
 Reporter:  sdeleon28@…  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Template system  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  debug template tag   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 The `{% debug %}` tag outputs Python code, whose dictionary syntax is
 close to JSON. Changing this tag to output JSON would be backwards-
 incompatible.

 However, it's implemented in less than 10 lines; you can easily copy it in
 your app and change it to output JSON.

 Or just use the [http://pypi.python.org/pypi/django-debug-toolbar Django
 debug toolbar] :)

-- 
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] #17221: `manage.py` (do not) sends ANSI escape sequences when terminal (can) can't handle them

[Django]

#17221: `manage.py` (do not) sends ANSI escape sequences  when terminal (can) 
can't
handle them
-+-
 Reporter:  rabio|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 I agree that Django's detection for color support in terminals isn't
 perfect in theory. However, this isn't a core functionality of the
 framework at all, and the current implementation appears to work
 sufficiently well in practice.

 Could you describe a reasonable use case where the current code fails? If
 it works fine in most cases, I won't feel a compelling need to re-
 implement it.

 Given this, and the lack of precise ideas for improvements or a solid
 patch, I'll close this ticket.

 However, if it's really a problem that occurs in common setups, or you
 have a well-tested patch that improves a realistic use case, I'd be glad
 to revisit this decision.

-- 
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] #17278: Unlike sqlite, spatialite requires NAME to be set to run the tests

[Django]

#17278: Unlike sqlite, spatialite requires NAME to be set to run the tests
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:
 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):

 * 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] #17246: title localization

[Django]

#17246: title localization
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  contrib.admin|   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  title main.py|  Unreviewed
  base.html  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 I'm sorry, but I don't grasp how the change you're proposing resolves the
 problem.

 Won't `{{ title }}` still be defined by the `verbose_name` of your model?

 Did I miss something?

-- 
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] #17239: mark_safe(media) in django admin Opzioni

[Django]

#17239: mark_safe(media) in django admin Opzioni
--+
 Reporter:  riccardodivirgilio|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:  mark_safe media   | 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
 * stage:  Unreviewed => Accepted
 * type:  Bug => Cleanup/optimization
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Indeed:
 - `changelist_view` passes an instance of `forms.Media` in the context,
 and `admin/change_list.html` renders separately `{{ media.css }}` and `{{
 media.js }}`;
 - `add_view` and `change_view` passes a string, rendered as a side effect
 of calling `mark_safe`, and `admin/change_form.html` renders directly `{{
 media }}`.

 It could be worth to resolve this inconsistency, which appeared at r10077
 and doesn't seem justified.

-- 
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] #17231: Use djangoproject.com color theme in django-admin template

[Django]

#17231: Use djangoproject.com color theme in django-admin template
-+-
 Reporter:  benjaoming   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3-rc1
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


-- 
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] #17133: get_script_name goofs when there is Apache URL rewriting

[Django]

#17133: get_script_name goofs when there is Apache URL rewriting
---+--
 Reporter:  gjanee@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 While it's clear that something's wrong in your setup, I'm unable to
 confirm that there's a bug in Django, and determine how we could fix it,
 sorry.

 You might be exceeding the limits of how much `mod_rewrite` magic Django
 can compensate for; if so, you can work around the problem with the
 `FORCE_SCRIPT_NAME` setting.

 If we wanted to debug this further, we'd need the values of the relevant
 environment variables, especially `SCRIPT_URL`, `REDIRECT_URL`,
 `PATH_INFO`, `SCRIPT_NAME`, as well as the relevant bits of your Apache
 configuration.

-- 
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] #17187: Incompatibility with Cherokee webserver's FastCGI handling

[Django]

#17187: Incompatibility with Cherokee webserver's FastCGI handling
-+-
 Reporter:  sciyoshi |Owner:  sam@…
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  cherokee flup| Triage Stage:
  fastcgi fcgi content-length uwsgi  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 It looks like this part of the code changed heavily since Django 1.3, the
 patch doesn't apply.

 Based on code inspection, I'd say this problem can't happen anymore --
 from `WSGIRequest.__init__`:
 {{{
 try:
 content_length = int(self.environ.get('CONTENT_LENGTH'))
 except (ValueError, TypeError):
 content_length = 0
 self._stream = LimitedStream(self.environ['wsgi.input'],
 content_length)
 }}}

 If it still occurs on trunk, could you reopen the ticket and provide a
 test case? (or at least simple steps to reproduce the problem, involving
 as few third-party tools as possible).

-- 
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] #17102: Add SSL-redirect middleware to better support all-SSL sites

[Django]

#17102: Add SSL-redirect middleware to better support all-SSL sites
--+
 Reporter:  carljm|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  SVN
 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):

 * 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] #17103: Add HTTP Strict Transport Security support, to improve support for all-SSL sites

[Django]

#17103: Add HTTP Strict Transport Security support, to improve support for 
all-SSL
sites
---+
 Reporter:  carljm |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  SVN
 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):

 * 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] #17212: django.contrib.gis.geos.error.GEOSException: Could not parse version info string "3.4.0dev-CAPI-1.8.0"

[Django]

#17212: django.contrib.gis.geos.error.GEOSException: Could not parse version 
info
string "3.4.0dev-CAPI-1.8.0"
+
 Reporter:  strk@…  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


Comment:

 Note that you should generate your patch from the "trunk" directory to
 avoid ambiguities.

-- 
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] #17212: django.contrib.gis.geos.error.GEOSException: Could not parse version info string "3.4.0dev-CAPI-1.8.0"

[Django]

#17212: django.contrib.gis.geos.error.GEOSException: Could not parse version 
info
string "3.4.0dev-CAPI-1.8.0"
+
 Reporter:  strk@…  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by aaugustin):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Looks good to me.

 Generally, each patch must include tests, but in this case, I sounds
 overkill. I'll defer to the GIS maintainer to decide.

-- 
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] #17217: Set nbsp instead of space as thousand separator

[Django]

#17217: Set nbsp instead of space as thousand separator
--+
 Reporter:  fadeyev   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Translations  |  Version:
 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):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 I'd be nice to check the typographical conventions of the 8 countries
 involved in this patch, just to be sure that NBSP is the proper character
 — there are other variants of SP.

 That said, I can't imagine a reason why a SP would be better than a NBSP
 as thousand separator. The only difference is that the latter prevents
 line wrapping, and line wrapping in the middle of a number can't be
 correct.

 If we wanted to follow this logic entirely, we should also patch
 `docs/topics/i18n/formatting.txt`.

-- 
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] #17231: Use djangoproject.com color theme in django-admin template

[Django]

#17231: Use djangoproject.com color theme in django-admin template
-+-
 Reporter:  benjaoming   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3-rc1
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 I'm quite reluctant to change the look of the admin just for the sake of
 it.

 Do we want every Django developer to explain to his clients why the look
 of their backend changed?

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

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

Re: [Django] #17298: Error: No module named filterspecs

[Django]

#17298: Error: No module named filterspecs
-+--
 Reporter:  Keats|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  SVN
 Severity:  Release blocker  |   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 anonymous):

 ok founded the bug

 from django.contrib.admin.filterspecs import FilterSpec

 no longer exists

 thanx

-- 
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] #17298: Error: No module named filterspecs

[Django]

#17298: Error: No module named filterspecs
-+--
 Reporter:  Keats|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  SVN
 Severity:  Release blocker  |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by aaugustin):

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


Comment:

 This looks like an error in your application's code: it imports a module
 that doesn't exist, or with the wrong path.

 If you need support on this issue, I suggest asking on the #django IRC
 channel on Freenode or on the django-users mailing list, since it isn't a
 bug in Django itself. If Django had a bug that caused both `manage.py
 runserver` and `manage.py test` to fail unconditionally, we'd know it :)

-- 
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] r17149 - django/trunk/docs

[noreply]

Author: aaugustin
Date: 2011-11-25 11:40:46 -0800 (Fri, 25 Nov 2011)
New Revision: 17149

Modified:
   django/trunk/docs/index.txt
Log:
Fixed #16277 -- Changed the link to the IRC logs.


Modified: django/trunk/docs/index.txt
===
--- django/trunk/docs/index.txt 2011-11-25 09:25:43 UTC (rev 17148)
+++ django/trunk/docs/index.txt 2011-11-25 19:40:46 UTC (rev 17149)
@@ -28,7 +28,7 @@
 .. _archives of the django-users mailing list: 
http://groups.google.com/group/django-users/
 .. _post a question: http://groups.google.com/group/django-users/
 .. _#django IRC channel: irc://irc.freenode.net/django
-.. _IRC logs: http://botland.oebfare.com/logger/django/
+.. _IRC logs: http://django-irc-logs.com/
 .. _ticket tracker: http://code.djangoproject.com/
 
 First steps

-- 
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] #16277: Links to IRC Log bot don't work

[Django]

#16277: Links to IRC Log bot don't work
-+-
 Reporter:  micha_el2003@…   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Djangoproject.com|  Version:  1.3
  Web site   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by aaugustin):

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


Comment:

 In [17149]:
 {{{
 #!CommitTicketReference repository="" revision="17149"
 Fixed #16277 -- Changed the link to the IRC logs.
 }}}

-- 
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] #17298: Error: No module named filterspecs

[Django]

#17298: Error: No module named filterspecs
-+
 Reporter:  Keats|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Other) |Version:  SVN
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Hi,

 the stable version 1.3.1 is bugged for testing with multidb when we try to
 test :
 it was patched in https://code.djangoproject.com/ticket/16828

 but trunk is bugged also but for everything :
 $python manage.py test
 Error: No module named filterspecs


 $python manage.py runserver
 Error: No module named filterspecs

 thanx

-- 
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] #17293: Link to irc log timeout

[Django]

#17293: Link to irc log timeout
---+--
 Reporter:  svleeuwen  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  logs irc   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 Dupe of #16277.

-- 
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] #17295: Admin "View" permission

[Django]

#17295: Admin "View" permission
-+-
 Reporter:  danny.adair@…|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  admin readonly   | Triage Stage:
  permission |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Thanks - I was sure there was at least one ticket about this but couldn't
 find it

-- 
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] #17297: Medical Assistants | Link building services | Medical billing and coding

[Django]

#17297: Medical Assistants | Link building services | Medical billing and coding
-+-
 Reporter:   |  Owner:  nobody
  anonymous  | Status:  new
 Type:   |Version:
  Uncategorized  |   Keywords:  Medical Assistants, Link building
Component:   |  services, Medical billing and coding
  Uncategorized  |  Has patch:  0
 Severity:  Normal   |  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 Medical care co-workers will be major persons in every doctor's offices,
 doctors plus well-being procedure blocks. Sometimes it is given that,
 occupation criteria to get health co-workers would probably call for an
 easy number of chores this includes management, entry office environment
 plus health. [http://bestmedicalassistantjobs.com/ Medical assistants] can
 even be allowed present be an aid to your doctor, even if endeavor
 prevalent tests plus furnishing demanded points so that you can attendees
 plus clients, about the business methods while using the medical. There
 does exist major sales of healthcare admin positions at present, resulting
 from a person's surge in range of people together with the necessity for
 timely plus more significant health aid. Medical-related co-workers
 without any doubt contain a fast paced working day plus, the running
 working hours in many doctor's offices and also doctors, are usually not
 resolved and consequently, healthcare co-workers might possibly
 occasionally, really need to improve very long working hours and not using
 a great amount enjoyment. Taking into consideration your need to get
 health jobs when health similar co-workers, I produced a wide health-
 related admin occupation criteria.Occupation Criteria: Medical care
 Assistants expressed in advance of, any adverse health admin ought to do
 diverse assignments. Occupation criteria to get medical care admin with
 like a number of assignments is usually researched less than.
 [http://www.thefutureofbellydance.com/videos/uprofile.php?UID=1093 medical
 billing and coding]


 At present many people are performing by on line. To get performing by on
 line it's important to take into consideration certain items for instance
 Promotion your Web web-site, Web-site Repair, Pleasing Jobs, Marketing and
 advertising your web blog plus Pagerank deliver the results etcetera. And
 various biggest element will be to employ a [http://onlineseoservices.net
 /link-building-services/ link building services] to get promotion your web
 blog on the net look motor. It assists people around bringing in extra
 pure visitors your web web-site. A very good building back links service
 is vitally important in your achievements.

-- 
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] #17283: Adding Human Readable Name to forms.DateField with input_formats option causes input_format to complain about multiple values for input_formats

[Django]

#17283: Adding Human Readable Name to forms.DateField with input_formats option
causes input_format to complain about multiple values for input_formats
-+-
 Reporter:   |Owner:  nobody
  amit.prakash.ambasta@… |   Status:  closed
 Type:  Bug  |  Version:  1.3-rc1
Component:  Forms|   Resolution:  invalid
 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
-+-

Comment (by anonymous):

 My assumption was that they worked similar to model fields. If that is not
 so.. why does the following code work:
  {{{
  #!python
 variable_number = forms.IntegerField( _( 'Human Readable Name'),
 required = False, label = 'Label Name')
  }}}

 Also, what does the string argument "Human Readable Name" represent in
 this case?


 The purpose of human readable field as taken from
 https://docs.djangoproject.com/en/dev/intro/tutorial01/#creating-models
 "You can use an optional first positional argument to a Field to designate
 a human-readable name...and it doubles as documentation"

-- 
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] #17296: staff_login_required decorator redirecting to default Login redirect instead of requested

[Django]

#17296: staff_login_required decorator redirecting  to default Login redirect
instead of requested
---+
 Reporter:  ayarshabeer|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  HTTP handling  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 While I am trying to access staff_required URL in the application it will
 shows admin login page  but after I given login credential it redirect to
 default login redirect page  (account/profile) instead of my requested
 staff page.

 After I went through the  django code I found that in login_required
 decorator (django/contrib/auth/views) there is checking for host
''' netloc = urlparse.urlparse(redirect_to)[1]
 '''
 # Use default setting if redirect_to is empty
 if not redirect_to:
 redirect_to = settings.LOGIN_REDIRECT_URL

 # Security check -- don't allow redirection to a different
 # host.
''' elif netloc and netloc != request.get_host():
 redirect_to = settings.LOGIN_REDIRECT_URL'''

 but this never succeed because staff_required decorator passing
 redirect_to value as request_full_path() and it doesnot contain host 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] #17283: Adding Human Readable Name to forms.DateField with input_formats option causes input_format to complain about multiple values for input_formats

[Django]

#17283: Adding Human Readable Name to forms.DateField with input_formats option
causes input_format to complain about multiple values for input_formats
-+-
 Reporter:   |Owner:  nobody
  amit.prakash.ambasta@… |   Status:  closed
 Type:  Bug  |  Version:  1.3-rc1
Component:  Forms|   Resolution:  invalid
 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 kmtracey):

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


Comment:

 Form fields don't take any non-keyword arguments, and I don't see anywhere
 in the documentation (e.g.
 https://docs.djangoproject.com/en/1.3/ref/forms/fields/#core-field-
 arguments) that implies differently. If that `_('Human Readable Name')` is
 intended to be the field's label, then it needs to be passed as
 `label=_('Human Readable 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] #17283: Adding Human Readable Name to forms.DateField with input_formats option causes input_format to complain about multiple values for input_formats

[Django]

#17283: Adding Human Readable Name to forms.DateField with input_formats option
causes input_format to complain about multiple values for input_formats
-+-
 Reporter:   |Owner:  nobody
  amit.prakash.ambasta@… |   Status:  new
 Type:  Bug  |  Version:  1.3-rc1
Component:  Forms|   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 kmtracey):

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


Old description:

> The following code snippet
>
> from django import forms
> from django.utils.translation import ugettext_lazy as _
>
> class SearchForm( forms.Form):
> d_o_b = forms.DateField( _( 'Human Readable Name'), required=False,
> input_formats=('%d-%m-%Y',))
>
> causes django to complain __init__() got multiple values for keyword
> argument 'input_formats'
>
> while
> d_o_b = form.DateField( required=False, input_formats=('%d-%m-%Y',))
> works fine.

New description:

 The following code snippet

 {{{
 #!python
 from django import forms
 from django.utils.translation import ugettext_lazy as _

 class SearchForm( forms.Form):
 d_o_b = forms.DateField( _( 'Human Readable Name'), required=False,
 input_formats=('%d-%m-%Y',))
 }}}
 causes django to complain `__init__() got multiple values for keyword
 argument 'input_formats'`

 while
 {{{
 #!python
 d_o_b = form.DateField( required=False, input_formats=('%d-%m-%Y',))
 }}}
 works fine.

--

Comment:

 Fixed formatting. Please use WikiFormatting and preview before posting.

-- 
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] #17276: Slow anti-join query against Postgres

[Django]

#17276: Slow anti-join query against Postgres
-+-
 Reporter:  dmitry@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  orm, postgres,   |  Patch needs improvement:  0
  join, anti-join|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 The query is asking for items with no m2m assigned items. Thus a join
 against only the m2m intermediate table should suffice.

 The last join in that chain is not necessary at all. Foreign keys ensure
 that if there is a row in course_students table, then there will be a
 matching row in course table. This means that if the first join yields any
 rows, so must the second join, too. Naturally, if there is no rows in the
 first join, then there will be no rows in the second join, either. The
 last join is not needed, as the null/not null status of the first join
 tells us already if the filter condition is correct or not.

 There is a slight complication because of deferred foreign keys used in
 Django - it is possible to insert a row into course_students table without
 there being a matching row in course table. I don't know if that is
 something Django should guard against. If the user ends up in situation
 where he has a row in the m2m table, but not in the target table, he has
 done something wrong - m2m targets should always be saved into the DB
 first before adding them to m2m collections.

 This complication of deferred foreign keys also make this a hard
 optimization target for databases. Django has an advantage in that even if
 we are using deferred foreign keys, we know that in normal usage the defer
 should not have any effect.

 Sidenote: why exactly are we using deferred foreign keys, not foreign keys
 with DEFERRABLE INITIALLY IMMEDIATE and set them to deferred only when
 needed in fixture loading? Or am I missing some other valid use case for
 deferred foreign keys in Django? If so, that would naturally also make the
 above join-removal optimization invalid.

 Trivial test case included.

-- 
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] #15744: serialization docs improvement

[Django]

#15744: serialization docs improvement
--+
 Reporter:  choj  |Owner:  gumuz
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  docs serialization| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by krzysiumed):

 * needs_better_patch:  1 => 0


Comment:

 Hm, there are some problems with natural key dictionaries connected with
 serialization as well as deserialization.

 Consider the following models.py file:
 {{{
 class PersonManager(models.Manager):
 def get_by_natural_key(self, *args, **kwargs):
 print args, kwargs # just for debug
 #return self.get(first_name=first_name, last_name=last_name) #
 previous version

 class Person(models.Model):
 objects = PersonManager()

 first_name = models.CharField(max_length=100)
 last_name = models.CharField(max_length=100)

 birthdate = models.DateField()

 def natural_key(self):
 return {'first name': self.first_name, 'last name':
 self.last_name} # after applying patch
 #return (self.first_name, self.last_name) # before applying patch

 class Meta:
 unique_together = (('first_name', 'last_name'),)

 class Book(models.Model):
 name = models.CharField(max_length=100)
 author = models.ForeignKey(Person)
 }}}

 First, it works correctly with `json`, but not with `xml`. Produced `xml`
 by typing `serialization.serialize('xml', Book.objects.all(),
 use_natural_keys=True)` is
 {{{
 
 My titlelast
 namefirst name
 }}}
 You can see that the natural key is labels `first name` and `last name`
 instead of values!

 I don't know if there is any problem with serializing with `yaml`.

 There are problems with deserialization too. During deserialization
 `PersonManager.get_by_natural_key` is invoked, but `args` and `kwargs`
 given to this method are:
 {{{
 # these lines are printed by 3rd line of models.py
 (u'last name', u'first name') {} # xml
 ('last name', 'first name') {} # json
 }}}

 I guess that natural key should be tuple and intention of core developers
 was not using dictonaries. Accidentally json serialization works (that's
 undocumented feature :-) ). I suggest to close this ticket - django code
 is correct, doc is compatible, because it says about Person.natural_key
 > That method should always return a natural key tuple ...
 and introduction to natural keys says
 > A natural key is a tuple of values that ...

 [[br]]

 Another question is if normal or unicode strings should be given to
 `PersonManager.get_by_natural_key`. Now, the unicode string is given
 during xml deserialization and normal string is given while json
 deserialization. Is it a bug?

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

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

Re: [Django] #16150: Syndication Feed docs incorrectly describe tag.

[Django]

#16150: Syndication Feed docs incorrectly describe  tag.
---+
 Reporter:  melinath   |Owner:  melinath
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  rss| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by krzysiumed):

 * needs_better_patch:  1 => 0


Comment:

 I improved the `melinath` patch by appling `aaugustin` advices.

-- 
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] #16168: Form validation is bypassed on Admin Inline ModelForms that define extra fields

[Django]

#16168: Form validation is bypassed on Admin Inline ModelForms that define extra
fields
-+-
 Reporter:   |Owner:  nobody
  izzaddin.ruhulessin@…  |   Status:  new
 Type:   |  Version:  SVN
  Cleanup/optimization   |   Resolution:
Component:  Documentation| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  validation,  |  Patch needs improvement:  0
  modelforms |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by krzysiumed):

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


Comment:

 I added backticks around `ValueError` in `PieterSwinkels` 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] #4501: Coverage support for tests

[Django]

#4501: Coverage support for tests
---+--
 Reporter:  bugs@… |Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:
 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 krzysiumed):

 * 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] #17276: Slow anti-join query against Postgres

[Django]

#17276: Slow anti-join query against Postgres
-+-
 Reporter:  dmitry@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  orm, postgres,   |  Patch needs improvement:  0
  join, anti-join|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-
Description changed by ramiro:

Old description:

> For background on this ticket please see the following two discussions:
>
>  * http://stackoverflow.com/questions/8190474/postgres-slow-outer-query-
> when-using-a-primary-key
>  * https://groups.google.com/group/django-
> users/browse_thread/thread/7d13f2d8748b4f9f
>
> Basically, in a many-to-many mappings between models Student and Course,
> if I want to find all instances of Students that aren't registered for
> classes, I would issue the following Django query:
>
> Student.objects.filter(course__isnull=True)
>
> Django translates this into the following query:
>
> SELECT "student"."id", "student"."name"
>FROM "student"
>   LEFT OUTER JOIN "course_students"
>  ON ("student"."id" = "course_students"."student_id")
>   LEFT OUTER JOIN "course"
>  ON ("course_students"."course_id" = "course"."id")
>WHERE "course"."id" IS NULL
>
> The problem is that the way the WHERE clause is generated is very
> inefficient (at least when used with Postgres). Changing WHERE to
> "course_students"."student_id" IS NOT NULL yields orders of magnitude
> improved query plan.  Here's the difference I'm seeing on real data:
>
> Django way: (cost=1072479.36..6256437.79 rows=1 width=145)
> Hand-crafted: (cost=1518.71..1533.35 rows=1 width=145)
>
> I'm attaching a sample project with the model already set up.  To see the
> generated SQL query, simply run "python manage.py anti-join."

New description:

 For background on this ticket please see the following two discussions:

  * http://stackoverflow.com/questions/8190474/postgres-slow-outer-query-
 when-using-a-primary-key
  * https://groups.google.com/group/django-
 users/browse_thread/thread/7d13f2d8748b4f9f

 Basically, in a many-to-many mappings between models Student and Course,
 if I want to find all instances of Students that aren't registered for
 classes, I would issue the following Django query:

 {{{
 Student.objects.filter(course__isnull=True)
 }}}

 Django translates this into the following query:
 {{{
 SELECT "student"."id", "student"."name"
FROM "student"
   LEFT OUTER JOIN "course_students"
  ON ("student"."id" = "course_students"."student_id")
   LEFT OUTER JOIN "course"
  ON ("course_students"."course_id" = "course"."id")
WHERE "course"."id" IS NULL
 }}}
 The problem is that the way the WHERE clause is generated is very
 inefficient (at least when used with Postgres). Changing WHERE to
 "course_students"."student_id" IS NOT NULL yields orders of magnitude
 improved query plan.  Here's the difference I'm seeing on real data:

 * Django way: (cost=1072479.36..6256437.79 rows=1 width=145)
 * Hand-crafted: (cost=1518.71..1533.35 rows=1 width=145)

 I'm attaching a sample project with the model already set up.  To see the
 generated SQL query, simply run "python manage.py anti-join."

--

-- 
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] #17235: Multipartparser shouldn't leave the QueryDict mutable

[Django]

#17235: Multipartparser shouldn't leave the QueryDict mutable
---+
 Reporter:  apollo13   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  SVN
 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 lukeplant):

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


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

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

Re: [Django] #17276: Slow anti-join query against Postgres

[Django]

#17276: Slow anti-join query against Postgres
-+-
 Reporter:  dmitry@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  orm, postgres,   |  Patch needs improvement:  0
  join, anti-join|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by lukeplant):

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


Comment:

 Accepted on the basis of Russell's comments in the thread linked. When it
 comes to implementation and the need to do different things for different
 databases, we may have to WONTFIX this, but we can see.

-- 
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] #17295: Admin "View" permission

[Django]

#17295: Admin "View" permission
-+-
 Reporter:  danny.adair@…|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  admin readonly   | Triage Stage:
  permission |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by lukeplant):

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


Comment:

 Duplicate of #820

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

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

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

[Django]

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

Comment (by ramiro):

 The localflavor-related warnings actually started appearing after r17009.
 E.g. imports of `django/contrib/localflavor/id/id_choices.py` (the one
 raising the warning
 
[https://code.djangoproject.com/browser/django/trunk/django/contrib/localflavor/id/id_choices.py?rev=14411
 at the module level]) in `django/contrib/localflavor/id/forms.py` were
 moved from class level to module level and so the `RuntimeWarning` is
 triggered when `contrib.localflavor.id` is simply imported.

 I don't think they can be filtered out in this condition. Maybe we can
 move these imports back to the class level?

 Something similar happens with the `ca` localflavor.

-- 
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] #11663: Delete orphaned replaced files

[Django]

#11663: Delete orphaned replaced files
-+-
 Reporter:  SmileyChris  |Owner:
 Type:  Uncategorized|  SmileyChris
Component:  File |   Status:  closed
  uploads/storage|  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by olau):

 I hate to add to the comment spam, but really, people, seeing that this is
 WONTFIX and that 1.3 has removed feature that a file field will delete
 it's associated file when the object is deleted, it's clear that Malcolm's
 idea of never touching the file system has won this battle.

 As much as you may disagree with this, please don't comment here. It's
 useless and will just spam all of us. If you want to do something about
 this, maybe use your energy to code a new file field that does in fact
 clean up?

 Regarding the file_cleanup.py command link posted above: there's a
 possible race condition there if a file ends up on disk before the
 corresponding object is saved in the database. If you want to make a non-
 racy garbage collector for this, you need to be really careful.

-- 
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] #17291: Oracle: cache the server version when first needed

[Django]

#17291: Oracle: cache the server version when first needed
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 Yes, it seems that cached_property would simplify the implementation. I
 will post an updated patch on Monday. Results from the test suite should
 be available then, too.

 I wonder if making the dbwrapper.ops a cached_property would be a wise
 thing to do. Seems like that would simplify the oracle backend some more,
 and would get rid of additional lines in _cursor() method. But I will not
 piggy-bag that into this ticket.

-- 
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] r17148 - in django/trunk: django/db/models/fields django/utils tests/modeltests/timezones

[noreply]

Author: aaugustin
Date: 2011-11-25 01:25:43 -0800 (Fri, 25 Nov 2011)
New Revision: 17148

Modified:
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/django/utils/timezone.py
   django/trunk/tests/modeltests/timezones/models.py
   django/trunk/tests/modeltests/timezones/tests.py
Log:
Fixed #17294 -- Supported nullable DateTimeFields when time zone support is 
enabled. Thanks pressureman for the report.


Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2011-11-24 17:18:56 UTC 
(rev 17147)
+++ django/trunk/django/db/models/fields/__init__.py2011-11-25 09:25:43 UTC 
(rev 17148)
@@ -786,7 +786,7 @@
 
 def get_prep_value(self, value):
 value = self.to_python(value)
-if settings.USE_TZ and timezone.is_naive(value):
+if value is not None and settings.USE_TZ and timezone.is_naive(value):
 # For backwards compatibility, interpret naive datetimes in local
 # time. This won't work during DST change, but we can't do much
 # about it, so we let the exceptions percolate up the call stack.

Modified: django/trunk/django/utils/timezone.py
===
--- django/trunk/django/utils/timezone.py   2011-11-24 17:18:56 UTC (rev 
17147)
+++ django/trunk/django/utils/timezone.py   2011-11-25 09:25:43 UTC (rev 
17148)
@@ -228,6 +228,9 @@
 else:
 return datetime.now()
 
+# By design, these four functions don't perform any checks on their arguments.
+# The caller should ensure that they don't receive an invalid value like None.
+
 def is_aware(value):
 """
 Determines if a given datetime.datetime is aware.

Modified: django/trunk/tests/modeltests/timezones/models.py
===
--- django/trunk/tests/modeltests/timezones/models.py   2011-11-24 17:18:56 UTC 
(rev 17147)
+++ django/trunk/tests/modeltests/timezones/models.py   2011-11-25 09:25:43 UTC 
(rev 17148)
@@ -3,6 +3,9 @@
 class Event(models.Model):
 dt = models.DateTimeField()
 
+class MaybeEvent(models.Model):
+dt = models.DateTimeField(blank=True, null=True)
+
 class Timestamp(models.Model):
 created = models.DateTimeField(auto_now_add=True)
 updated = models.DateTimeField(auto_now=True)

Modified: django/trunk/tests/modeltests/timezones/tests.py
===
--- django/trunk/tests/modeltests/timezones/tests.py2011-11-24 17:18:56 UTC 
(rev 17147)
+++ django/trunk/tests/modeltests/timezones/tests.py2011-11-25 09:25:43 UTC 
(rev 17148)
@@ -25,7 +25,7 @@
 from django.utils.unittest import skipIf
 
 from .forms import EventForm, EventSplitForm, EventModelForm
-from .models import Event, Timestamp
+from .models import Event, MaybeEvent, Timestamp
 
 
 # These tests use the EAT (Eastern Africa Time) and ICT (Indochina Time)
@@ -403,6 +403,11 @@
  datetime.datetime(2011, 1, 1, tzinfo=UTC)],
 transform=lambda d: d)
 
+def test_null_datetime(self):
+# Regression for #17294
+e = MaybeEvent.objects.create()
+self.assertEqual(e.dt, None)
+
 NewDatabaseTests = override_settings(USE_TZ=True)(NewDatabaseTests)
 
 

-- 
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] #17294: django.utils.timezone functions raise AttributeError if DateTimeField allows null

[Django]

#17294: django.utils.timezone functions raise AttributeError if DateTimeField
allows null
-+-
 Reporter:  pressureman  |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:   |  Version:  SVN
  Internationalization   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by aaugustin):

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


Comment:

 In [17148]:
 {{{
 #!CommitTicketReference repository="" revision="17148"
 Fixed #17294 -- Supported nullable DateTimeFields when time zone support
 is enabled. Thanks pressureman 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] #17295: Admin "View" permission

[Django]

#17295: Admin "View" permission
-+-
 Reporter:  danny.adair@…|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  admin readonly   | Triage Stage:
  permission |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


Comment:

 P.S.: I think the current "change" permission is a historic remnant,
 similar to the "is_staff" attribute of users. The admin app is much more
 powerful and versatile than what they seem to imply...

-- 
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] #17295: Admin "View" permission

[Django]

#17295: Admin "View" permission
---+---
 Reporter:  danny.adair@…  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:
 Severity:  Normal |   Keywords:  admin readonly permission
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 In some cases it is useful to give read-only access to a !ModelAdmin (for
 some users/permission holders). At the moment, the "change" permission is
 needed to view an object, and then further limit this general editing form
 by defining readonly_fields.

 Here's one way how this could be done "manually":
 {{{
 from django.contrib import admin
 from django.contrib.admin.util import flatten_fieldsets

 class ReadOnlyAdmin(admin.ModelAdmin):
 def get_readonly_fields(self, request, obj=None):
 # untested, this could do:
 # readonly_fields = self.model._meta.get_all_field_names()
 # borrowed from ModelAdmin:
 if self.declared_fieldsets:
 fields = flatten_fieldsets(self.declared_fieldsets)
 else:
 form = self.get_formset(request, obj).form
 fields = form.base_fields.keys()
 return fields

 def has_add_permission(self, request):
 # Nobody is allowed to add
 return False

 def has_delete_permission(self, request, obj=None):
 # Nobody is allowed to delete
 return False
 }}}

 What's awkward here is that you now need the "change" permission for read-
 only access. If I want to further customize by inventing a "view"
 permission and then checking the request's user for that permission, that
 is still true and makes it even more awkward - what if I wanted readonly
 for the "view" permission holders, and readwrite for certain others? The
 "view" permission holders would still need the "change" permission to even
 get to see a link in the change_list.

 In other words, with the readonly fields functionality taken to the
 extreme of all fields, at the latest, "change" becomes an inappropriate
 name for the permission.

 I think it may not actually be that hard to define read-only access with a
 new permission:

  1. Auto-create a "view" permission (or maybe "access" is a better name)
  2. change_list shows links to objects if you have the "view" permission,
 i.e. don't need "change"
  3. change_form checks if you have "change" permission, if not,
 automatically sets all fields as read-only

 Oh the comfort! :-)

 See also http://stackoverflow.com/questions/7920371/whole-model-as-read-
 only/7965193#7965193

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

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

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

[Django]

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

 * owner:  nobody => aaugustin


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

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

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

[Django]

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

Comment (by aaugustin):

 I'll deal with the warnings related to time-zone support. They were
 introduced at r17117.

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