Re: [Django] #18616: New auth signal: user_login_failed

[Django]

#18616: New auth signal: user_login_failed
--+--
 Reporter:  micolous  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by micolous):

 * needs_docs:  0 => 1


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

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

Re: [Django] #18616: New auth signal: user_login_failed (was: New auth signal: user_login_fail)

[Django]

#18616: New auth signal: user_login_failed
--+--
 Reporter:  micolous  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by micolous):

 Per the Github pull request comment by Brad Pitcher, I've changed the name
 of the signal to `user_login_failed` to match the verb tense of the other
 signals.

 Updated the code and the tests, and checks out.

-- 
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] #18616: New auth signal: user_login_fail

[Django]

#18616: New auth signal: user_login_fail
--+--
 Reporter:  micolous  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by anonymous):

 Great idea. I manually tested this to work for me too, with the minor
 exception that the last line of code should be
   {{{#!python
   user_login_fail.connect(login_attempt_failure_handler)
   }}}

-- 
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] #2131: HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: HttpResponseSendFile for serving static files handler-specific sendfile
mechanism
-+-
 Reporter:   |Owner:  ccahoon
  ymasuda[at]ethercube.com   |   Status:  reopened
 Type:  New feature  |  Version:  master
Component:  HTTP handling|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 [http://www.parisbonbon.com parisbonbon]

-- 
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] #2137: [patch] order_with_respect_to in M-R has no affect on admin interface

[Django]

#2137: [patch] order_with_respect_to in M-R has no affect on admin interface
---+
 Reporter:  anonymous  |Owner:  xian
 Type:  Bug|   Status:  reopened
Component:  contrib.admin  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by anonymous):

 [http://www.parisbonbon.com parisbonbon]

-- 
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] #1919: filter truncatewords wipes newlines from string, so not chainable with markup filters

[Django]

#1919: filter truncatewords wipes newlines from string, so not chainable with
markup filters
-+
 Reporter:  derelm   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  sprintsept14 | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by anonymous):

 [http://www.parisbonbon.com parisbonbon]

-- 
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] #1453: generic views sometimes inefficient with large data sets - especially archive_index

[Django]

#1453: generic views sometimes inefficient with large data sets - especially
archive_index
---+-
 Reporter:  hugo   |Owner:  zefciu
 Type:  New feature|   Status:  assigned
Component:  Generic views  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Someday/Maybe
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by anonymous):

 [http://www.parisbonbon.com parisbonbon]

-- 
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] #1028: High-level feed framework should make more feed elements available

[Django]

#1028: High-level feed framework should make more feed elements available
-+-
 Reporter:  ubernostrum  |Owner:
 Type:  New feature  |  tylerdavis
Component:  contrib.syndication  |   Status:  assigned
 Severity:  Normal   |  Version:  1.2-alpha
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-

Comment (by anonymous):

 [http://www.parisbonbon parisbonbon]

-- 
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] #494: Collapse in admin interface for inline related objects

[Django]

#494: Collapse in admin interface for inline related objects
-+-
 Reporter:  jcstover@…   |Owner:  aptiko
 Type:  New feature  |   Status:  reopened
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  edit_inline, nfa-| Triage Stage:  Accepted
  someday|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by anonymous):

 [http://www.parisbonbon.com parisbonbon]

-- 
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] #29: Fix usability issue with limit_choices_to and "Add another" in admin

[Django]

#29: Fix usability issue with limit_choices_to and "Add another" in admin
---+-
 Reporter:  adrian |Owner:  anonymous
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Someday/Maybe
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+-

Comment (by anonymous):

 [http://www.parisbonbon.com parisbonbon]

-- 
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] #25: Filtering interface on ForeignKey boxes

[Django]

#25: Filtering interface on ForeignKey  boxes
---+
 Reporter:  adrian |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  feature| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+

Comment (by anonymous):

 [http://www.parisbonbon parisbonbon]

-- 
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] #23: Add support for ValidationWarning

[Django]

#23: Add support for ValidationWarning
-+
 Reporter:  adrian   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by anonymous):

 [http://www.parisbonbon parisbonbon]

-- 
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] #820: [patch] "view" permission to compliment add/change/delete

[Django]

#820: [patch] "view" permission to compliment add/change/delete
-+-
 Reporter:  kayos@…  |Owner:  adrian
 Type:  enhancement  |   Status:  closed
