[Changeset] r16965 - django/trunk/docs/releases

[noreply]

Author: carljm
Date: 2011-10-12 23:41:40 -0700 (Wed, 12 Oct 2011)
New Revision: 16965

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Fixed a missed typo in the 1.4 release notes. Oops.

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-10-13 05:56:15 UTC (rev 16964)
+++ django/trunk/docs/releases/1.4.txt  2011-10-13 06:41:40 UTC (rev 16965)
@@ -359,7 +359,7 @@
 
 If settings, URLconf, and apps within the project are imported or referenced
 using the project-name prefix (e.g. ``myproject.settings``, ``ROOT_URLCONF =
-``myproject.urls``, etc), the new ``manage.py`` will need to be moved one
+"myproject.urls"``, etc), the new ``manage.py`` will need to be moved one
 directory up, so it is outside the project package rather than adjacent to
 ``settings.py`` and ``urls.py``.
 

-- 
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] #17044: Add "project layout and python path" page to documentation

[Django]

#17044: Add "project layout and python path" page to documentation
-+
   Reporter:  carljm |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Documentation  |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  |
-+
 It would be good to have a page in the docs that explains in a bit more
 detail why the default "startproject" layout is the way it is, how the
 python path gets set correctly so that it works (e.g. by "script
 directory" if you use manage.py, "current directory" otherwise), what
 directory should be manually added to sys.path in environments where
 neither of those apply, where you put packages in the layout if you want
 them to be top-level and where you put them if they should be inside the
 project package, etc. Some of this information is in the 1.4 release
 notes, there's a bunch more discussed in [this mailing list thread
 http://groups.google.com/group/django-
 developers/browse_frm/thread/44b70a37ff73298b].

-- 
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] #17042: allow startproject, startapp to write into existing directory or a specified directory

[Django]

#17042: allow startproject, startapp to write into existing directory or a
specified directory
-+-
 Reporter:  ptone|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ptone):

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


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

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

Re: [Django] #17042: allow startproject, startapp to write into existing directory or a specified directory

[Django]

#17042: allow startproject, startapp to write into existing directory or a
specified directory
-+-
 Reporter:  ptone|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:
 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
-+-

Comment (by ptone):

 I've expanded the scope of this ticket to not only cover the case of an
 existing directory of the specified name, but to allow a second argument
 to specify a different existing directory, or the current working
 directory

-- 
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] #17042: allow startproject, startapp to write into existing directory or a specified directory (was: allow startproject, startapp to write into existing directory)

[Django]

#17042: allow startproject, startapp to write into existing directory or a
specified directory
-+-
 Reporter:  ptone|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:
 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
-+-

-- 
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] #15372: manage.py adds to sys.path and forcibly imports the parent dir of the settings module

[Django]

#15372: manage.py adds to sys.path and forcibly imports the parent dir of the
settings module
-+-
 Reporter:  Jorge Vargas |Owner:  russellm
 |   Status:  closed
 Type:  Bug  |  Version:  SVN
Component:  Core (Other) |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 In [16964]:
 {{{
 #!CommitTicketReference repository="" revision="16964"
 Fixed #15372 -- Switched to a startproject default layout that allows us
 to avoid sys.path hacks.
 }}}

-- 
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] #17043: Model subclass field named the same as one of the parent model subclasses clashes

[Django]

#17043: Model subclass field named the same as one of the parent model 
subclasses
clashes
--+
 Reporter:  charettes |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The following model inheritance should raise a warning on model
 validation:
 {{{
 #!python
 from django.db import models

 class A(models.Model):
 pass

 class B(A):
 pass

 class C(A):
 b = models.BooleanField()

 print A.b
 #
 print B.b
 #
 print C.b
 #

 C.objects.create(b=False)
 #ValueError: Cannot assign "False": "C.b" must be a "B" instance.
 }}}

 Took me some time before figuring out what was happening. Feel free to
 rename the ticket with a more descriptive title.

 Is there a reason why the {{{RelatedObjectDescriptor}}} is also added to
 the subclasses of {{{A}}} and not only the parent model? Lets say I have a
 {{{c = C}}} instance, theres no way {{{c.b}}} might return something, only
 {{{a = A}}} might do?

-- 
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] #5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")

[Django]

#5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")
-+
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  sprintdec01  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by net147):

 * cc: net147 (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] #6933: You cannot search with spaces if search_fields is declared with "^"

[Django]

#6933: You cannot search with spaces if search_fields is declared with "^"
-+-
 Reporter:  Martín Conte Mac |Owner:  diafour
  Donell  |   Status:  new
 Type:  New feature  |  Version:  newforms-
