date:20111021

[Django] #17086: humanize and markup tests modify global templatetags library state

2011-10-21 Thread Django

#17086: humanize and markup tests modify global templatetags library state
+
   Reporter:  carljm|  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.humanize  |Version:  SVN
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The tests for both `contrib.humanize` and `contrib.markitup` use
 `add_to_builtins` to (permanently) add their respective template tag
 libraries to the context of all rendered templates. This is done at
 module-level in their test modules, and there is no attempt to clean up or
 isolate the effect of this change.

 This can cause templates rendered in unrelated user tests to behave
 differently depending on whether they are run alone or as part of a suite
 including the markup/humanize tests. For instance, if a template fails to
 `{% load markup %}` or `{% load humanize %}` when it should, and a test
 renders that template, that test would succeed under a full `manage.py
 test` but fail if run without the contrib/humanize tests.

 This also affects Django's own test suite.

 I think the proper solution here is to (a) use the appropriate `{% load
 %}` tags in the test templates for those test suites, and (b) temporarily
 monkeypatch `django.template.base.templatetags_modules` so that it
 includes the templatetag module for humanize during humanize's tests, and
 likewise for markup.

 If #17085 is fixed, it would provide an alternative way to fix this
 without needing the monkeypatch.

-- 
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] #17085: Deprecate "add_to_builtins" and replace with API on Template (was: Deprecate "add_to_builtins")

2011-10-21 Thread Django

#17085: Deprecate "add_to_builtins" and replace with API on Template
-+--
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 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
-+--

-- 
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] #17085: Deprecate "add_to_builtins"

2011-10-21 Thread Django

#17085: Deprecate "add_to_builtins"
---+
   Reporter:  carljm   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  Template system  |Version:  SVN
   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|
---+
 `add_to_builtins` modifies global process state. This is to be avoided
 whenever possible, and in this case there would be a much better
 alternative: provide an API on a Template object to inject templatetag
 libraries as "built-in" for that Template. This provides the same effect
 as `add_to_builtins` but in a localized and explicit way. If the tag
 library should be effectively built-in for the whole project, just use a
 custom `render_to_response` equivalent (or `TemplateResponse` subclass)
 that uses this API to inject the library for each Template rendered.

 Deprecating `add_to_builtins` is another step on the path of cleaning up
 globally-stored settings-related state in Django, which needs to be done
 if we're going to clean up settings as process-global.

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

2011-10-21 Thread noreply

Author: Alex
Date: 2011-10-21 23:13:01 -0700 (Fri, 21 Oct 2011)
New Revision: 17024

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Fixed the grammar of a sentence in the docs.

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-10-22 06:06:44 UTC (rev 17023)
+++ django/trunk/docs/releases/1.4.txt  2011-10-22 06:13:01 UTC (rev 17024)
@@ -58,7 +58,7 @@
 This method allows for more efficient creation of multiple objects in the ORM.
 It can provide significant performance increases if you have many objects,
 Django makes use of this internally, meaning some operations (such as database
-setup for test suites) has seen a performance benefit as a result.
+setup for test suites) have seen a performance benefit as a result.
 
 See the :meth:`~django.db.models.query.QuerySet.bulk_create` docs for more
 information.

-- 
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] r17023 - django/trunk/django/contrib/humanize

2011-10-21 Thread noreply

Author: carljm
Date: 2011-10-21 23:06:44 -0700 (Fri, 21 Oct 2011)
New Revision: 17023

Modified:
   django/trunk/django/contrib/humanize/tests.py
Log:
Mocked datetime in the naturaltime tests to avoid sporadic test failure.

Modified: django/trunk/django/contrib/humanize/tests.py
===
--- django/trunk/django/contrib/humanize/tests.py   2011-10-22 04:30:10 UTC 
(rev 17022)
+++ django/trunk/django/contrib/humanize/tests.py   2011-10-22 06:06:44 UTC 
(rev 17023)
@@ -159,4 +159,21 @@
 '1 day from now',
 '1 year, 4 months from now',
 ]
