Re: [Django] #17194: Auth tests failing on non-US locales

[Django]

#17194: Auth tests failing on non-US locales
+
 Reporter:  hcarvalhoalves  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.auth|  Version:  SVN
 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
+

Comment (by claudep):

 Replying to [comment:5 hcarvalhoalves]:
 > The patch only overrides the locale for Django's own tests, correct?
 User-provided tests will still run on the settings.py locale?

 Yes, of course.

-- 
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] #15901: Django should wrap all PEP 249 exceptions in db.utils

[Django]

#15901: Django should wrap all PEP 249 exceptions in db.utils
-+-
 Reporter:  xiaket   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jamesh):

 * has_patch:  0 => 1


Comment:

 Attaching my patch from the duplicate ticket so it doesn't get lost.  Has
 anyone else given the patch a test to see if it covers their use cases?

-- 
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] #17193: Send templated email.

[Django]

#17193: Send templated email.
-+
 Reporter:  tomchristie  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Mail)  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 Yes, you should assign the ticket to yourself if you intend to work on it.

 You'll find more information about our development process in the
 [https://docs.djangoproject.com/en/dev/internals/contributing/
 contributing guide].

-- 
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] #17225: Salt used for cookie-based sessions isn't consistent with module name (was: Salt)

[Django]

#17225: Salt used for cookie-based sessions isn't consistent with module name
-+-
 Reporter:  julien   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  contrib.sessions |   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
-+-
Description changed by julien:

Old description:

> The salt used for dumping/loading cookie-based session is
> 'django.contrib.sessions.backends.cookies':
>
> https://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/signed_cookies.py?rev=16466#L92
>
> https://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/signed_cookies.py?rev=16466#L36
>
> It'd make more sense if it were
> 'django.contrib.sessions.backends.signed_cookies'.

New description:

 The salt used for dumping/loading cookie-based sessions is
 'django.contrib.sessions.backends.cookies':

 
https://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/signed_cookies.py?rev=16466#L92

 
https://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/signed_cookies.py?rev=16466#L36

 It'd make more sense if it were
 'django.contrib.sessions.backends.signed_cookies' to reflect the actual
 module 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.

[Django] #17225: Salt

[Django]

#17225: Salt
+
   Reporter:  julien|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.sessions  |Version:
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The salt used for dumping/loading cookie-based session is
 'django.contrib.sessions.backends.cookies':

 
https://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/signed_cookies.py?rev=16466#L92

 
https://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/signed_cookies.py?rev=16466#L36

 It'd make more sense if it were
 'django.contrib.sessions.backends.signed_cookies'.

-- 
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] #17223: django.contrib.sessions.backends.session_cookies is Incorrectly Referenced

[Django]

#17223: django.contrib.sessions.backends.session_cookies is Incorrectly 
Referenced
-+-
 Reporter:  bryanveloso  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Ready for checkin
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #17224: determine and document the use of default option in context of FileField

[Django]

#17224: determine and document the use of default option in context of FileField
--+
 Reporter:  ptone |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  File uploads/storage  |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently the 'default' option in the definition of a "FileField" just
 gets passed on to Field where it is just stored in the database as a raw
 string.

 There are several other potentially viable things FileField could do,
 including checking to see if it is a valid path to a file, and then copy
 that to "upload_to" and make that the field's contents.

 Either way, whatever is the "proper" action for default, even if it
 remains unchanged, it should be documented in the FileField docs.

-- 
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] #17223: django.contrib.sessions.backends.session_cookies is Incorrectly Referenced

[Django]

#17223: django.contrib.sessions.backends.session_cookies is Incorrectly 
Referenced
---+
 Reporter:  bryanveloso|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 The documentation says to use `django.contrib.sessions.backends.cookies`
 in the instructions to enable cookie-backed sessions, but the module is
 actually `django.contrib.sessions.backends.session_cookies`.

-- 
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] #17216: Django contrib login view does not pass request to auth form on POST

[Django]

#17216: Django contrib login view does not pass request to auth form on POST
-+-
 Reporter:  Zaar Hai |Owner:  nobody
  |   Status:  closed
 Type:  Bug  |  Version:  1.3
Component:  contrib.auth |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  auth, login  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ptone):

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


Comment:

 Sending the request to the standard AuthenticationForm assumes that you
 have cookies enabled as it will trigger a cookie capability check. However
 the default session backend is the database backend, not the cookie
 backend.  So changing the default behavior of the view to pass the request
 would break sites that don't require cookies, with browsers with cookies
 disabled.

 Since you are already providing a customized auth form - the solution in
 this case is just to provide your own login view 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] #17193: Send templated email.

[Django]

#17193: Send templated email.
-+
 Reporter:  tomchristie  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Mail)  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by julianapplebaum):

 I'm new to to the django dev community, and was hoping to write some unit
 tests for this shortcut. Should I claim the ticket before doing that?
 Sorry if this isn't the right place to be asking that.

 - Julian Applebaum

-- 
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] #17220: github repo may be no more available behind https

[Django]

#17220: github repo may be no more available behind https
--+
 Reporter:  fernando+django@… |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:
 Severity:  Normal|   Resolution:
 Keywords:  github git https  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by ptone):

 * 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] #17143: select_related makes base __init__ unsafe

[Django]

#17143: select_related makes base __init__ unsafe
-+-
 Reporter:  Leo  |Owner:
 Type:  Bug  |  calvinspealman
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by calvinspealman):

 * has_patch:  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.

[Django] #17222: Let `manage.py` learn --colour/--color option to control if colouring output is wanted by user

[Django]

#17222: Let `manage.py`  learn  --colour/--color option to control if colouring
output is wanted by user
+
 Reporter:  rabio   |  Owner:  nobody
 Type:  New feature | Status:  new