Component:  contrib.admin|  admin
 Severity:  Normal   |   Resolution:
 Keywords:  nfa-someday yandex-  | Triage Stage:  Accepted
  sprint ep2008  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kmtracey):

 * needs_docs:  0 => 1
 * ui_ux:   => 0
 * type:  Bug => New feature
 * easy:   => 0


Comment:

 #17039 reported this again. Also given the current behavior is documented
 
(https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.search_fields)
 I'd call this ticket a new feature, not a bug. Also, I don't see that the
 doc mentioning the inability to search exactly on phrases with spaces is
 changed by the newest patch here so I think there is some doc change
 needed in addition to what is added by 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] #17039: search_fields and multiword searches

[Django]

#17039: search_fields and multiword searches
---+--
 Reporter:  shelldweller   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by kmtracey):

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


Comment:

 I think this is #6933.

-- 
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] #10899: easier manipulation of sessions by test client

[Django]

#10899: easier manipulation of sessions by test client
---+
 Reporter:  tallfred   |Owner:  nobody
 Type:  New feature|   Status:  reopened
Component:  Testing framework  |  Version:  SVN
 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 ptone):

 * needs_better_patch:  0 => 1


Comment:

 Tests failing:

 {{{

 FAIL: test_group_permission_performance
 (regressiontests.admin_views.tests.GroupAdminTest)
 --
 Traceback (most recent call last):
   File "/Users/admin/Projects/django/django-
 git/tests/regressiontests/admin_views/tests.py", line 2983, in
 test_group_permission_performance
 self.assertEqual(response.status_code, 200)
   File "/Users/admin/Projects/django/django-git/django/test/testcases.py",
 line 246, in __exit__
 executed, self.num
 AssertionError: 8 != 6 : 8 queries executed, 6 expected

 ==
 FAIL: test_user_permission_performance
 (regressiontests.admin_views.tests.UserAdminTest)
 --
 Traceback (most recent call last):
   File "/Users/admin/Projects/django/django-
 git/tests/regressiontests/admin_views/tests.py", line 2952, in
 test_user_permission_performance
 self.assertEqual(response.status_code, 200)
   File "/Users/admin/Projects/django/django-git/django/test/testcases.py",
 line 246, in __exit__
 executed, self.num
 AssertionError: 9 != 7 : 9 queries executed, 7 expected

 --
 Ran 4228 tests in 340.354s

 FAILED (failures=2, skipped=69, expected failures=3)
 }}}

-- 
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] #16642: TemplateView get_context_data returns params dict

[Django]

#16642: TemplateView get_context_data returns params dict
-+-
 Reporter:  martinogden  |Owner:
 Type:  Bug  |  martinogden
Component:  Generic views|   Status:  closed
 Severity:  Normal   |  Version:  1.3
 Keywords:  class-based generic  |   Resolution:  invalid
  view, TemplateView | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by russellm):

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


Comment:

 The params dictionary isn't redundant at all -- it's a namespace. The
 parameters passed in to the view aren't the only context variables that
 the template can render. Consider the case where the arguments passed in
 part of the URL pattern overlap with context variables created by the
 view.

-- 
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] #10725: Autoreloader hides signal exits from child

[Django]

#10725: Autoreloader hides signal exits from child
-+-
 Reporter:  Glenn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ptone):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Accepted => Ready for checkin


Comment:

 not really testable, but should provide more information to user who hits
 this edgecase

-- 
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] #16918: BaseDateDetailView's get_object ignores queryset argument

[Django]

#16918: BaseDateDetailView's get_object ignores queryset argument
-+-
 Reporter:  mitar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  1.3
 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
-+-

Comment (by ptone):

 bah - FWIW - I was the one who RFC - patch applied cleanly, and all tests
 pass, patch fixes impl to match docs - and has good coverage with 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] #16918: BaseDateDetailView's get_object ignores queryset argument

[Django]

#16918: BaseDateDetailView's get_object ignores queryset argument
-+-
 Reporter:  mitar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  1.3
 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 anonymous):

 * stage:  Accepted => Ready for checkin


-- 
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] #15619: Logout link should be protected

[Django]

#15619: Logout link should be protected
---+--
 Reporter:  void   |Owner:  ashchristopher
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  SVN
 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 anonymous):

 * needs_better_patch:  0 => 1


Comment:

 setting patch needs improvement per comment 18

-- 
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:  reopened
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 ptone):

 seems that this would be more suited as a contribution to django-
 extensions

-- 
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] #17042: allow startproject, startapp to write into existing directory

[Django]

#17042: allow startproject, startapp to write into existing directory
-+-
 Reporter:  ptone|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:
 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 ptone):

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


Comment:

 This relies someone on the files "manage.py" and "models.py" being
 "special markers" - but they are as good as any.  manage.py may one day go
 away, in which case settings could be checked.

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

-- 
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] #17042: allow startproject, startapp to write into existing directory