-self.humanize_tester(test_list, result_list, 'naturaltime')
+
+# mock out datetime so these tests don't fail occasionally when the
+# test runs too slow
+class MockDateTime(object):
+def now(self):
+return now
+
+def __call__(self, *args, **kwargs):
+return datetime(*args, **kwargs)
+
+from django.contrib.humanize.templatetags import humanize
+orig_datetime = humanize.datetime
+humanize.datetime = MockDateTime()
+
+try:
+self.humanize_tester(test_list, result_list, 'naturaltime')
+finally:
+humanize.datetime = orig_datetime

-- 
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] #8927: Make Request proxy the WSGI environ

2011-10-21 Thread Django

#8927: Make Request proxy the WSGI environ
---+
 Reporter:  simon  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by carljm):

 * ui_ux:   => 0
 * version:  1.0 => SVN
 * easy:   => 0


Comment:

 It's become a bit muddy what would qualify as a "fix" for this bug.
 `request.environ` exists; the only patch that's been submitted here is to
 make it available under `mod_python` as well, but that's not really
 relevant since the `mod_python` handler is deprecated and soon to be
 removed. Having requests "proxy" the environ suggests perhaps something
 deeper, maybe that changes to the `HttpRequest` instance would actually be
 reflected in corresponding changes in the `environ`? Not sure how
 important that actually is in practice.

 Looking at Mark Ramm's initial comment about `call_wsgi_app`, it seems
 that the actual request is to include something like
 [https://github.com/alex/django-wsgi/blob/master/django_wsgi.py django-
 wsgi] in core, to allow easy "adaptation" between Django view functions
 and/or urlconfs and WSGI callables. The fact that that code is so short
 demonstrates that the needed pieces are already in place, it's a matter of
 making it more convenient.

 I think adding such adapter functions to Django core makes sense, and
 fills in really the last major gap in Django WSGI support. Filed also as
 https://github.com/alex/django-wsgi/issues/2

-- 
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] #16360: Add a standard entrypoint for WSGI to project template

2011-10-21 Thread Django

#16360: Add a standard entrypoint for WSGI to project template
--+
 Reporter:  jezdez|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

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


Comment:

 In [17022]:
 {{{
 #!CommitTicketReference repository="" revision="17022"
 Fixed #16360 -- Added WSGI entrypoint to startproject layout, and enabled
 internal servers (runserver and runfcgi) to use an externally-defined WSGI
 application. Thanks to Armin Ronacher, Jannis Leidel, Alex Gaynor, ptone,
 and Jacob Kaplan-Moss.
 }}}

-- 
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] r17021 - in django/trunk/django/contrib/admin/static/admin: css js/admin

2011-10-21 Thread noreply

Author: julien
Date: 2011-10-21 20:38:10 -0700 (Fri, 21 Oct 2011)
New Revision: 17021

Modified:
   django/trunk/django/contrib/admin/static/admin/css/widgets.css
   django/trunk/django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js
Log:
Fixed #17064 -- Improved the UX for the admin's time and date picker widgets by 
brushing up the 'Cancel' button's visual feedback and by allowing the popups to 
get closed by pressing the 'Escape' key.

Modified: django/trunk/django/contrib/admin/static/admin/css/widgets.css
===
--- django/trunk/django/contrib/admin/static/admin/css/widgets.css  
2011-10-21 23:38:52 UTC (rev 17020)
+++ django/trunk/django/contrib/admin/static/admin/css/widgets.css  
2011-10-22 03:38:10 UTC (rev 17021)
@@ -379,15 +379,19 @@
 
 .calendar-cancel {
 margin: 0 !important;
-padding: 0;
+padding: 0 !important;
 font-size: 10px;
 background: #e1e1e1 url(../img/nav-bg.gif) 0 50% repeat-x;
 border-top: 1px solid #ddd;
 }
 