Component:  contrib.admin|  Version:  master
 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
-+-
Changes (by anonymous):

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


Comment:

 [http://www.parisbonbon.com parisbonbon]

-- 
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] #18616: New auth signal: user_login_fail

[Django]

#18616: New auth signal: user_login_fail
--+--
 Reporter:  micolous  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by micolous):

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


Comment:

 Pull request with patch: https://github.com/django/django/pull/201

 Tests pass with SQLite.  I've added an additional test to make sure this
 signal is fired correctly.

-- 
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] #18616: New auth signal: user_login_fail

[Django]

#18616: New auth signal: user_login_fail
--+
 Reporter:  micolous  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 I've implemented a new signal in Django called `user_login_fail`, in
 `django.contrib.auth`.

 It is fired whenever an unsuccessful use of
 `django.contrib.auth.authenticate()` occurs, so will apply to all
 unsuccessful login attempts.

 An example of use:

 {{{
 from django.contrib.auth.signals import user_login_fail

 def login_attempt_failure_handler(sender, **kwargs):
 print "login attempt failure from %s: %r" % (sender, kwargs)

 user_login_failure.connect(login_attempt_failure_handler)
 }}}

 This would then print on the console while running the development server:

 {{{
 login attempt failure from django.contrib.auth: {'credentials':
 {'username': u'michael', 'password': u'notmypassword'}, 'signal':
 }
 }}}

 I'm aware at the moment that this passes back the password, however the
 `authenticate` method takes in kwargs for it's authentication, and could
 include some extra information needed when notifying the administrator
 (such as a login realm).

 The other issue is that this has no idea about what is the sender or the
 request associated with this signal.  I'm unsure of whether this could be
 fixed in the signal (and present some better information), or just
 delegate this responsibility to the use of the `traceback` module.

 Patch / pull request is incoming.

-- 
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] #18247: filter and Decimal equality doesn't work

[Django]

#18247: filter and Decimal equality doesn't work
-+-
 Reporter:  elmopl@… |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  decimal filter   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by fengb):

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


Comment:

 Per http://article.gmane.org/gmane.comp.db.sqlite.general/75696 ,  SUM
 values should not have affinity so typecasting Decimal into a string will
 never return real values.

 I think changing the typecast of Decimal into float is "good enough".
 Internally, sqlite3 already represents these values as floats, and it
 would fix this bug.  Otherwise, we would need separate casting engines
 depending on whether SUM is used.

-- 
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/django] 566433: typo in "django/docs/topics/python3.txt"

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5664338e22c1312e68293181a41b290434b2018a
  
https://github.com/django/django/commit/5664338e22c1312e68293181a41b290434b2018a
  Author: Stefan Kjartansson 
  Date:   2012-07-10 (Tue, 10 Jul 2012)

  Changed paths:
M docs/topics/python3.txt

  Log Message:
  ---
  typo in "django/docs/topics/python3.txt"


  Commit: c9a1f9d1fca6acd1361a7ae15c4dd7f58538233e
  
https://github.com/django/django/commit/c9a1f9d1fca6acd1361a7ae15c4dd7f58538233e
  Author: Adrian Holovaty 
  Date:   2012-07-11 (Wed, 11 Jul 2012)

  Changed paths:
M docs/topics/python3.txt

  Log Message:
  ---
  Merge pull request #197 from StefanKjartansson/master

Fixed typo in docs


Compare: https://github.com/django/django/compare/f4875242161f...c9a1f9d1fca6

-- 
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/django] fe443b: fixed a typo in timezones docs.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fe443b11def46828a140bdd5521807e6a6c27bf8
  
https://github.com/django/django/commit/fe443b11def46828a140bdd5521807e6a6c27bf8
  Author: mitnk 
  Date:   2012-07-10 (Tue, 10 Jul 2012)

  Changed paths:
M docs/topics/i18n/timezones.txt

  Log Message:
  ---
  fixed a typo in timezones docs.


  Commit: f4875242161fa741216f5941e029ad5f78a74ec3
  
https://github.com/django/django/commit/f4875242161fa741216f5941e029ad5f78a74ec3
  Author: Adrian Holovaty 
  Date:   2012-07-11 (Wed, 11 Jul 2012)

  Changed paths:
M docs/topics/i18n/timezones.txt

  Log Message:
  ---
  Merge pull request #199 from mitnk/master