Component:  Core (Management commands)  |Version:  SVN
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 It will be nice if `manage.py` could understand --colour/--color options
 like grep do for example (i.e always / never / guess).

 === Rationale ===

 1. It may be still reasonable to force `manage.py` to output colour escape
 sequences even when output is not send to a `tty` (now escape sequences
 for colour are supresed in this case). For example, this may happen when
 its output is redirected to `less -R` or `tail`.

 2. Even when switching colours off may be achieved now by setting
 DJANGO_COLORS=nocolor environment variable (or to any palette name not
 known to `django.utils.termcolors`), it is not obvious way to achieve this
 and it is not always as easy to set / change environment variable as it is
 to run command with additional option.

 3. See also #17221 for additional rationale as this enhancement may
 provide temporary workaround for 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] #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:  new
Component:  Core (Management commands)  |Version:  SVN
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 `manage.py` may sends ANSI escape sequences for output colourization.
 Unfortunately, guessing if terminal support colours is broken. Guessing if
 output colourisation is desirable do not take all possible use cases into
 account.

 === Rationale: ===

 As it is now, partial checking is made (only platform is checked by
 `django.core.management.color.supports_color()`) and `manage.py` may sends
 colour codes even when terminal can not handle them properly (as it is a
 case for most, if not all, dumb terminals).

 For guessing to work correctly, checking if terminal can handle colours
 need to be reimplemented. For this, potentially `curses.has_colors()`
 could be used but I'm not sure is it supported on windows, though. In
 addition, `django.utils.termcolors` allow to request "blink" option
 (fortunately not used in default palettes), but not all terminals that
 support colours know how to blink.

-- 
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] #16865: get_or_create defaults to _for_write even when it's just reading

[Django]

#16865: get_or_create defaults to _for_write even when it's just reading
-+-
 Reporter:  Rick van Hattem  |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by russellm):

 @carljm has correctly hit the reason this was done -- get_or_create needs
 to get a reliable answer as to whether the object exists, and due to the
 potential for replication lag, the most reliable answer comes from the
 write source, not the read source.

 That said, I can certainly see the value in moving the *initial* read load
 off the maste, and from the looks of it, @kmtracey's analysis is correct
 -- as long as the fallback read is performed on the master, we should get
 the benefits of a distributed initial read, while retaining a reliable
 write.

-- 
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] #8408: add a new meta option: don't do count(*) in admin

[Django]

#8408: add a new meta option: don't do count(*) in admin
-+-
 Reporter:  lidaobing|Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by kmike):

 * cc: kmike84@… (added)


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

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

Re: [Django] #17194: Auth tests failing on non-US locales

[Django]

#17194: Auth tests failing on non-US locales
+
 Reporter:  hcarvalhoalves  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.auth|  Version:  SVN
 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
+

Comment (by hcarvalhoalves):

 The patch only overrides the locale for Django's own tests, correct? User-
 provided tests will still run on the settings.py locale?

-- 
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] #17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset

[Django]

#17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset
---+-
 Reporter:  jimallman   |Owner:  jimallman
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Release blocker|   Resolution:
 Keywords:  fieldset   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+-
Changes (by julien):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. This is a regression that needs to get fixed before
 the next release.

-- 
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:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by charettes):

 jezdez wrote:
I'm not sure what those new labels would help the user, to be honest.
 The implementation details of those fields should not be reflected on the
 front-end, IMO.

 Actually the only place i found where it was used is in
 
[https://github.com/charettes/django/blob/master/django/contrib/admindocs/views.py#L330
 contrib.admindocs] which exposes it to the frond-end.

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

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

Re: [Django] #16575: SelectDateWidget should have possibility to have more custom configurations

[Django]

#16575: SelectDateWidget should have possibility to have more custom 
configurations
--+
 Reporter:  foobarrior|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  SelectDateWidget  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by calebs):

 I made foobarrior's changes into a git diff off of the 1.3.1 trunc with a
 few other changes including:

 * Removal of stray prints and other debug statements.
 * Adding _has_changed back in. (Not certain about what to do with this
 method)
 * Consolidated the two helper functions into one and added a docstring.
 * Fallback to defaults based on locale

 If L10N is False, the changes in this diff make the select widgets order
 by year, month, day. I'm not sure if this should fall back to US order
 (d/m/Y) as before, or UTC (Y/m/d).

 Tests are still needed and this diff causes a failure in line 92 of
 FormsExtraTestCase. However, should the test be amended to use UTC or en-
 US in the event of no L10N?

-- 
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] #17220: github repo may be no more available behind https

[Django]

#17220: github repo may be no more available behind https
--+--
 Reporter:  fernando+django@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:
 Severity:  Normal|   Keywords:  github git https
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+--
 Following https://docs.djangoproject.com/en/dev/topics/install
 /#installing-development-version , I was unable to download latests
 version of github repo:


 {{{
 $ git clone https://github.com/django/django.git
 Initialized empty Git repository in /home/admin/django/django/.git/
 Cannot get remote repository information.
 Perhaps git-update-server-info needs to be run there?
 }}}


 This is a known error from github for old git versions (see
 https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-
 in-90-days).

 Despite updating git was not an option on my server, I was able to
 download django code using git:// instead of https:// :

 {{{
 $ git --version
 git version 1.5.2.5
 $ git clone git://github.com/django/django.git
 Initialized empty Git repository in /home/admin/django/django/.git/
 remote: Counting objects: 138773, done.
 remote: Compressing objects: 100% (35866/35866), done.
 Indexing 138773 objects...
 remote: Total 138773 (delta 104852), reused 130823 (delta 98002)
  100% (138773/138773) done
 Resolving 104852 deltas...
  100% (104852/104852) done
 Checking 4640 files out...
  100% (4640/4640) done
 }}}




 For next developers, can you please change documentation accordingly ?