+.calendar-cancel:hover {
+background: #e1e1e1 url(../img/nav-bg-reverse.gif) 0 50% repeat-x;
+}
+
 .calendar-cancel a {
-padding: 2px;
-color: #999;
+color: black;
+display: block;
 }
 
 ul.timelist, .timelist li {

Modified: 
django/trunk/django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js
===
--- 
django/trunk/django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js
2011-10-21 23:38:52 UTC (rev 17020)
+++ 
django/trunk/django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js
2011-10-22 03:38:10 UTC (rev 17021)
@@ -79,17 +79,24 @@
 addEvent(clock_box, 'click', DateTimeShortcuts.cancelEventPropagation);
 
 quickElement('h2', clock_box, gettext('Choose a time'));
-time_list = quickElement('ul', clock_box, '');
+var time_list = quickElement('ul', clock_box, '');
 time_list.className = 'timelist';
-time_format = get_format('TIME_INPUT_FORMATS')[0];
+var time_format = get_format('TIME_INPUT_FORMATS')[0];
 quickElement("a", quickElement("li", time_list, ""), gettext("Now"), 
"href", "javascript:DateTimeShortcuts.handleClockQuicklink(" + num + ", new 
Date().strftime('" + time_format + "'));");
 quickElement("a", quickElement("li", time_list, ""), 
gettext("Midnight"), "href", 
"javascript:DateTimeShortcuts.handleClockQuicklink(" + num + ", new 
Date(1970,1,1,0,0,0,0).strftime('" + time_format + "'));");
 quickElement("a", quickElement("li", time_list, ""), gettext("6 
a.m."), "href", "javascript:DateTimeShortcuts.handleClockQuicklink(" + num + ", 
new Date(1970,1,1,6,0,0,0).strftime('" + time_format + "'));");
 quickElement("a", quickElement("li", time_list, ""), gettext("Noon"), 
"href", "javascript:DateTimeShortcuts.handleClockQuicklink(" + num + ", new 
Date(1970,1,1,12,0,0,0).strftime('" + time_format + "'));");
 
-cancel_p = quickElement('p', clock_box, '');
+var cancel_p = quickElement('p', clock_box, '');
 cancel_p.className = 'calendar-cancel';
 quickElement('a', cancel_p, gettext('Cancel'), 'href', 
'javascript:DateTimeShortcuts.dismissClock(' + num + ');');
+django.jQuery(document).bind('keyup', function(event) {
+if (event.which == 27) {
+// ESC key closes popup
+DateTimeShortcuts.dismissClock(num);
+event.preventDefault();
+}
+});
 },
 openClock: function(num) {
 var clock_box = 
document.getElementById(DateTimeShortcuts.clockDivName+num)
@@ -195,6 +202,13 @@
 var cancel_p = quickElement('p', cal_box, '');
 cancel_p.className = 'calendar-cancel';
 quickElement('a', cancel_p, gettext('Cancel'), 'href', 
'javascript:DateTimeShortcuts.dismissCalendar(' + num + ');');
+django.jQuery(document).bind('keyup', function(event) {
+if (event.which == 27) {
+// ESC key closes popup
+DateTimeShortcuts.dismissCalendar(num);
+event.preventDefault();
+}
+});
 },
 openCalendar: function(num) {
 var cal_box = 
document.getElementById(DateTimeShortcuts.calendarDivName1+num)

-- 
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] #17064: Small UX improvements to the admin's time and date picker

2011-10-21 Thread Django

#17064: Small UX improvements to the admin's time and date picker
--+
 Reporter:  julien|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+
Changes (by julien):

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


Comment:

 In [17021]:
 {{{
 #!CommitTicketReference repository="" revision="17021"
 Fixed #17064 -- Improved the UX for the admin's time and date picker
 widgets by brushing up the 'Cancel' button's visual feedback and by
 allowing the popups to get closed by pressing the 'Escape' key.
 }}}

-- 
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] #16574: Test fails when setting MESSAGE_TAGS

2011-10-21 Thread Django

#16574: Test fails when setting MESSAGE_TAGS
--+
 Reporter:  Boldewyn  |Owner:  elbarto
 Type:  Bug   |   Status:  new
Component:  contrib.messages  |  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 julien):

 * needs_better_patch:  0 => 1