Fixed a typo in the timezones document.


Compare: https://github.com/django/django/compare/76d5daa60f90...f4875242161f

-- 
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] #18601: document python minor version requirement of >=2.6.5

[Django]

#18601: document python minor version requirement of >=2.6.5
--+
 Reporter:  ptone |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Release blocker   |   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 ptone):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/200

-- 
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] #17756: GeoDjango missing pyspatialite support

[Django]

#17756: GeoDjango missing pyspatialite support
-+
 Reporter:  danols   |Owner:  danols
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+

Comment (by claudep):

 Thanks, we are close now. But I think that the docs are still not clear
 enough about what steps are needed to install !SpatiaLite. The subsections
 are currently:

 * SQLite
 * !SpatiaLite library (libspatialite) and tools (spatialite)
 * pyspatialite
 * pysqlite2

 AFAIR, the pyspatialite method does not need any other step, right? In
 that case, wouldn't it be better to structure the section this way:

 * pyspatialite
 * Installing from sources
   * SQLite
   * !SpatiaLite library (libspatialite) and tools (spatialite)
   * pysqlite2

-- 
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] #15661: LogEntry objects have no unicode method

[Django]

#15661: LogEntry objects have no unicode method
-+-
 Reporter:  Keryn Knight |Owner:  ShawnMilo
    |   Status:  closed
 Type:  New feature  |  Version:  master
Component:  contrib.admin|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  logentry unicode |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by cspinelive):

 I'm no longer anonymous.

 I have custom action_flags in my django_admin_log table (something other
 than 1,2,3 Add, Change, Delete).  It was breaking when I deleted a user
 that had a LogEntry with one of those custom action_flags.  The code was
 falling thru to the final

 return _('LogEntry Object')


 I imported ugettext at the top and changed that line to

 return ugettext('LogEntry Object')

 and all is 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] #15661: LogEntry objects have no unicode method

[Django]

#15661: LogEntry objects have no unicode method
-+-
 Reporter:  Keryn Knight |Owner:  ShawnMilo
    |   Status:  closed
 Type:  New feature  |  Version:  master
Component:  contrib.admin|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  logentry unicode |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by anonymous):

 * ui_ux:   => 0


Comment:

 I'm getting errors in production (django 1.4) (not local development
 django 1.3) when I try to delete an AuthUser that has an associated
 LogEntry.  The preview screen that shows all the linked objects does not
 appear.  Instead I get

 TypeError: coercing to Unicode: need string or buffer, __proxy__ found

 I suspect it is because the unicode method added in this patch is
 returning a proxy object and not a unicode string.

 Here is the full stacktrace...

 Traceback (most recent call last):

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/core/handlers/base.py",
 line 111, in get_response
response = callback(request, *callback_args, **callback_kwargs)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/options.py",
 line 366, in wrapper
return self.admin_site.admin_view(view)(*args, **kwargs)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/utils/decorators.py",
 line 91, in _wrapped_view
response = view_func(request, *args, **kwargs)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/views/decorators/cache.py",
 line 89, in _wrapped_view_func
response = view_func(request, *args, **kwargs)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/sites.py",
 line 196, in inner
return view(request, *args, **kwargs)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/utils/decorators.py",
 line 25, in _wrapper
return bound_func(*args, **kwargs)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/utils/decorators.py",
 line 91, in _wrapped_view
response = view_func(request, *args, **kwargs)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/utils/decorators.py",
 line 21, in bound_func
return func(self, *args2, **kwargs2)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/options.py",
 line 1153, in changelist_view
response = self.response_action(request,
 queryset=cl.get_query_set(request))

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/options.py",
 line 908, in response_action
response = func(self, request, queryset)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/actions.py",
 line 35, in delete_selected
queryset, opts, request.user, modeladmin.admin_site, using)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/util.py",
 line 132, in get_deleted_objects
to_delete = collector.nested(format_callback)

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/util.py",
 line 186, in nested
roots.extend(self._nested(root, seen, format_callback))

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/util.py",
 line 169, in _nested
children.extend(self._nested(child, seen, format_callback))

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/util.py",
 line 171, in _nested
ret = [format_callback(obj)]

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/contrib/admin/util.py",
 line 130, in format_callback
force_unicode(obj))

  File
 