[Django]

#17042: allow startproject, startapp to write into existing directory
+
 Reporter:  ptone   |  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
+
 There might be various times you would want to "convert" an existing
 directory into a django project/app

 such might be the case for when you want to put a project under normal SVN
 flow of svnadmin create

 but there could be a number of circumstances - especially once #15372 is
 fixed where you want to turn an existing dir into a project container.

-- 
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] #13321: Drop reference to 'quality time' in admin logout message

[Django]

#13321: Drop reference to 'quality time' in admin logout message
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  logged out message   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Per the contributing guide (and ignoring the inappropriate expletive) you
 shouldn't reopen bugs closed as "wontfix" by core developers. As stated by
 Russell, if you disagree, you should start a discussion on the django-
 developers mailing list. Thanks!

-- 
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] #13321: Drop reference to 'quality time' in admin logout message

[Django]

#13321: Drop reference to 'quality time' in admin logout message
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  reopened
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  logged out message   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by anonymous):

 * status:  closed => reopened
 * severity:   => Normal
 * type:   => Uncategorized
 * easy:   => 0
 * ui_ux:   => 0
 * resolution:  wontfix =>


Comment:

 It's quite irritating ... if it were actually funny rather than
 condescending it might be a different story.

 Developer here is an asshole.  Not the first I've encountered here
 unfortunately, shitting on important bugs and others like this (that
 aren't), but serve to reinforce an environment hostile to suggestion.

-- 
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] r16963 - in django/trunk: django/contrib/auth/management django/contrib/contenttypes docs/ref/contrib

[noreply]

Author: Alex
Date: 2011-10-12 13:51:59 -0700 (Wed, 12 Oct 2011)
New Revision: 16963

Modified:
   django/trunk/django/contrib/auth/management/__init__.py
   django/trunk/django/contrib/contenttypes/models.py
   django/trunk/django/contrib/contenttypes/tests.py
   django/trunk/docs/ref/contrib/contenttypes.txt
Log:
Introduce `ContentType.objects.get_for_models(*models)` and use it in the the 
auth permissions code.  This is a solid performance gain on the test suite.  
Thanks to ptone for the profiling to find this hotspot, and carl for the review.

Modified: django/trunk/django/contrib/auth/management/__init__.py
===
--- django/trunk/django/contrib/auth/management/__init__.py 2011-10-12 
19:34:34 UTC (rev 16962)
+++ django/trunk/django/contrib/auth/management/__init__.py 2011-10-12 
20:51:59 UTC (rev 16963)
@@ -31,8 +31,8 @@
 searched_perms = list()
 # The codenames and ctypes that should exist.
 ctypes = set()
-for klass in app_models:
-ctype = ContentType.objects.get_for_model(klass)
+ctypes_for_models = ContentType.objects.get_for_models(*app_models)
+for klass, ctype in ctypes_for_models.iteritems():
 ctypes.add(ctype)
 for perm in _get_all_permissions(klass._meta):
 searched_perms.append((ctype, perm))

Modified: django/trunk/django/contrib/contenttypes/models.py
===
--- django/trunk/django/contrib/contenttypes/models.py  2011-10-12 19:34:34 UTC 
(rev 16962)
+++ django/trunk/django/contrib/contenttypes/models.py  2011-10-12 20:51:59 UTC 
(rev 16963)
@@ -15,19 +15,26 @@
 ct = self.get(app_label=app_label, model=model)
 return ct
 
+def _get_opts(self, model):
+opts = model._meta
+while opts.proxy:
+model = opts.proxy_for_model
+opts = model._meta
+return opts
+
+def _get_from_cache(self, opts):
+key = (opts.app_label, opts.object_name.lower())
+return self.__class__._cache[self.db][key]
+
 def get_for_model(self, model):
 """
 Returns the ContentType object for a given model, creating the
 ContentType if necessary. Lookups are cached so that subsequent lookups
 for the same model don't hit the database.
 """
-opts = model._meta
-while opts.proxy:
-model = opts.proxy_for_model
-opts = model._meta
-key = (opts.app_label, opts.object_name.lower())
+opts = self._get_opts(model)
 try:
-ct = self.__class__._cache[self.db][key]
+ct = self._get_from_cache(opts)
 except KeyError:
 # Load or create the ContentType entry. The smart_unicode() is
 # needed around opts.verbose_name_raw because name_raw might be a
@@ -41,6 +48,48 @@
 
 return ct
 