Comment:

 Thanks, the patch is generally looking good. However, I'm now getting 3
 failures. Am I missing something?

 {{{
 python manage.py test messages
 Creating test database for alias 'default'...
 ..F..F...F..
 ==
 FAIL: test_tags (django.contrib.messages.tests.cookie.CookieTest)
 --
 Traceback (most recent call last):
   File
 
"/Users/julien/Documents/Development/eclipse/workspace/DjangoCore/git/django/contrib/messages/tests/base.py",
 line 339, in test_tags
 'success'])
 AssertionError: Lists differ: [u'info', '', u'extra-tag debu... !=
 ['info', '', 'extra-tag debug'...

 First differing element 4:
 ui-state-error
 error

 - [u'info', '', u'extra-tag debug', u'warning', u'ui-state-error',
 u'success']
 ?  --   -   - --

 + ['info', '', 'extra-tag debug', 'warning', 'error', 'success']

 ==
 FAIL: test_tags (django.contrib.messages.tests.fallback.FallbackTest)
 --
 Traceback (most recent call last):
   File
 
"/Users/julien/Documents/Development/eclipse/workspace/DjangoCore/git/django/contrib/messages/tests/base.py",
 line 339, in test_tags
 'success'])
 AssertionError: Lists differ: [u'info', '', u'extra-tag debu... !=
 ['info', '', 'extra-tag debug'...

 First differing element 4:
 ui-state-error
 error

 - [u'info', '', u'extra-tag debug', u'warning', u'ui-state-error',
 u'success']
 ?  --   -   - --

 + ['info', '', 'extra-tag debug', 'warning', 'error', 'success']

 ==
 FAIL: test_tags (django.contrib.messages.tests.session.SessionTest)
 --
 Traceback (most recent call last):
   File
 
"/Users/julien/Documents/Development/eclipse/workspace/DjangoCore/git/django/contrib/messages/tests/base.py",
 line 339, in test_tags
 'success'])
 AssertionError: Lists differ: [u'info', '', u'extra-tag debu... !=
 ['info', '', 'extra-tag debug'...

 First differing element 4:
 ui-state-error
 error

 - [u'info', '', u'extra-tag debug', u'warning', u'ui-state-error',
 u'success']
 ?  --   -   - --

 + ['info', '', 'extra-tag debug', 'warning', 'error', 'success']

 --
 Ran 72 tests in 0.937s

 FAILED (failures=3)
 Destroying test database for alias 'default'...
 }}}

-- 
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] #3357: Make Django's server optionally multithreaded

2011-10-21 Thread Django

#3357: Make Django's server optionally multithreaded
-+-
 Reporter:  treborhudson@…   |Owner:  adrian
 Type:  Uncategorized|   Status:  closed
Component:  django-admin.py  |  Version:  SVN
  runserver  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  post10   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Note also #16099 reversed the wontfix on this, the threading mixin and an
 option to disable its use were added in r16427.

-- 
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] #16360: Add a standard entrypoint for WSGI to project template

2011-10-21 Thread Django

#16360: Add a standard entrypoint for WSGI to project template
--+
 Reporter:  jezdez|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

 * needs_docs:  1 => 0


Comment:

 This now has tests, several people have reviewed the docs, and the
 instructions for all three WSGI servers have been tested and work. I think
 it's ready and will commit soon, though I wouldn't mind having someone do
 a final once-over first for anything I may have missed.

-- 
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] r17020 - django/trunk/django/utils

2011-10-21 Thread noreply

Author: Alex
Date: 2011-10-21 16:38:52 -0700 (Fri, 21 Oct 2011)
New Revision: 17020