"/home/fieldagent/webapps/fieldagent_no_3/lib/python2.7/django/utils/encoding.py",
 line 71, in force_unicode
s = unicode(s)

 TypeError: coercing to Unicode: need string or buffer, __proxy__ found

-- 
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] #18541: Infinite Lock With Caching Backend

[Django]

#18541: Infinite Lock With Caching Backend
-+
 Reporter:  zmsmith  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  caching  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by zmsmith):

 Had a chance to look at this, but
 [http://docs.python.org/library/signal#signal.alarm signal.alarm()] is not
 cooperating with the thread locking.

 Interestingly, when this lock occurs, {{{SIGINT}}} is also just getting
 swallowed. I wonder if the code in
 [https://github.com/django/django/blob/master/django/utils/synch.py
 django.utils.synch] is doing something a little too aggressive, but it's
 hard for me to say because I don't have any real experience with
 threading.

-- 
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] #16572: select_related doesn't work (silent/masked TypeError) over multiple one-to-one relationships

[Django]

#16572: select_related doesn't work (silent/masked TypeError) over multiple 
one-to-
one relationships
-+-
 Reporter:  rfrankel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  select_related orm   |  Needs documentation:  0
  queryset   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by anonymous):

 This patch certainly solved the problems I was having with this.

-- 
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] #18615: Allow retrieval of the signature age using the signing API

[Django]

#18615: Allow retrieval of the signature age using the signing API
--+
 Reporter:  brutasse  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Core (Other)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently there is no way to retrieve the time a value was dumped when
 unsigning it. One way to do hack around this limitation is to do:

 {{{#!python
 import datetime

 from django.core import signing
 from django.utils import timezone


 def loads_with_timestamp(value, salt):
 try:
 data = signing.loads(value, salt=salt, max_age=-1)
 except signing.SignatureExpired as e:
 age = float(str(e).split('Signature age ')[1].split(' >')[0])
 timestamp = timezone.now() - datetime.timedelta(seconds=age)
 return timestamp, signing.loads(value, salt=salt)
 }}}

 This isn't particularly elegant. It'd be great if the API allowed that
 kind of thing, although I'm not sure what's the best way to do it:

 * a flag that changes the return value of the `loads` function? (ugh)
 * a new function, `loads_with_timestamp`? (name bikeshedding ensues)
 * an API change in Django 1.7 and opt-in in previous versions?

 Maybe there are other ways…

-- 
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] #9762: template filter |date:"r" not valid RFC 2822 formatted when LANGUAGE_CODE different than english

[Django]

#9762: template filter |date:"r" not valid RFC 2822 formatted when LANGUAGE_CODE
different than english
--+
 Reporter:  amele |Owner:  kgrandis
 Type:  Bug   |   Status:  new
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  date template filter  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by anonymous):

 this is still a problem

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

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

Re: [Django] #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:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  oracle postgresql|  decision needed
  mysql schemas  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by gezuru@…):

 * cc: gezuru@… (removed)


-- 
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] #18494: Positional arguments not passed to view functions in included urlconfs

[Django]

#18494: Positional arguments not passed to view functions in included urlconfs
---+
 Reporter:  rfugger|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (URLs)|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  urls, urlconf  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by stefantalpalaru):

 Better patch that only adds the unnamed matches from the parent pattern.
 I've also added a test.

-- 
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] #11688: verbose_name should allow dynamical translation based on a number

[Django]

#11688: verbose_name should allow dynamical translation based on a number
--+
 Reporter:  mitar |Owner:  nobody
 Type:  New feature   |   Status:  reopened