-- 
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] #14315: memcached doesn't support negative deltas for incr() and decr()

[Django]

#14315: memcached doesn't support negative deltas for incr() and decr()
-+
 Reporter:  manfre   |Owner:  manfre
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by tobias):

 The test applies and the tests all pass (with the memcache tests enabled).
 I removed excess white space, added a second comment, and opened a pull
 request with the updated diff here:

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

-- 
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:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Translations |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by charettes):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Translations
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization


-- 
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] #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:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Some IntegerField subclasses share the same description which render this
 attribute pretty useless in the end.

 The same happens with SlugField which has the same description as the
 CharField and with FileField and ImageField.

 Here's the github [https://github.com/django/django/pull/79, pull request]
 and [https://github.com/django/django/pull/79.diff the dynamic diff].

 Is there a command to makemessages for the core? Does the .po changes must
 be included in this commit?

-- 
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] #16208: natural key YAML deserialization using non-list natural keys broken (with fixing patch)

[Django]

#16208: natural key YAML deserialization using non-list natural keys broken 
(with
fixing patch)
--+
 Reporter:  jeff.k@…  |Owner:  kenth
 Type:  Bug   |   Status:  assigned
Component:  Core (Serialization)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  yaml  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by kenth):

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


-- 
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] #16137: .get behaviour is inconsistent with .get_or_create when no kwargs are given

[Django]

#16137: .get behaviour is inconsistent with .get_or_create when no kwargs are 
given
-+-
 Reporter:  wilfred@…|Owner:  poirier
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by charettes):

 Updated patch with a more descriptive test failure (instead of
 {{{self.assertTrue(False)}}})

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

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

Re: [Django] #7463: alternate phone regex for US flavor forms

[Django]

#7463: alternate phone regex for US flavor forms
-+-
 Reporter:  kevin@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.localflavor  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor forms| Triage Stage:  Accepted
  areacode delimiter |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kmtracey):

 * needs_better_patch:  0 => 1


Comment:

 This format isn't exactly familiar to me, but I'm not exactly an arbiter
 of common US phone number formats so I accept that it might be nice to
 support nnn/nnn-. However, I don't think nnn/nnn/ nor nnn-nnn/
 should be accepted -- those are not mentioned in the original description
 and don't look at all valid to me, yet it seems they are acceptable with
 the patch. See additional tests I added that try to ensure these patterns
 are not accepted -- these tests fail with the patch.

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

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

Re: [Django] #17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset

[Django]

#17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset
---+--
 Reporter:  jimallman   |Owner:  jimallman
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  fieldset   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Changes (by jimallman ):

 * owner:  anonymous => jimallman
 * status:  assigned => new


-- 
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] #17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset

[Django]

#17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset
---+--
 Reporter:  jimallman   |Owner:  anonymous
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  fieldset   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Changes (by jimallman ):

 * owner:  nobody => anonymous
 * needs_docs:   => 0
 * status:  new => assigned
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 I'm going to attempt a fix, either by postponing the matching height
 (perhaps with an event listener) ''or'' by using a more sensitive test for
 `$(from_box).outerHeight()`

-- 
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] #17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset

[Django]

#17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset
---+--
 Reporter:  jimallman   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  SVN
 Severity:  Normal |   Keywords:  fieldset
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  1
---+--
 The select filter creates a pair of "from" and "to" widgets (in
 SelectFilter2.js), and gives them matching height by applying the height
 of the "from" box to the "to" box.

 But if a model uses collapsed fieldsets in admin pages, the "from" box has
 0 height (says jQuery) which effectively hides the "to" box. The widget
 data is intact, but obviously this is confusing and makes removing
 individual values impossible in the UI.

 This happens in both !Firefox/Mac and IE8/Win (discovered while editing
 Entries in the Zinnia blog app).

-- 
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] #16684: BaseForm needs to escape the 'class' attribute value

[Django]

#16684: BaseForm needs to escape the 'class' attribute value
---+
 Reporter:  dtrebbien  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.3
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by kmtracey):

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


Comment:

 Given the different rules for escaping css classes than regular html
 escaping, and the fact that css class names are generally going to be
 under the control of developers and not pulled from user-supplied input, I
 don't see that escaping css class names is something Django should be
 doing.

-- 
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] #17174: The docs should mention, that MySql doesn't support microseconds

[Django]

#17174: The docs should mention, that MySql doesn't support microseconds
---+
 Reporter:  jammon |Owner:  poirier
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 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 kmtracey):

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


Comment:

 In [17095]:
 {{{
 #!CommitTicketReference repository="" revision="17095"
 Fix #17174: Add note in the supported databases notes that MySQL can't
 conceive of a time unit smaller than a second. Thanks jammon and poirier.
 }}}

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

[noreply]

Author: kmtracey
Date: 2011-11-13 11:28:43 -0800 (Sun, 13 Nov 2011)
New Revision: 17095

Modified:
   django/trunk/docs/ref/databases.txt
Log:
Fix #17174: Add note in the supported databases notes that MySQL can't conceive 
of a time unit smaller than a second. Thanks jammon and poirier.

Modified: django/trunk/docs/ref/databases.txt
===
--- django/trunk/docs/ref/databases.txt 2011-11-13 19:05:02 UTC (rev 17094)
+++ django/trunk/docs/ref/databases.txt 2011-11-13 19:28:43 UTC (rev 17095)
@@ -372,6 +372,9 @@
 :class:`~django.db.models.TimeField` or 
:class:`~django.db.models.DateTimeField`
 respectively, a ``ValueError`` is raised rather than truncating data.
 
+MySQL does not store fractions of seconds. Fractions of seconds are truncated
+to zero when the time is stored.
+
 Row locking with ``QuerySet.select_for_update()``
 -
 