Modified:
   django/trunk/django/utils/functional.py
Log:
move an mport out of a function

Modified: django/trunk/django/utils/functional.py
===
--- django/trunk/django/utils/functional.py 2011-10-20 20:08:33 UTC (rev 
17019)
+++ django/trunk/django/utils/functional.py 2011-10-21 23:38:52 UTC (rev 
17020)
@@ -1,3 +1,4 @@
+import copy
 import operator
 from functools import wraps, update_wrapper
 
@@ -258,7 +259,6 @@
 memo[id(self)] = result
 return result
 else:
-import copy
 return copy.deepcopy(self._wrapped, memo)
 
 # Need to pretend to be the wrapped class, for the sake of objects that 
care

-- 
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] #17021: views.generic.create_update.lo okup_object uses .objects instead of the default manager

2011-10-21 Thread Django

#17021: views.generic.create_update.lo okup_object uses .objects instead of the
default manager
---+--
 Reporter:  salgado|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Generic views  |  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
---+--
Changes (by Alex):

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


Comment:

 function-based generic views are deprecated, thus closing 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] #16948: Django DB backends hid information in database exceptions

2011-10-21 Thread Django

#16948: Django DB backends hid information in database exceptions
-+-
 Reporter:  jamesh   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alex):

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


Comment:

 Marking as a dupe of #15901

-- 
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] #16945: Extend LazyObject to accept constructor parameters

2011-10-21 Thread Django

#16945: Extend LazyObject to accept constructor parameters
--+--
 Reporter:  mitar |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  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
--+--
Changes (by Alex):

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


Comment:

 Marking as wontfix, this is not part of the public API, it isn't needed in
 Django, and if you insist on using it in your own code anyways, you can
 easily add this functionality in your own subclass.

-- 
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] #17027: Let ExpressionNodes use pow

2011-10-21 Thread Django

#17027: Let ExpressionNodes use __pow__
-+-
 Reporter:  dan@…|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:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Alex):

 * needs_better_patch:   => 1
 * needs_docs:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 1
 * 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] #17084: URL conf is evaluated after form Metas

2011-10-21 Thread Django

#17084: URL conf is evaluated after form Metas
---+--
 Reporter:  reames@…   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Alex):

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


Comment:

 This is a natural artifact of how Python's module and import systems work.
 As a result, in 1.4 we introduced reverse_lazy, which works in these
 circumstances: https://docs.djangoproject.com/en/dev/topics/http/urls
 /#reverse-lazy

-- 
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] #17084: URL conf is evaluated after form Metas

2011-10-21 Thread Django

#17084: URL conf is evaluated after form Metas
---+
 Reporter:  reames@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have a model form that looks something like:
 {{{
 class MyForm(forms.ModelForm):
   class Meta(object):
 model = Foo
 my_data = urlresolvers.reverse('myview')
 }}}

 This causes the following error:
   Exception Type: !ImproperlyConfigured

   Exception Value: The included urlconf project.urls doesn't have any
 patterns in it

 I believe this is probably because forms are evaluated before the URL
 resolvers are.

-- 
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] #17020: Error in Tests: Causes a TemplateNotFound Exception

2011-10-21 Thread Django

#17020: Error in Tests: Causes a TemplateNotFound Exception
--+-
 Reporter:  dstufft   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.messages  |  Version:  1.3
 Severity:  Normal|   Resolution:  duplicate
 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 claudep):

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


Comment:

 #16507 seems to tackle the same issue.

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

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

Re: [Django] #16574: Test fails when setting MESSAGE_TAGS

2011-10-21 Thread Django

#16574: Test fails when setting MESSAGE_TAGS
--+
 Reporter:  Boldewyn  |Owner:  elbarto
 Type:  Bug   |   Status:  new
Component:  contrib.messages  |  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
--+

Comment (by claudep):

 Just added a patch that uses override_settings throughout the
 contrib.messages 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.