+def get_for_models(self, *models):
+"""
+Given *models, returns a dictionary mapping {model: content_type}.
+"""
+# Final results
+results = {}
+# models that aren't already in the cache
+needed_app_labels = set()
+needed_models = set()
+needed_opts = set()
+for model in models:
+opts = self._get_opts(model)
+try:
+ct = self._get_from_cache(opts)
+except KeyError:
+needed_app_labels.add(opts.app_label)
+needed_models.add(opts.object_name.lower())
+needed_opts.add(opts)
+else:
+results[model] = ct
+if needed_opts:
+cts = self.filter(
+app_label__in=needed_app_labels,
+model__in=needed_models
+)
+for ct in cts:
+model = ct.model_class()
+if model._meta in needed_opts:
+results[model] = ct
+needed_opts.remove(model._meta)
+self._add_to_cache(self.db, ct)
+for opts in needed_opts:
+# These weren't in the cache, or the DB, create them.
+ct = self.create(
+app_label=opts.app_label,
+model=opts.object_name.lower(),
+name=smart_unicode(opts.verbose_name_raw),
+)
+self._add_to_cache(self.db, ct)
+results[ct.model_class()] = ct
+return results
+
 def get_for_id(self, id):
 """
 Lookup a ContentType by ID. Uses the same shared cache as get_for_model

Modified: django/trunk/django/contrib/contenttypes/tests.py
===
--- django/trunk/django/contrib/contenttypes/tests.py   2011-10-12 19:34:34 UTC 
(rev 16962)
+++ django/trunk/django/contrib/contenttypes/tests.py   2011-10-12 20:51:59 UTC 
(rev 16963)
@@ -63,6 +63,36 @@
 with self.assertNumQueries(1):
  

[Django] #17041: Non-staff users should see clear message when trying to access admin

[Django]

#17041: Non-staff users should see clear message when trying to access admin
---+
 Reporter:  coolRR |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Currently, when a non-staff user tries to access the admin, they get sent
 to the login screen. (Unless there's some error in my system, that's what
 I observed.)

 This is confusing. They should get a message to the effect of: "You are
 not a staff member; the administration interface may be accessed by staff
 members only."

-- 
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] #17040: In utils.crypto.constant_time_compare only call ord on non ints.

[Django]

#17040: In utils.crypto.constant_time_compare only call ord on non ints.
+--
 Reporter:  adsworth|  Owner:  adsworth
 Type:  Bug | Status:  new
Component:  Python 3|Version:  1.3
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+--
 Iterating over a byte string in Python 3 will yield ints. Make sure that
 ord is only called on non ints.

-- 
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] #16942: utils.htp.int_to_base36 explicit cast to int

[Django]

#16942: utils.htp.int_to_base36 explicit cast to int
--+
 Reporter:  adsworth  |Owner:  adsworth
 Type:  Bug   |   Status:  new
Component:  Python 3  |  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 adsworth):

 Attached a new patch using integer division.

 Does this really need a separate test case?

-- 
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] r16962 - django/trunk/django/contrib/contenttypes

[noreply]

Author: Alex
Date: 2011-10-12 12:34:34 -0700 (Wed, 12 Oct 2011)
New Revision: 16962

Modified:
   django/trunk/django/contrib/contenttypes/tests.py
Log:
Convert the contettypes tests to use self.assertNumQueries, rather than hand 
rolling their own version. Thanks to carl for the review.

Modified: django/trunk/django/contrib/contenttypes/tests.py
===
--- django/trunk/django/contrib/contenttypes/tests.py   2011-10-11 22:21:14 UTC 
(rev 16961)
+++ django/trunk/django/contrib/contenttypes/tests.py   2011-10-12 19:34:34 UTC 
(rev 16962)
@@ -1,12 +1,13 @@
+from __future__ import with_statement
+
 import urllib
-from django import db
-from django.conf import settings
+
+from django.db import models
 from django.contrib.contenttypes.models import ContentType
-from django.contrib.sites.models import Site
 from django.contrib.contenttypes.views import shortcut
+from django.contrib.sites.models import Site
 from django.http import HttpRequest, Http404
 from django.test import TestCase
-from django.db import models
 from django.utils.encoding import smart_str
 
 
@@ -33,16 +34,10 @@
 class ContentTypesTests(TestCase):
 
 def setUp(self):
-# First, let's make sure we're dealing with a blank slate (and that
-# DEBUG is on so that queries get logged)
-self.old_DEBUG = settings.DEBUG
 self.old_Site_meta_installed = Site._meta.installed
-settings.DEBUG = True
 ContentType.objects.clear_cache()
-db.reset_queries()
 
 def tearDown(self):
-settings.DEBUG = self.old_DEBUG
 Site._meta.installed = self.old_Site_meta_installed
 ContentType.objects.clear_cache()
 
@@ -54,19 +49,19 @@
 """
 
 # At this point, a lookup for a ContentType should hit the DB
-ContentType.objects.get_for_model(ContentType)
-self.assertEqual(1, len(db.connection.queries))
+with self.assertNumQueries(1):
+ContentType.objects.get_for_model(ContentType)
 
 # A second hit, though, won't hit the DB, nor will a lookup by ID