Component:  Internationalization  |  Version:  1.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by sirex):

 I tried to find all places, where verbose_name is involved, and here is
 list of what I found with noun forms and context for whole string:

 {{{
 [ genitive ] "Cannot delete %(name)s"
 [ accusative, @gender ]  "Delete selected %(verbose_name_plural)s"
 []   '%(verbose_name)s: %(obj)s'
 [ @gender ]  'Added %(name)s "%(object)s".
 [ dative,  @gender ] 'Changed %(list)s for %(name)s "%(object)s".'
 [ @gender ]  'Deleted %(name)s "%(object)s".'
 [ @gender ]  'The %(name)s "%(obj)s" was added successfully.'
 [ accusative ]   "You may add another %(verbose_name)s below."
 [ @gender ]  'The %(name)s "%(obj)s" was changed
 successfully.'
 [ @gender ]  'The %(name)s "%(obj)s" was added successfully.
 You may edit it again below.'
 [ accusative ]   "You may add another %(verbose_name)s below."
 [ accusative ]   'Add %(verbose_name)s'
 [ @gender ]  '%(name)s object with primary key %(key)r does
 not exist.'
 [ accusative ]   'Change %s'
 [ genitive, number ] "%(count)s %(name)s was changed successfully."
 [ @gender ]  '%(name)s object with primary key %(key)r does
 not exist.'
 [ @gender ]  'The %(name)s "%(obj)s" was deleted
 successfully.'
 [ genitive ] "Cannot delete %(name)s"
 [ accusative ]   {% blocktrans with cl.opts.verbose_name as name
 %}Add {{ name }}{% endblocktrans %}
 [ accusative ]   {% trans 'Add' %} {{ opts.verbose_name }}
 [ accusative ]   {% blocktrans with
 verbose_name=inline_admin_formset.opts.verbose_name|title %}Add another {{
 verbose_name }}{% endblocktrans %}
 [ accusative ]   'Select %(verbose_name)s'
 [ accusative,  @gender ] 'Select %(verbose_name)s to change'
 [ genitive, number ] '%d %(verbose_name)s' % (self.result_count, name)
 [ genitive ] {{ field.verbose_name|capfirst }} calendar
 [ accusative ]   {{ model.verbose_name_plural|capfirst }} by {{
 field.verbose_name }}
 [ accusative ]   Home / {{ model.verbose_name_plural|capfirst }} /
 By {{ field.field.verbose_name }}
 [ accusative ]   {{ model.verbose_name_plural|capfirst }} by {{
 field.field.verbose_name }}
 [ instrumental ] {{ model.verbose_name_plural|capfirst }} with {{
 field.field.verbose_name }} {{ value }}
 [ accusative ]   Home / {{ model.verbose_name_plural|capfirst }} /
 Fields / By {{ field.field.verbose_name }} / {{ value }}
 [ genitive, number ] {{ object_list.count }} {% if
 object_list.count|pluralize %}{{ model.verbose_name_plural }}{% else %}{{
 model.verbose_name }}{% endif %} with {{ field.field.verbose_name }} {{
 value }}
 [ plural ]   Home / {{ model.verbose_name_plural|capfirst }}
 [ genitive, number ] {{ model.objects.count }} {% if
 model.objects.count|pluralize %}{{ model.verbose_name_plural }}{% else
 %}{{ model.verbose_name }}{% endif %}
 []   {{ object.model.verbose_name|capfirst }}: {{
 object }}
 [ plural ]   Home / {{
 object.model.verbose_name_plural|capfirst }} / {{ object }}
 []   {{ object.model.verbose_name|capfirst }}: {{
 object }}
 [ plural, @gender ]  Appears in "{{ related_object.related_field }}"
 in the following {{ related_object.model.verbose_name_plural }}:
 [ plural, instrumental ] {{ model.verbose_name_plural|capfirst }} with {{
 field.verbose_name }} in {{ month|date:"F Y" }}
 [ accusative, plural ]   Home / {{ model.verbose_name_plural|capfirst }} /
 Calendars / By {{ field.verbose_name }} / {{ month|date:"Y" }} / {{
 month|date:"F" }}
 [ genitive, number ] {{ object_list.count }} {% if
 object_list.count|pluralize %}{{ model.verbose_name_plural }}{% else %}{{
 model.verbose_name }}{% endif %} with {{ field.verbose_name }} on {{
 month|date:"F Y" }}
 [ plural, accusative ]   {{ model.verbose_name_plural|capfirst }} by {{
 field.field.verbose_name }}
 [ plural, accusative ]   Home / {{ model.verbose_name_plural|capfirst }} /
 Fields / By {{ field.field.verbose_name }}
 [ plural, accusative ]   {{ model.verbose_name_plural|capfirst }} 

Re: [Django] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 Please provide the necessary settings to be able to reproduce your
 problem. Please try also to debug the test to see why
 SiteProfileNotAvailable is not raised.

-- 
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] #17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE

[Django]

#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
--+
 Reporter:  slacy |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by dokterbob):

 Replying to [comment:19 Claude Paroz ]:
 > In [531878302735e6a2b36d82b584947bbf8eae8111]:
 > {{{
 > #!CommitTicketReference repository=""
 revision="531878302735e6a2b36d82b584947bbf8eae8111"
 > Fixed #17966 -- Isolated ProfileTestCase from custom AUTH_PROFILE_MODULE
 >
 > Thanks Rob Golding for helping on the patch.
 > }}}

 The patch seems to fix the initial problem but the tests now fail due to
 `SiteProfileNotAvailable` now not being raised in my specific setup. It
 seems as though `override_settings` is not doing quite what it ought to
 do:

 * With `AUTH_PROFILE_MODULE` commented out in my settings, the test runs
 fine.
 * When I comment out the full `@override_settings` line the test runs
 fine.
 * When I remove the `AUTH_PROFILE_MODULE` override, the test fails with
 `AttributeError: AUTH_PROFILE_MODULE` as in the original bug report.
 * When I remove the `USE_TZ` override, I get the `SiteProfileNotAvailable`
 exception not being raised.

 No doubt this is a weird and difficult problem. Let me know if more
 feedback is required - I personally have no real clue what's going on here
 and do not have the time to delve much deeper but would love to help this
 bug get fixed.

 Lastly, it seems that Rob Golding's original patch from the pull request
 passes the unittest just fine.

-- 
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] #11688: verbose_name should allow dynamical translation based on a number