[Django] #17083: sessions.backends.cache does not allow non-default cache to be configured

2011-10-21 Thread Django

#17083: sessions.backends.cache does not allow non-default cache to be 
configured
--+
 Reporter:  charles@… |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.sessions  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Django 1.3 introduced support for more than one cache to be defined.
 However, the cache-based session store backend does not support using a
 non-default backend.

 A configuration option should be available to select the cache to be used
 by the Django session store cache backend.

 Use case: One may want the session store to be kept in a replicated cache
 (to prevent user-visible disruption during failover events) vs cached data
 which can be regenerated without user-visible impact beyond performance.

 Use case: One may want the session store to be kept in a distributed cache
 while keeping other content in a system-local cache.

-- 
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] #11569: django.core.cache.backends.db has bad transaction handling

2011-10-21 Thread Django

#11569: django.core.cache.backends.db has bad transaction handling
-+-
 Reporter:  Glenn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gerdemb):

 The attached patch modifies the _base_set() function for the database
 backend so that the INSERT INTO statement will not insert duplicated cache
 keys. It uses an SQL "trick", but it is standard SQL and should be
 compatible with all the database backends. I've been using it with success
 on PostgreSQL.

-- 
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] #13906: REPEATABLE READ (as used by default on MySQL) breaks atleast QuerySet.get_or_create().

2011-10-21 Thread Django

#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
-+-
 Reporter:  sebastian_noack  |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:  mysql transaction|  Patch needs improvement:  1
  isolation  |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by gerdemb):

 * cc: gerdemb (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] #6641: Concurrency issue with get_or_create

2011-10-21 Thread Django

#6641: Concurrency issue with get_or_create
-+-
 Reporter:  JEFFGUINNESS |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  get_or_create|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gerdemb):

 * cc: gerdemb (added)
 * 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] #11569: django.core.cache.backends.db has bad transaction handling

2011-10-21 Thread Django

#11569: django.core.cache.backends.db has bad transaction handling
-+-
 Reporter:  Glenn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gerdemb):

 * cc: gerdemb (added)
 * ui_ux:   => 0
 * easy:   => 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] #16574: Test fails when setting MESSAGE_TAGS

2011-10-21 Thread Django

#16574: Test fails when setting MESSAGE_TAGS
--+
 Reporter:  Boldewyn  |Owner:  elbarto
 Type:  Bug   |   Status:  new
Component:  contrib.messages  |  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 elbarto):

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

Re: [Django] #16574: Test fails when setting MESSAGE_TAGS

2011-10-21 Thread Django

#16574: Test fails when setting MESSAGE_TAGS
--+
 Reporter:  Boldewyn  |Owner:  elbarto
 Type:  Bug   |   Status:  new
Component:  contrib.messages  |  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 elbarto):

 With this patch it passes the tests:

 {{{
 bsanchez@bsanchez:~/test/testproject$ python manage.py test messages
 Creating test database for alias 'default'...
 
 --
 Ran 72 tests in 0.478s

 OK
 Destroying test database for alias 'default'...
 bsanchez@bsanchez:~/test/testproject$
 }}}

 On the other hand, I set the decorator in the class instead of the method
 because it fails there:

 {{{
 bsanchez@bsanchez:~/test/testproject$ python manage.py test messages
 Creating test database for alias 'default'...
 ..F.
 ==
 FAIL: test_tags (django.contrib.messages.tests.cookie.CookieTest)
 --
 Traceback (most recent call last):
   File "/home/bsanchez/src/trunk/django/test/utils.py", line 214, in inner
 return test_func(*args, **kwargs)
   File "/home/bsanchez/src/trunk/django/contrib/messages/tests/base.py",
 line 372, in test_tags
 'success'])
 AssertionError: Lists differ: [u'info', '', u'extra-tag debu... !=
 ['info', '', 'extra-tag debug'...

 First differing element 4:
 ui-state-error
 error

 - [u'info', '', u'extra-tag debug', u'warning', u'ui-state-error',
 u'success']
 ?  --   -   - --

 + ['info', '', 'extra-tag debug', 'warning', 'error', 'success']

 --
 Ran 72 tests in 0.467s

 FAILED (failures=1)
 Destroying test database for alias 'default'...
 bsanchez@bsanchez:~/test/testproject$
 }}}