-- 
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] #14315: memcached doesn't support negative deltas for incr() and decr()

[Django]

#14315: memcached doesn't support negative deltas for incr() and decr()
-+
 Reporter:  manfre   |Owner:  manfre
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by manfre):

 * 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] #14315: memcached doesn't support negative deltas for incr() and decr()

[Django]

#14315: memcached doesn't support negative deltas for incr() and decr()
-+
 Reporter:  manfre   |Owner:  manfre
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.2
 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 manfre):

 * owner:  otherjacob => manfre
 * ui_ux:   => 0


Comment:

 Updated patch to trunk and removed smart_str calls.

-- 
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] #16378: locmem should use pickle.HIGHEST_PROTOCOL to match memcached et. al.

[Django]

#16378: locmem should use pickle.HIGHEST_PROTOCOL to match memcached et. al.
-+
 Reporter:  PaulM|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:  1|UI/UX:  0
-+
Changes (by manfre):

 * owner:  manfre => nobody


-- 
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] #16378: locmem should use pickle.HIGHEST_PROTOCOL to match memcached et. al.

[Django]

#16378: locmem should use pickle.HIGHEST_PROTOCOL to match memcached et. al.
-+
 Reporter:  PaulM|Owner:  manfre
 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:  1|UI/UX:  0
-+
Changes (by manfre):

 * owner:  nobody => manfre


-- 
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] #17215: runtests doesn't clean up all temp files all the time

[Django]

#17215: runtests doesn't clean up all temp files all the time
---+
 Reporter:  kmtracey   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 kmtracey):

 * owner:  kmtracey => nobody


Comment:

 r17094 was a quick way to get rid of the leftover tmp dirs from a clean
 test run; if anyone has a better approach/idea please speak up.

 There were also some leftover django dirs -- these I think come
 from runs that don't complete successfully. I'm not sure how to approach
 cleaning them up.

-- 
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] #17215: runtests doesn't clean up all temp files all the time

[Django]

#17215: runtests doesn't clean up all temp files all the time
---+
 Reporter:  kmtracey   |Owner:  kmtracey
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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
---+

Comment (by kmtracey):

 In [17094]:
 {{{
 #!CommitTicketReference repository="" revision="17094"
 Refs #17215: Avoid generating 47 leftover tmp dirs during a clean test
 run.
 }}}

-- 
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] r17094 - in django/trunk: django/contrib/formtools/tests/wizard/wizardtests tests tests/modeltests/model_forms tests/regressiontests/admin_views tests/regressiontests/forms tests/regressi

[noreply]

Author: kmtracey
Date: 2011-11-13 11:05:02 -0800 (Sun, 13 Nov 2011)
New Revision: 17094

Modified:
   django/trunk/django/contrib/formtools/tests/wizard/wizardtests/forms.py
   django/trunk/tests/modeltests/model_forms/models.py
   django/trunk/tests/regressiontests/admin_views/admin.py
   django/trunk/tests/regressiontests/admin_views/models.py
   django/trunk/tests/regressiontests/forms/models.py
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
   django/trunk/tests/runtests.py
Log:
Refs #17215: Avoid generating 47 leftover tmp dirs during a clean test run.

Modified: 
django/trunk/django/contrib/formtools/tests/wizard/wizardtests/forms.py
===
--- django/trunk/django/contrib/formtools/tests/wizard/wizardtests/forms.py 
2011-11-13 15:09:08 UTC (rev 17093)
+++ django/trunk/django/contrib/formtools/tests/wizard/wizardtests/forms.py 
2011-11-13 19:05:02 UTC (rev 17094)
@@ -1,3 +1,4 @@
+import os
 import tempfile
 
 from django import forms
@@ -10,7 +11,7 @@
 
 from django.contrib.formtools.wizard.views import WizardView
 
-temp_storage_location = tempfile.mkdtemp()
+temp_storage_location = 
tempfile.mkdtemp(dir=os.environ.get('DJANGO_TEST_TEMP_DIR'))
 temp_storage = FileSystemStorage(location=temp_storage_location)
 
 class Page1(forms.Form):