[Django]

#11688: verbose_name should allow dynamical translation based on a number
--+
 Reporter:  mitar |Owner:  nobody
 Type:  New feature   |   Status:  reopened
Component:  Internationalization  |  Version:  1.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by sirex):

 This ticket also covers case-matching, and current patch adds one layer of
 complexity, but actually fixes only number related issues. And what I'm
 proposing, is to fix this as whole using one flexible solution, instead of
 fixing just small parts of it, by implementing different techniques for
 each issue.

 lukeplant thank you for pointing about adjectives, because in Lithuanian
 language we have same situation, "Delete selected %(verbose_name_plural)s"
 for masculine gender must be translated to "Ištrinti pažymėt'''us'''
 %(verbose_name_plural)s", and for feminine "Ištrinti pažymėt'''as'''
 %(verbose_name_plural)s".

 In combination mmitar and my proposed solutions solves:

 * number context issues
 * grammatical case issues

 Unsolved issues:

 * adjective agreement (http://en.wikipedia.org/wiki/Adjective#Agreement)

 I did some research, but could not find any thing related to this, except
 number context which is included in gettext. Also, gettext has context
 feature that we can reuse.

 To fix adjective agreement issue using proposed solution, we can add
 gender context to translatable strings, that has adjectives describing
 dynamic model name.

 For this, in model's Meta class we need to add {{{ verbose_name_gender
 }}}:

 {{{
 from django.db import models
 from django.utils.translation import Noun

 class Book(models.Model):
 title = models.CharField(max_length=128)

 class Meta:
 verbose_name = Noun('book', gender='feminine')
 }}}

 Then, in strings with model name, we can use some thing like this:

 {{{
 pgettext(model.opts.verbose_name.gender, 'Delete selected
 %(verbose_name)s' % {'verbose_name': model.opts.verbose_name.accusative})
 }}}

 And {{{ makemessages }}}, reading this {{{ Noun('book', gender='feminine')
 }}} will write to .po file both genders and translators will be able to
 translate it correctly.

 So with this, at least for Lithuanian language all issues seems to be
 solved. Solution is still fully backward compatible, and for those, who
 are not interested to support many languages, where model names are used,
 nothing changes. But those, who want to support other languages, will be
 easy to add correct grammatical cases and genders where 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] #17285: Documentation typo: 'SimpleTemplateResponse.add_post_rendering_callback'

[Django]

#17285: Documentation typo: 'SimpleTemplateResponse.add_post_rendering_callback'
---+--
 Reporter:  yorkedork  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 Yes, this is consistent with our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions branch policy].

-- 
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] #18548: View changes field when 'unique_together' is not satisfied in a Form

[Django]

#18548: View changes field when 'unique_together' is not satisfied in a Form
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  reopened
Component:  Documentation |  Version:  1.4
 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):

 * type:  Bug => Cleanup/optimization
 * version:  1.3 => 1.4
 * component:  Forms => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 Yes, the documentation could state more clearly that the *instance* passed
 to the form will be modified and should not be reused later in the view,
 especially if validation fails.

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