-- 
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] #2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in mysql)

2011-10-21 Thread Django

#2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in
mysql)
-+-
 Reporter:  scanner@…|Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by todd.kennedy@…):

 * cc: todd.kennedy@… (removed)
 * needs_tests:  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] #2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in mysql)

2011-10-21 Thread Django

#2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in
mysql)
-+-
 Reporter:  scanner@…|Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by todd.kennedy@…):

 * cc: todd.kennedy@… (added)
 * needs_better_patch:  1 => 0
 * has_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] #17080: Custom fields using attname, Model init and Deserialization: hard-coded magic for relation fields

2011-10-21 Thread Django

#17080: Custom fields using attname, Model __init__ and Deserialization: 
hard-coded
magic for relation fields
-+-
 Reporter:  anentropic   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Core |  Version:  1.3
  (Serialization)|   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Accepted => Design decision needed


Comment:

 Ok, I was a bit quick to mark this accepted. There is no need for Django
 to fix this, as attname seems to be something that is internal to Django.
 There is this documentation in django/db/models/fields/`__init__.py`:
 {{{
 # A guide to Field parameters:
 #
 #   * name:  The name of the field specifed in the model.
 #   * attname:   The attribute to use on the model object. This is the
 same as
 #"name", except in the case of ForeignKeys, where "_id" is
 #appended.
 #   * db_column: The db_column specified in the model (or None).
 #   * column:The database column for this field. This is the same as
 #"attname", except if db_column is specified.
 }}}

 I couldn't find anything interesting about attname from Django's
 documentation.

 So, now my take is that if this is going to be fixed, the right fix is to
 define what attname and name really mean. And then fix the code to match
 that definition. Currently the definition for attname seems to be that it
 is to be used only with foreign keys.

 Marking this design decision needed.

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

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

Re: [Django] #17080: Custom fields using attname, Model init and Deserialization: hard-coded magic for relation fields

2011-10-21 Thread Django

#17080: Custom fields using attname, Model __init__ and Deserialization: 
hard-coded
magic for relation fields
--+
 Reporter:  anentropic|Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Core (Serialization)  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by akaariai):

 * component:  Uncategorized => Core (Serialization)
 * stage:  Unreviewed => Accepted


Comment:

 In the patch there is this code:
 {{{
 elif field.name != field.attname:
 data[field.attname] = field.to_python(field_value)

 # Handle all other fields
 else:
 data[field.name] = field.to_python(field_value)
 }}}

 Why not write it just as

 {{{
 # Handle all other fields
 else:
 data[field.attname] = field.to_python(field_value)
 }}}

 As far as I see that is equivalent to what is done in the patch. This also
 models what `__init__` is doing. It expects all other fields by attname.

 To get the patch in ready for checkin stage, you will need to write your
 test case as a normal Django test case, that is a patch to tests
 directory. tests/modeltests/serializers/ seems to be a good directory for
 this. It would also be good to check if other deserializers suffer from
 this problem.

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

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

Re: [Django] #17082: Login form should use HTML5 autofocus with JavaScript as fallback

2011-10-21 Thread Django

#17082: Login form should use HTML5 autofocus with JavaScript as fallback
-+-
 Reporter:  drhevans |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by drhevans):

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


Comment:

 Ah, ignore moronic patch; and forgive me for creating tickets when not
 really concentrating! Obviously autofocus attribute needs to be on the
 input, not the label, which requires slightly deeper patching.

-- 
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] #17082: Login form should use HTML5 autofocus with JavaScript as fallback

2011-10-21 Thread Django