Modified: django/trunk/tests/modeltests/model_forms/models.py
===
--- django/trunk/tests/modeltests/model_forms/models.py 2011-11-13 15:09:08 UTC 
(rev 17093)
+++ django/trunk/tests/modeltests/model_forms/models.py 2011-11-13 19:05:02 UTC 
(rev 17094)
@@ -7,13 +7,14 @@
 words, most of these tests should be rewritten.
 """
 
+import os
 import tempfile
 
 from django.core.files.storage import FileSystemStorage
 from django.db import models
 
 
-temp_storage_dir = tempfile.mkdtemp()
+temp_storage_dir = tempfile.mkdtemp(dir=os.environ['DJANGO_TEST_TEMP_DIR'])
 temp_storage = FileSystemStorage(temp_storage_dir)
 
 ARTICLE_STATUS = (

Modified: django/trunk/tests/regressiontests/admin_views/admin.py
===
--- django/trunk/tests/regressiontests/admin_views/admin.py 2011-11-13 
15:09:08 UTC (rev 17093)
+++ django/trunk/tests/regressiontests/admin_views/admin.py 2011-11-13 
19:05:02 UTC (rev 17094)
@@ -260,7 +260,7 @@
 actions = None
 
 
-temp_storage = FileSystemStorage(tempfile.mkdtemp())
+temp_storage = 
FileSystemStorage(tempfile.mkdtemp(dir=os.environ['DJANGO_TEST_TEMP_DIR']))
 UPLOAD_TO = os.path.join(temp_storage.location, 'test_upload')
 
 

Modified: django/trunk/tests/regressiontests/admin_views/models.py
===
--- django/trunk/tests/regressiontests/admin_views/models.py2011-11-13 
15:09:08 UTC (rev 17093)
+++ django/trunk/tests/regressiontests/admin_views/models.py2011-11-13 
19:05:02 UTC (rev 17094)
@@ -246,7 +246,7 @@
 return "Primary key = %s" % self.id
 
 
-temp_storage = FileSystemStorage(tempfile.mkdtemp())
+temp_storage = 
FileSystemStorage(tempfile.mkdtemp(dir=os.environ['DJANGO_TEST_TEMP_DIR']))
 UPLOAD_TO = os.path.join(temp_storage.location, 'test_upload')
 
 
@@ -547,4 +547,4 @@
 title = models.CharField(max_length=100) 
 published = models.BooleanField() 
 slug = models.SlugField(max_length=1000)
-
\ No newline at end of file
+

Modified: django/trunk/tests/regressiontests/forms/models.py
===
--- django/trunk/tests/regressiontests/forms/models.py  2011-11-13 15:09:08 UTC 
(rev 17093)
+++ django/trunk/tests/regressiontests/forms/models.py  2011-11-13 19:05:02 UTC 
(rev 17094)
@@ -1,4 +1,5 @@
 # -*- coding: utf-8 -*-
+import os
 import datetime
 import tempfile
 
@@ -6,7 +7,7 @@
 from django.db import models
 
 
-temp_storage_location = tempfile.mkdtemp()
+temp_storage_location = 
tempfile.mkdtemp(dir=os.environ['DJANGO_TEST_TEMP_DIR'])
 temp_storage = FileSystemStorage(location=temp_storage_location)
 
 

Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2011-11-13 15:09:08 UTC (rev 17093)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2011-11-13 19:05:02 UTC (rev 17094)
@@ -100,7 +100,7 @@
 def setUp(self):
 super(BaseCollectionTestCase, self).setUp()
 self.old_root = settings.STATIC_ROOT
-settings.STATIC_ROOT = tempfile.mkdtemp()
+settings.STATIC_ROOT = 
tempfile.mkdtemp(dir=os.environ['DJANGO_TEST_TEMP_DIR'])
 self.run_collectstatic()
 # Use our own error handler that can handle .svn dirs on Windows
 #self.addCleanup(shutil.rmtree, settings.STATIC_ROOT,

Modified: django/trunk/tests/runtests.py

Re: [Django] #16074: Class-based views clash get_context_data

[Django]

#16074: Class-based views clash get_context_data
---+
 Reporter:  emyller|Owner:  tobias
 Type:  Bug|   Status:  assigned
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords:  cbv| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by tobias):

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


-- 
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] #16074: Class-based views clash get_context_data

[Django]

#16074: Class-based views clash get_context_data
---+
 Reporter:  emyller|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords:  cbv| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by ptone):

 note that once a root object is in place to handle get_context_data for
 any inheritence tree, it should be easy to then fix #16744 in the base
 method

-- 
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] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+
 Reporter:  reinout|Owner:  tobias
 Type:  New feature|   Status:  assigned
Component:  Generic views  |  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
---+

Comment (by tobias):

 Per a discussion with kmtracey at the sprint today, #16074 should get
 merged before this patch goes in.

-- 
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] #16858: incr() on locmem cache resets the expiry time

[Django]

#16858: incr() on locmem cache resets the expiry time
-+
 Reporter:  boxm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  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:  1|UI/UX:  0
-+
Changes (by manfre):

 * needs_tests:  1 => 0


Comment:

 The original patch walked the expiration time forward by time.time() with
 each call to incr() and decr(). The new patch uses a special timeout value
 to skip setting the expiration time.

-- 
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] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+
 Reporter:  reinout|Owner:  tobias
 Type:  New feature|   Status:  assigned
Component:  Generic views  |  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
---+

Comment (by mlavin):

 This pull request looks good to me. Adds desired functionality with tests
 and docs.

-- 
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] #17180: Documentation should mention that {% load i18n %} is needed in every template

[Django]

#17180: Documentation should mention that {% load i18n %} is needed in every
template
--+
 Reporter:  stefan.freyr@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by StFS):

 Well, I think the key thing here is what aaugustin mentioned. A little
 hand-holding can't hurt. If you ask yourself the question who uses the
 docs, the answer is by and large people who don't know Django all that
 well. Maybe some people go about learning such frameworks by reading the
 docs from beginning to end (and remembering every detail) but I for one is
 not like that. In my case I was using it as a lookup reference because I
 needed information about the i18n behavior.

 In general I subscribe to the DRY principal but I firmly believe that it
 does not apply as well to documentation, at least not in cases such as
 this, where there's very little risk of this behavior changing and the
 docs becoming inconsistent because of 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.

Re: [Django] #17053: Add a note about USE_THOUSAND_SEPARATOR in localization docs

[Django]

#17053: Add a note about USE_THOUSAND_SEPARATOR in localization docs
--+
 Reporter:  shelldweller  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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:  1 |UI/UX:  0
--+
Changes (by poirier):

 * needs_better_patch:  0 => 1


Comment:

 The patch does not apply, it looks as if the localization docs were re-
 arranged in [17026].

-- 
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] #16563: Error pickling request.user

[Django]

#16563: Error pickling request.user
-+
 Reporter:  zero.fuxor@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.3
 Severity:  Release blocker  |   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 tobias):

 As a work around, can't you just pickle a real User model object instead
 of request.user?  E.g., the dumb way to do this might look something like:

 {{{
 def some_view(request):
 pickle.dumps(User.objects.get(pk=request.user.pk))
 }}}

-- 
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] #17037: Add management command to print active project settings

[Django]

#17037: Add management command to print active project settings
-+-
 Reporter:  msabramo |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  printsettings|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by poirier):

 Instead of using "===" to mark default settings, how about instead
 prefixing those lines with "# "?  Then the output will be a valid settings
 file, with the settings not changed from the defaults commented out, which
 might be useful.

-- 
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] #11581: URLField verify_exists blocks 401 respones

[Django]

#11581: URLField verify_exists blocks 401 respones
--+
 Reporter:  rlaager@… |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  1.0
 Severity:  Normal|   Resolution:  wontfix
 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 mlavin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 {{{ verify_exists }}} is set to be deprecated in 1.4 and removed in 1.5
 related to security and performance issues. As such I'm going to close as
 wontfix.

-- 
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] #16563: Error pickling request.user

[Django]

#16563: Error pickling request.user
-+
 Reporter:  zero.fuxor@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.3
 Severity:  Release blocker  |   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 poirier):

 FYI, the current code that makes request.user a SimpleLazyObject is from
 changeset [16305], which was a re-working of [16297], to fix #15929.

 A comment cleaned up along the way said:
 {{{
 # If we access request.user, request.session is accessed, which
 results in
 # 'Vary: Cookie' being sent in every request that uses this context
 # processor, which can easily be every request on a site if
 # TEMPLATE_CONTEXT_PROCESSORS has this context processor added.  This
 kills
 # the ability to cache.  So, we carefully ensure these attributes are
 lazy.
 }}}
 which seems like a pretty good reason for making request.user lazy.

 Would it be possible to fix this instead by fixing the chain of events
 somewhere else?  e.g. should any access of request.session result in
 setting the Vary: Cookie header?

-- 
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] #16137: .get behaviour is inconsistent with .get_or_create when no kwargs are given

[Django]

#16137: .get behaviour is inconsistent with .get_or_create when no kwargs are 
given
-+-
 Reporter:  wilfred@…|Owner:  poirier
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by poirier):

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


Comment:

 Updated patch to apply to Django trunk.
 Added brief note to 1.4 release notes.

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

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

Re: [Django] #16137: .get behaviour is inconsistent with .get_or_create when no kwargs are given

[Django]

#16137: .get behaviour is inconsistent with .get_or_create when no kwargs are 
given
-+-
 Reporter:  wilfred@…|Owner:  poirier
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by poirier):

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


-- 
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] #17215: runtests doesn't clean up all temp files all the time

[Django]

#17215: runtests doesn't clean up all temp files all the time
---+
 Reporter:  kmtracey   |Owner:  kmtracey
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 kmtracey):

 * owner:  nobody => kmtracey


-- 
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] #10504: Consistency between HttpResponse* params and render_to_response

[Django]

#10504: Consistency between HttpResponse* params and render_to_response
--+
 Reporter:  bhagany   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  Version:  1.0
 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 kenth):

 * needs_tests:  1 => 0


Comment:

 Added tests for new shortcut.

-- 
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] #17215: runtests doesn't clean up all temp files all the time

[Django]

#17215: runtests doesn't clean up all temp files all the time
---+
 Reporter:  kmtracey   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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
---+

Comment (by kmtracey):

 Replying to [comment:1 aaugustin]:
 > I cleaned /tmp on the CI server, but that bug should be fixed
 nonetheless.

 Thanks! And oh yes we should fix the tests to not require periodic /tmp
 cleanup.

 It seems a clean test run leaves behind 47 (!) /tmp/tmp
 directories. 47*15 configs on the ci server is 705 directories
 accumulating per commit. That means less than 50 commits  before we again
 hit the 32,000 file in the directory limit

-- 
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] #15646: Document that the FileField's path can not be relied on until the model is saved

[Django]

#15646: Document that the FileField's path can not be relied on until the model 
is
saved
-+-
 Reporter:  anonymous|Owner:  poirier
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  storage system path  | Triage Stage:  Accepted
  upload_to  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by poirier):

 * owner:  nobody => poirier
 * status:  new => assigned
 * ui_ux:   => 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] #16818: Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't commit to database

[Django]

#16818: Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't
commit to database
-+-
 Reporter:  pressureman  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kmtracey):

 * owner:  kmtracey => nobody
 * has_patch:  0 => 1


Comment:

 Attached patch makes the test run successfully on the 3 backends I have
 available to test where it was failing before (sqlite3, MySQL/InnoDB,
 PostgreSQL). Possibly it would be a good idea to factor out that force-
 managed stuff into a reusable bit that could be shared by different
 operations that require it...in a brief scan I see it in the insert (where
 I stole it from) and now bulk_insert and django/db/models/deletion.py has
 something very similar. But first I'd like some confirmation from someone
 with more ORM knowledge than me that that's the right thing to do to
 correct the error here.

-- 
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] #16416: date template tag should support "e" and "o" format character

[Django]

#16416: date template tag should support "e" and "o" format character
-+
 Reporter:  CarstenF |Owner:  poirier
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  ISO 8601 | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by poirier):

 * has_patch:  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.

[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:  Uncategorized  | Status:  new
Component:  Translations   |Version:
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 Space was replaced with nbsp only for Polish locale:
 https://code.djangoproject.com/ticket/13577
 I wonder why it hasn't been done for all other locales that use a space as
 a thousand separator.

-- 
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] #17216: Django contrib login view does not pass request to auth form on POST

[Django]

#17216: Django contrib login view does not pass request to auth form on POST
--+-
 Reporter:  Zaar Hai   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.3
 Severity:  Normal|   Keywords:  auth, login
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Django auth login view pass request to auth form constructor on only on
 GET and not on POST.
 I need this on post as well because it will enables doing additional
 validation in custom supplied auth form.

 So how about the attached 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] #17215: runtests doesn't clean up all temp files all the time

[Django]

#17215: runtests doesn't clean up all temp files all the time
---+
 Reporter:  kmtracey   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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


Comment:

 I cleaned /tmp on the CI server, but that bug should be fixed nonetheless.

-- 
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] #16632: 204 (No Content) responses without content-type crashes django if UA is Internet Explorer

[Django]

#16632: 204 (No Content) responses without content-type crashes django if UA is
Internet Explorer
---+
 Reporter:  juan@… |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  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 kenth):

 * needs_tests:  1 => 0


Comment:

 Added tests to confirm bug & 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] #7463: alternate phone regex for US flavor forms

[Django]

#7463: alternate phone regex for US flavor forms
-+-
 Reporter:  kevin@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.localflavor  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor forms| Triage Stage:  Accepted
  areacode delimiter |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by mlavin):

 * ui_ux:   => 0
 * needs_tests:  1 => 0


Comment:

 Updated the patch to apply to latest trunk and included new valid patterns
 to localflavor tests.

-- 
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] #16744: Class based view should have the view object in the context

[Django]

#16744: Class based view should have the view object in the context
---+
 Reporter:  reinout|Owner:  tobias
 Type:  New feature|   Status:  assigned
Component:  Generic views  |  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 tobias):

 * has_patch:  0 => 1


Comment:

 Patch request with tests and docs here:
 https://github.com/django/django/pull/80

 From what I could tell, all destructive view methods require an argument,
 so they can't be called from the template anyways.

-- 
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] #16684: BaseForm needs to escape the 'class' attribute value

[Django]

#16684: BaseForm needs to escape the 'class' attribute value
---+
 Reporter:  dtrebbien  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by mlavin):

 {{{ conditional_escape }}} is not appropriate for this issue and this test
 is not correct. Using the example from the CSS spec, {{{
 conditional_escape }}} would convert {{{ B }}} to {{{ BW }}} not
 the correct {{{ B\ }}}. The test currently converts the class name {{{
 \ }}} to {{{ \\required }}} which is not a valid class name.

 To handle this there would need to be another escape function for handling
 css escaping rules. It seems as though it developers choose to use these
 characters in their css they can handle the escaping themselves. I don't
 see why this would need to be a part of Django.

-- 
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] #16416: date template tag should support "e" and "o" format character

[Django]

#16416: date template tag should support "e" and "o" format character
-+
 Reporter:  CarstenF |Owner:  poirier
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  ISO 8601 | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by poirier):

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


-- 
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] #13640: add_filter in django/db/models/ sql/query.py causes exception when model have 'evaluate' attribute

[Django]

#13640: add_filter in django/db/models/ sql/query.py causes exception when model
have 'evaluate' attribute
-+-
 Reporter:  LukaszKorzybski  |Owner:  tobias
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   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 kmtracey):

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


Comment:

 In [17093]:
 {{{
 #!CommitTicketReference repository="" revision="17093"
 Fixed #13640: Avoid generating an exception when a model has an attribute
 named 'evaluate'. Thanks LukaszKorzybski and tobias.
 }}}

-- 
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] r17093 - in django/trunk: django/db/models/sql tests/regressiontests/model_regress

[noreply]

Author: kmtracey
Date: 2011-11-13 07:09:08 -0800 (Sun, 13 Nov 2011)
New Revision: 17093

Modified:
   django/trunk/django/db/models/sql/query.py
   django/trunk/tests/regressiontests/model_regress/tests.py
Log:
Fixed #13640: Avoid generating an exception when a model has an attribute named 
'evaluate'. Thanks LukaszKorzybski and tobias.

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2011-11-13 00:43:02 UTC (rev 
17092)
+++ django/trunk/django/db/models/sql/query.py  2011-11-13 15:09:08 UTC (rev 
17093)
@@ -14,6 +14,7 @@
 from django.utils.tree import Node
 from django.db import connections, DEFAULT_DB_ALIAS
 from django.db.models import signals
+from django.db.models.expressions import ExpressionNode
 from django.db.models.fields import FieldDoesNotExist
 from django.db.models.query_utils import InvalidQuery
 from django.db.models.sql import aggregates as base_aggregates_module
@@ -1064,7 +1065,7 @@
 value = True
 elif callable(value):
 value = value()
-elif hasattr(value, 'evaluate'):
+elif isinstance(value, ExpressionNode):
 # If value is a query expression, evaluate it
 value = SQLEvaluator(value, self)
 having_clause = value.contains_aggregate

Modified: django/trunk/tests/regressiontests/model_regress/tests.py
===
--- django/trunk/tests/regressiontests/model_regress/tests.py   2011-11-13 
00:43:02 UTC (rev 17092)
+++ django/trunk/tests/regressiontests/model_regress/tests.py   2011-11-13 
15:09:08 UTC (rev 17093)
@@ -164,8 +164,23 @@
 1
 )
 
+
 class ModelValidationTest(TestCase):
 def test_pk_validation(self):
 one = NonAutoPK.objects.create(name="one")
 again = NonAutoPK(name="one")
 self.assertRaises(ValidationError, again.validate_unique)
+
+
+class EvaluateMethodTest(TestCase):
+"""
+Regression test for #13640: cannot filter by objects with 'evaluate' attr
+"""
+
+def test_model_with_evaluate_method(self):
+"""
+Ensures that you can filter by objects that have an 'evaluate' attr
+"""
+dept = Department.objects.create(pk=1, name='abc')
+dept.evaluate = 'abc'
+Worker.objects.filter(department=dept)

-- 
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] #17166: The fixture documentation tells nowhere that you can (should?) use FIXTURE_DIRS in your settings.py

[Django]

#17166: The fixture documentation tells nowhere that you can (should?) use
FIXTURE_DIRS in your settings.py
--+
 Reporter:  anonymous |Owner:  poirier
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  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:  1 |UI/UX:  0
--+
Changes (by poirier):

 * has_patch:  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.

[Django] #17215: runtests doesn't clean up all temp files all the time

[Django]

#17215: runtests doesn't clean up all temp files all the time
-+
   Reporter:  kmtracey   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 http://ci.djangoproject.com/job/Django/ builds started failing yesterday
 due to too many files in /tmp:

 
http://ci.djangoproject.com/job/Django/461/database=sqlite3,python=python2.5/console

 There were nearly 300 /tmp/django_ directories that had
 accumulated, and looking at my own machine's tmp directory I see a bunch
 of other /tmp/tmp directories that have accumulated in just the
 last day.

-- 
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] #17166: The fixture documentation tells nowhere that you can (should?) use FIXTURE_DIRS in your settings.py

[Django]

#17166: The fixture documentation tells nowhere that you can (should?) use
FIXTURE_DIRS in your settings.py
--+
 Reporter:  anonymous |Owner:  poirier
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by poirier):

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


-- 
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] #17174: The docs should mention, that MySql doesn't support microseconds

[Django]

#17174: The docs should mention, that MySql doesn't support microseconds
---+
 Reporter:  jammon |Owner:  poirier
 Type:  New feature|   Status:  assigned
Component:  Documentation  |  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:  1  |UI/UX:  0
---+
Changes (by poirier):

 * has_patch:  0 => 1
 * easy:  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] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
-+-
 Reporter:  mlavin   |Owner:  tobias
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by tobias):

 Ensuring that calling str() on an object will not raise an exception seems
 like a pretty basic improvement to me as well.  I'm not sure why this
 trivial fix is getting so much push back.

-- 
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] #17174: The docs should mention, that MySql doesn't support microseconds

[Django]

#17174: The docs should mention, that MySql doesn't support microseconds
---+
 Reporter:  jammon |Owner:  poirier
 Type:  New feature|   Status:  assigned
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by poirier):

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


-- 
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] #17188: Add use_ssl parameter to HttpResponseRedirect shortcut

[Django]

#17188: Add use_ssl parameter to HttpResponseRedirect shortcut
---+--
 Reporter:  briancray  |Owner:  nobody
 Type:  New feature|   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 poirier):

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


Comment:

 Why does middleware require a double redirect? Couldn't middleware force
 the 'https:" on the location header in the response?  I think django-
 secure will do this for you.  There's also another ticket, 17102, to add
 this feature to Django itself.

-- 
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] #13640: add_filter in django/db/models/ sql/query.py causes exception when model have 'evaluate' attribute

[Django]

#13640: add_filter in django/db/models/ sql/query.py causes exception when model
have 'evaluate' attribute
-+-
 Reporter:  LukaszKorzybski  |Owner:  tobias
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by tobias):

 Sorry about that, it's been so long since I wrote the original patch I
 honestly had forgotten doing it, and it seemed like a pretty trivial fix
 to me.  I'll make sure I get someone else to review it next time.

-- 
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] #15271: django.contrib.gis.forms.fields.GeometryField should call to_python before cleaning

[Django]

#15271: django.contrib.gis.forms.fields.GeometryField should call to_python 
before
cleaning
-+-
 Reporter:  volrath  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  gis, field, clean,   | Triage Stage:  Accepted
  to_python  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by copelco):

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


Comment:

 I reviewed volrath's patches and consolidated them into a single file. I
 also created a pull request here:

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

-- 
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] #17188: Add use_ssl parameter to HttpResponseRedirect shortcut (was: Addition to HttpResponseRedirect shortcut)

[Django]

#17188: Add use_ssl parameter to HttpResponseRedirect shortcut
---+--
 Reporter:  briancray  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by poirier):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 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] #16865: get_or_create defaults to _for_write even when it's just reading

[Django]

#16865: get_or_create defaults to _for_write even when it's just reading
-+-
 Reporter:  Rick van Hattem  |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by WoLpH):

 @calvinspealman: it is called '''get'''_or_create isn't it? All of the
 Django code that uses it makes the assumption that it is always available
 and just falls back to creating if it is indeed new. And as you can see in
 the code, it is implemented as such. It does a get with a fallback to
 create. In your case it would be a create with a fallback to get if you
 get an integrity error.

 @kmtracey: You are right, it all depends on your replication method which
 it why this code has been working flawlessly for me so far. Regardless,
 the current system definately breaks any kind of master slave setup which
 is just silly.

 Perhaps the current database routers need an extra method for that. Right
 now we have the `db_for_write` and `db_for_read` but in this case it might
 be useful to have a `db_for_realtime_read` or something. Assuming that the
 database which you write to is also the one you want to read from is not
 in all cases right.

-- 
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] #15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute '_table_row_index'

[Django]

#15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute
'_table_row_index'
---+--
 Reporter:  bmihelac   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 #17177 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] #13640: add_filter in django/db/models/ sql/query.py causes exception when model have 'evaluate' attribute

[Django]

#13640: add_filter in django/db/models/ sql/query.py causes exception when model
have 'evaluate' attribute
-+-
 Reporter:  LukaszKorzybski  |Owner:  tobias
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by aaugustin):

 * stage:  Ready for checkin => Accepted


Comment:

 You shouldn't mark your own patches as "ready for checkin"; a review by
 someone else is required.

-- 
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] #17180: Documentation should mention that {% load i18n %} is needed in every template

[Django]

#17180: Documentation should mention that {% load i18n %} is needed in every
template
--+
 Reporter:  stefan.freyr@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by aaugustin):

 I accepted this ticket on the grounds that a little hand-holding can't
 hurt, and that our docs often have some overlap with related topics.

 I don't have strong feelings one way or another; we could mark it as
 "wontfix" to avoid duplicating information.

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