-ct = ContentType.objects.get_for_model(ContentType)
-self.assertEqual(1, len(db.connection.queries))
-ContentType.objects.get_for_id(ct.id)
-self.assertEqual(1, len(db.connection.queries))
+with self.assertNumQueries(0):
+ct = ContentType.objects.get_for_model(ContentType)
+with self.assertNumQueries(0):
+ContentType.objects.get_for_id(ct.id)
 
 # Once we clear the cache, another lookup will again hit the DB
 ContentType.objects.clear_cache()
-ContentType.objects.get_for_model(ContentType)
-self.assertEqual(2, len(db.connection.queries))
+with self.assertNumQueries(1):
+ContentType.objects.get_for_model(ContentType)
 
 def test_shortcut_view(self):
 """

-- 
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] #17039: search_fields and multiword searches

[Django]

#17039: search_fields and multiword searches
---+--
 Reporter:  shelldweller   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by shelldweller):

 * cc: shelldweller (added)
 * needs_better_patch:   => 0
 * 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] #17039: search_fields and multiword searches

[Django]

#17039: search_fields and multiword searches
---+
 Reporter:  shelldweller   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 Django admin automatically splits query string for search_fields and
 creates a chained series of filters. For example if ModelAdmin instance
 contains

 {{{
 search_fields = ('my_field',)
 }}}

 and the user searches for "cool search", the resulting queryset will look
 like this:

 {{{
 qs.filter(my_field__icontains="cool").filter(my_field__icontains="search")
 }}}

 translating into SQL

 {{{
  ... WHERE my_field LIKE '%cool%' AND my_field LIKE '%search%'
 }}}

 So far so good. Now if we have anchored or exact search instead:

 {{{
 search_fields = ('^my_field',)
 }}}

 Django admin will do exactly the same thing as above and will result in a
 query like this:

 {{{
  ... WHERE my_field LIKE 'cool%' AND my_field LIKE 'search%'
 }}}

 which is not ever going to find anything because the same field cannot
 possibly start with two different strings.

 For this reason I am proposing to inspect lookup first and don't split
 query string if exact or anchored lookup is requested. So we would have
 instead:

 {{{
  ... WHERE my_field LIKE 'cool search%'
 }}}

 The code that need to change is between these two lines:
 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/views/main.py#L362
 and
 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/views/main.py#L365

-- 
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:  reopened
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|
-+-
Changes (by msabramo):

 * needs_better_patch:  1 => 0


Comment:

 See new patch
 
[https://code.djangoproject.com/attachment/ticket/17037/django_manage_py_diffsettings_all.diff
 django_manage_py_diffsettings_all.diff].

 Some samples of use:

 {{{
 $ django diffsettings --all | grep '===' | head
 ABSOLUTE_URL_OVERRIDES = {}  ===
 ADMIN_FOR = ()  ===
 ALLOWED_INCLUDE_ROOTS = ()  ===
 APPEND_SLASH = True  ===
 AUTHENTICATION_BACKENDS = ('django.contrib.auth.backends.ModelBackend',)
 ===
 CACHES = {'default': {'LOCATION': '', 'BACKEND':
 'django.core.cache.backends.locmem.LocMemCache'}}  ===
 CACHE_MIDDLEWARE_ALIAS = 'default'  ===
 CACHE_MIDDLEWARE_KEY_PREFIX = ''  ===
 CACHE_MIDDLEWARE_SECONDS = 600  ===
 COMMENTS_ALLOW_PROFANITIES = False  ===
 }}}

 {{{
 $ django diffsettings --help | grep --after=2 -- '--all'
   --all Display all settings; not just ones that differ
 from
 Django defaults. Settings that equal the defaults
 are
 followed by "===".
 }}}

-- 
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:  reopened
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  printsettings|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 We could add an option to "diffsettings" to show the settings that are set
 to their default value too. They would be highlighted with a special
 marker, for instance `===`.

 I don't expect this option to be widely used — Django has a huge number of
 settings and in most cases the default is OK — but it can't hurt.

 I think we should keep the name "diffsettings". The backwards
 compatibility issues outweigh the semantic improvement of changing it to
 "settings".

-- 
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:  reopened
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  printsettings|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by msabramo):

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


Comment:

 Sorry to reopen.

 I didn't know about diffsettings. Thanks for pointing it out. Looks like
 it prints the settings that differ from Django core's default settings.

 What my command does is slightly different. It prints out all the settings
 regardless of whether they are the same or different as the Django
 default.

 So printsettings is simpler than diffsettings. I suppose both functions
 could be done by a single command (settings?) in order to minimize the #
 of commands, but I'll leave that question open. If folks want that, I can
 rework 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] #17038: Use of _default_manager instead of _base_manager in ForeignKey ModelForm field validation

[Django]

#17038: Use of _default_manager instead of _base_manager  in ForeignKey 
ModelForm
field validation
-+-
 Reporter:  ben@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  manager form |  Unreviewed
  validation ForeignKey  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by anonymous):

 * component:  Forms => Database layer (models, ORM)


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

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

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

[Django]

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

 * cc: npeihl (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] #17038: Use of _default_manager instead of _base_manager in ForeignKey ModelForm field validation (was: Use of _default_manager instead of _base_manager in ForeignKey form field validatio

[Django]

#17038: Use of _default_manager instead of _base_manager  in ForeignKey 
ModelForm
field validation
-+-
 Reporter:  ben@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  manager form | Triage Stage:
  validation ForeignKey  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by anonymous):

 * needs_better_patch:   => 0
 * 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.

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:  closed
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  printsettings| Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by msabramo):

 * cc: msabramo (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.

[Django] #17038: Use of _default_manager instead of _base_manager in ForeignKey form field validation

[Django]

#17038: Use of _default_manager instead of _base_manager  in ForeignKey form 
field
validation
--+
 Reporter:  ben@… |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Forms |Version:  1.3
 Severity:  Normal|   Keywords:  manager form validation ForeignKey
 Triage Stage:|  Has patch:  0
  Unreviewed  |  UI/UX:  0
Easy pickings:  1 |
--+
 I'm not absolutely convinced this is a bug, but it is causing me grief and
 appears to be a bug when considered against
 [https://docs.djangoproject.com/en/dev/topics/db/managers/#controlling-
 automatic-manager-types Django's documented methodology with respect to
 "plain" manager usage vs. default manager usage].

 The bug I am referring to is located in:

 django/db/models/fields/related.py , line 850
 (version 1.3.1)

 This is in the "validate" method of ForeignKey.  Specifically, the
 problematic code is:

qs = self.rel.to.'''_default_manager'''.using(using).filter(
 *''*''{self.rel.field_name: value}
  )
qs = qs.complex_filter(self.rel.limit_choices_to)
if not qs.exists():
raise exceptions.ValidationError(self.error_messages['invalid'] % {
 'model': self.rel.to._meta.verbose_name, 'pk': value})

 To me, this should be using  _base_manager instead of _default_manager in
 order to be consistent with Django's stated  plain vs. default "automatic
 manager" paradigm for foreign key lookups.

 The specific problem I am running into is that my default manager's
 get_queryset method filters out a significant number of records (archived
 records), but I also have a secondary manager which includes them.  In my
 form, I have an option to load a ModelChoiceField using the queryset from
 the secondary manager, including the archived records.  However,
 validation for my form fails if a archived record is selected, since the
 above code looks to the default manager (which excludes all archived
 records) for validation instead of a "plain" manager.

 I am looking at creating a custom field in order to override the validate
 method as a work around, but this seemed like a potential bug to me.

 This is my first bug report, so let me know if other information will be
 useful.

 Ben

-- 
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] #4136: NULL fields and Unique keys

[Django]

#4136: NULL fields and Unique keys
-+-
 Reporter:  David Cramer |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  1.3-rc1
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by federico.capoano@…):

 How am I supposed to do in a case like:

 {{{
 ipv4_address = models.IPAddressField(verbose_name=_('ipv4 address'),
 blank=True, null=True, unique=True, default=None)
 ipv6_address = models.GenericIPAddressField(protocol='IPv6',
 verbose_name=_('ipv6 address'), blank=True, null=True, unique=True,
 default=None)
 }}}

 No idea on how to solve this.

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

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

Re: [Django] #16642: TemplateView get_context_data returns params dict

[Django]

#16642: TemplateView get_context_data returns params dict
-+-
 Reporter:  martinogden  |Owner:
 Type:  Bug  |  martinogden
Component:  Generic views|   Status:  reopened
 Severity:  Normal   |  Version:  1.3
 Keywords:  class-based generic  |   Resolution:
  view, TemplateView | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by simon@…):

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


Comment:

 This behaviour seems rather undesirable. The TemplateView is meant to be
 the quickest and easiest way of rendering a template. Why does it
 encapsulate the kwargs inside a redundant single-element dictionary?
 Having to change the templates to include params feels totally wrong.

 Is there an alternative class-based view that doesn't require the use of
 'params'?

-- 
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] #14319: Add signals test_setup and test_teardown to Django test suite runner Options

[Django]

#14319: Add signals test_setup and test_teardown to Django test suite runner
Options
---+
 Reporter:  jsdalton   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  SVN
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  signals| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by jsdalton):

 What you're saying sounds reasonable but it's hard for me to really
 understand the context in which this decision has been made. Is there a
 ticket or discussion that relates to this idea of moving the Django test
 suite toward a "plugin" approach? I googled plugins for unittest2 but I
 couldn't really find anything about it either.

 I'd be happy to assist in any efforts that are being made to move the
 testing suite in Django in the direction you are suggesting, but I'm
 concerned that we're killing a useful improvement for the sake of future
 ambitions that might never materialize.

-- 
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] #4136: NULL fields and Unique keys

[Django]

#4136: NULL fields and Unique keys
-+-
 Reporter:  David Cramer |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  1.3-rc1
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by federico.capoano@…):

 * version:  0.96 => 1.3-rc1


-- 
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] #16965: Model Formsets can_delete documentation lacking actual use example

[Django]

#16965: Model Formsets can_delete documentation lacking actual use example
-+-
 Reporter:  gregcorey@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  can_delete,  | Triage Stage:
  documentation, model formset   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by geraldcor):

 * keywords:  can_delete, documentation, formsets => can_delete,
 documentation, model formset


-- 
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:  closed
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  printsettings| Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 It seems to me that this already exists:
 [https://docs.djangoproject.com/en/dev/ref/django-admin/#diffsettings
 manage.py diffsettings].

 Did I miss something in your proposal?

-- 
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] #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 commands)  |Version:  1.3
 Severity:  Normal  |   Keywords:  printsettings
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+---
 A large number of problems that we have with our Django project at work
 turn out to be because of settings that are not what they should be (note
 that our settings are not straightforward to see with a glance at
 settings.py since we use multiple settings files for production, dev, and
 common settings). I thought that it might be useful to have a Django
 management command that shows the settings in effect after all the
 settings files are processed.

 It was super easy to write and is a tiny amount of code, but I have a
 feeling that this will quickly curtail a lot of problems.

-- 
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] #10293: Show Unicode representations next to ManyToMany raw_id_field

[Django]

#10293: Show Unicode representations next to ManyToMany raw_id_field
-+-
 Reporter:  joaoolavo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  raw_id_field,| Triage Stage:  Design
  manytomanyfield,   |  decision needed
  manytomanyrawidwidget, unicode |  Needs documentation:  0
  representation |  Patch needs improvement:  0
Has patch:  0|UI/UX:  1
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Stanislas ):

 * cc: stan@… (added)


Comment:

 I have merged this patch in #7028.

-- 
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] #7028: Better raw_id_fields feedback in newform-admins branch

[Django]

#7028: Better raw_id_fields feedback in newform-admins branch
-+-
 Reporter:  Marcob   |Owner:  nobody
|   Status:  new
 Type:  New feature  |  Version:  SVN
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  raw-id-fields nfa-   |  Needs documentation:  0
  someday design_ux  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  1
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by Stanislas ):

 ManyToMany raw_id_field: Maybe we could add a "Clear" button for each
 labeled object in order to javascriptly remove its Id in the input ?

-- 
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] #16763: code.djangoproject.com won't stop emailing me (doesn't abide by cc/reporter/etc)

[Django]

#16763: code.djangoproject.com won't stop emailing me (doesn't abide by
cc/reporter/etc)
-+-
 Reporter:  ferringb |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by RaceCondition):

 Why am I getting updates about this issue even though now I'm not even in
 the CC list??

-- 
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] #11030: File uploads break on non english filesystem encoding

[Django]

#11030: File uploads break on non english filesystem encoding
-+-
 Reporter:  Honza_Kral   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  File |  Version:  1.2
  uploads/storage|   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  file path encoding   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mailing List SVR ):

 * cc: lists@… (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] #9538: modelformset_factory cannot easily be used for only inserting

[Django]

#9538: modelformset_factory cannot easily be used for only inserting
-+
 Reporter:  cgrady   |Owner:  brosner
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  modelform| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

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


Comment:

 This is a CSRF verification problem, and it doesn't look related to the
 problem originally described by this ticket.

 I suggest reviewing the CSRF docs, and if you can't figure out what's
 going wrong, asking for help on the #django IRC channel or the django-
 users mailing list.

-- 
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] #9538: modelformset_factory cannot easily be used for only inserting

[Django]

#9538: modelformset_factory cannot easily be used for only inserting
-+
 Reporter:  cgrady   |Owner:  brosner
 Type:  New feature  |   Status:  reopened
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  modelform| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by drgubuntu@…):

 * status:  closed => reopened
 * keywords:   => modelform
 * version:  1.0 => 1.3
 * resolution:  fixed =>


Comment:

 Ive got error in this sample program CSRF verification failed. Request
 aborted.

 from myform.xforms.models import Author
 from django.forms.models import modelformset_factory
 from django.shortcuts import render_to_response,
 get_object_or_404,HttpResponse


 def index(request):
 AuthorFormSet = modelformset_factory(Author)

 if request.method == 'POST':
 formset = AuthorFormSet(request.POST,request.FILES)
 if formset.is_valid():
 formset.save()
 else:
 formset = AuthorFormSet()
 return render_to_response("authors.html",{"formset":formset,})

 # Create your views 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] #16679: Speed up signals by caching the reveicers per sender

[Django]

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Suor):

 Are there any real world scenario for using numerous thrown out dynamic
 classes? And while they are thrown out they still live long enough to use
 signals. Probably the right approach here will be just ignore this case.

 About inherited signals. I agree that they could simplify some code
 (making it more implicit by the way). It will also make signals
 implementation slower and more complex. It seems that somebody should
 start another ticket or topic on django-developers to resolve this
 question. Who knows? Maybe a lot of people want this?

 About implementation. It appears to me that my approach is cleaner when
 sender inheritance is not involved, otherwise one should just go with
 caching. So this solution should be delayed until we get any decision on
 previous question.

-- 
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] #16679: Speed up signals by caching the reveicers per sender

[Django]

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 The senders_no_receivers cache is there to make the sending marginally
 faster. But I think if you did on the last line this:

 {{{
 return receivers and deref(receivers) or []
 }}}
 I would be actually as fast as the senders_no_receivers cache version, as
 you would get rid of that function call. Other than that your code does
 look much better.

 The problem with not having .use_caching property is that if somebody
 decides to use dynamic classes with the signaling system, you will get
 really bad memory leak - every dynamic class will be stored in the cache.
 This is not a problem with model classes, because you will leak the
 classes anyways in app models cache.

 So, what do you think, which way should we go here, caching, your version
 or both?

 The `Haystack` use case is following:
 {{{
 class NoteIndex(RealtimeSearchIndex):
 # Index definition
 site.register(Note, NoteIndex)
 }}}

 Because you use RealtimeSearchIndex, haystack will connect to the signals,
 and do automatic updates of the index in the signals. Now, if you have
 SpecialNote(Note) class, and you save a SpecialNote, you will NOT get the
 index updated, even if you saved a note. Even a ProxyNote(Note) would
 break your indexing. There are surely other use cases like that. For
 example you could have an extension "django-audits", where you register an
 audit_trail for a model, and it will automatically do auditing for you.
 Now, if you use subclassing (even proxy classes), suddenly your auditing
 is not there. See the problem?

 Although there are other problems for signals, too: they are not sent when
 you do qs.update, nor are they sent when you do bulk_create. I have some
 ideas of how there could be fixed, although that would mean first fetching
 the to-be-updated resultset in qs.update() and then doing the update in
 one query. So it would mean that if you update a gazillion rows in one go,
 you would get a LOT worse performance... But having data modification
 signals that are only sometimes sent will lead to problems for users who
 think they can audit their data by just signals. Ah well, getting out of
 this ticket's topic again... :)

-- 
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] #7028: Better raw_id_fields feedback in newform-admins branch

[Django]

#7028: Better raw_id_fields feedback in newform-admins branch
-+-
 Reporter:  Marcob   |Owner:  nobody
|   Status:  new
 Type:  New feature  |  Version:  SVN
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  raw-id-fields nfa-   |  Needs documentation:  0
  someday design_ux  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  1
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by Stanislas ):

 * cc: stan@… (added)


Comment:

 Replying to [comment:64 julien]:
 > This looks really good! However, it really needs to support
 `ManyToManyFields` before it can be included in core. A list builder
 widget, as specified in `[1]`, could be a nice solution.
 >
 > `[1]` http://wiki.jqueryui.com/w/page/12137993/ListBuilder


 That's nice indeed but for the sake of consistency the same interface
 should also be ported to the ForeignKey's raw_id. This mean to completely
 rethink this patch.

 And what about the non-javascript users ?

 Merging #10293 looks more reasonable and simpler to me.

 But I like the idea of an auto-completion (and so my users) !

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

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

Re: [Django] #11211: Add GMarkerOptions: clickable, bouncy, dragCrossMove, bounceGravity, autoPan and hide

[Django]

#11211: Add GMarkerOptions: clickable, bouncy, dragCrossMove, bounceGravity,
autoPan and hide
-+-
 Reporter:  Travis Jeffery   |Owner:  nobody
 |   Status:  new
 Type:  New feature  |  Version:  SVN
Component:  GIS  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  google, maps,|  decision needed
  gmarker, options   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

 * 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] #16679: Speed up signals by caching the reveicers per sender

[Django]

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Suor):

 As I understand haystack it creates SearchIndex for each model and that
 search index connects signals to that index and signal receiver depends on
 that search index, so no use for inherited signals here too. Or maybe I
 just don't see a big simplifying refactoring here which involves inherited
 signals?

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