#17082: Login form should use HTML5 autofocus with JavaScript as fallback
--+
 Reporter:  drhevans  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.admin |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  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] #17080: Custom fields using attname, Model init and Deserialization: hard-coded magic for relation fields

2011-10-21 Thread Django

#17080: Custom fields using attname, Model __init__ and Deserialization: 
hard-coded
magic for relation fields
---+--
 Reporter:  anentropic |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anentropic):

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


Comment:

 Although actually my minimal test case is still broken...!

 Just my actual working code uses something more like the field in the
 djangosnippet above, i.e. Field class + Descriptor ...so I'm happy to get
 that working at least.

-- 
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] #17080: Custom fields using attname, Model init and Deserialization: hard-coded magic for relation fields

2011-10-21 Thread Django

#17080: Custom fields using attname, Model __init__ and Deserialization: 
hard-coded
magic for relation fields
---+--
 Reporter:  anentropic |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anentropic):

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


Comment:

 Apologies...

 Everything works fine for me without any patch if I make my custom
 descriptor subclass '''property'''

 I was copying Django's existing descriptors, all of which seem to subclass
 '''object''' instead.

 Perhaps this could be documented.

-- 
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] #17080: Custom fields using attname, Model init and Deserialization: hard-coded magic for relation fields

2011-10-21 Thread Django

#17080: Custom fields using attname, Model __init__ and Deserialization: 
hard-coded
magic for relation fields
---+--
 Reporter:  anentropic |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anentropic):

 * needs_better_patch:  0 => 1


Comment:

 http://djangosnippets.org/snippets/2294/
 This field sets both name and attname in its descriptor, using
 ''instance.!__dict!__[self.field.name]''. That is different to other
 Django fields but allows the model to be initialised with either
 ''attname'' or ''name'' as a kwarg.

 However it needs different values supplied depending on if you use
 ''name'' or ''attname'' in the Model kwargs... my patch breaks this field
 by causing it to be initialised by ''attname'', but with a ''name'' type
 value.

 It seems we should have a flag on Field classes so they can tell Django
 whether they should be initialised by ''attname'' or ''name''.

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

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

Re: [Django] #17080: Custom fields using attname, Model init and Deserialization: hard-coded magic for relation fields

2011-10-21 Thread Django

#17080: Custom fields using attname, Model __init__ and Deserialization: 
hard-coded
magic for relation fields
---+--
 Reporter:  anentropic |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anentropic):

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


Comment:

 I've added a patch and test case. This fixes things for me.

-- 
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] #17081: runfcgi with daemonize=True requires aboslute path for pidfile parameter

2011-10-21 Thread Django

#17081: runfcgi with daemonize=True requires aboslute path for pidfile parameter
---+-
 Reporter:  bernhard.hollaender@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:  runfcgi
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 I was unable to start the fcgi server with the deamonize option set to
 true. The problem was that the PID file was specified using a relative
 path:

 $ python manage.py runfcgi method=prefork host=localhost daemonize=true
 port=9000 pidfile=fcgi.pid

 Unfortunately this did not return any error message, the process just
 returned but no daemon was created. Changin the pidfile option to an
 absolute path solved the issue.

 The same issue was reported here:
 http://community.webfaction.com/questions/4303/runfcgi-cant-demonize

 Observed on Ubuntu 10.10, python 2.6.6

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

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

Re: [Django] #1021: [PATCH] unique_together should check the uniqueness in the validation phase

2011-10-21 Thread Django

#1021: [PATCH] unique_together should check the uniqueness in the validation 
phase
--+
 Reporter:  Ian@… |Owner:  nobody
 Type:  defect|   Status:  closed
Component:  Validators|  Version:  SVN
 Severity:  major |   Resolution:  fixed
 Keywords:  model-validation  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by dasdasd@…):

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


Comment:

 [http://answers.yahoo.com/question/index?qid=20111021011406AA5arfi test
 post] moderators view closed tickets?

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

40 matches

Mail list logo