Re: [Django] #16933: Make it more obvious on screen which version of the doc is being viewed

[Django]

#16933: Make it more obvious on screen which version of the doc is being viewed
-+-
 Reporter:  julien   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Djangoproject.com|   Resolution:  fixed
  Web site   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  1
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by julien):

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


Comment:

 This is now fixed. Check out the little green box in the bottom right
 corner: https://docs.djangoproject.com

-- 
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] #10523: Changing object with long __repr__ causes error

[Django]

#10523: Changing object with long __repr__ causes error
---+
 Reporter:  bromer |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  contrib.admin  |  Version:  1.2-beta
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by julien):

 Like others in this thread, I can't seem to be able to reproduce this
 problem. The attached patch passes for me on Python with Sqlite. Perhaps
 this would need to be tested on other backends.

-- 
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] #13958: There is an error, when a source file with backslash-r returns is interpreted by the Python error report page.

[Django]

#13958: There is an error, when a source file with backslash-r returns is
interpreted by the Python error report page.
-+--
 Reporter:  petrvanblokland  |Owner:  nessita
 Type:  Bug  |   Status:  reopened
Component:  Uncategorized|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by anonymous):

 * type:  Uncategorized => Bug
 * easy:  0 => 1


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

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

Re: [Django] #15600: Add Limitations section in the auth documentation

[Django]

#15600: Add Limitations section in the auth documentation
---+
 Reporter:  rklists@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by rklists@…):

 Agreed - for every alternative pointed out it's also worth noting
 potential trade-offs

-- 
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] #15600: Add Limitations section in the auth documentation

[Django]

#15600: Add Limitations section in the auth documentation
---+
 Reporter:  rklists@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by PaulM):

 rklists: that functionality is tracked in #16860, which is important, but
 not directly related to straightforward throttling.

 ratelimitcache doesn't do anything the webserver itself can't do. More
 complicated things like account lockouts are going to require per-
 installation tuning, and represent a DoS vector that needs to be balanced.
 Throttling does discourage an attacker from trying the 500 most common
 passwords for your 8000 users in an afternoon. It's about incremental
 protection 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] #16860: Provide hooks for password policy

[Django]

#16860: Provide hooks for password policy
--+
 Reporter:  PaulM |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Description changed by PaulM:

Old description:

> While it is possible to change the validation for new passwords by
> subclassing the form, I think that Django should provide a more friendly
> interface for this. We should have a pluggable password authentication
> framework which enforces no rules by default, but comes with several
> reasonable example policies which may be enabled.
>
> Problems to be solved include:
>
>  * Informing the user of the various password requirements
>  * Allowing policies to chain together smoothly
>  * Provide flexibility for complex requirements (some may include their
> own models)
>  * Backwards compatibility
>  * Javascript validation assistance (someday, maybe?)
>  * HTML5 support (i.e. the pattern attribute)

New description:

 While it is possible to change the validation for new passwords by
 subclassing the form, I think that Django should provide a more friendly
 interface for this. We should have a pluggable password authentication
 framework which enforces no rules by default, but comes with several
 reasonable example policies which may be enabled.

 Problems to be solved include:

  * Informing the user of the various password requirements
  * Allowing policies to chain together smoothly
  * Provide flexibility for complex requirements (some may include their
 own models)
  * Backwards compatibility
  * Javascript validation assistance (someday, maybe?)
  * HTML5 support (i.e. the pattern attribute)
  * Support for various rate-limiting and lockout schemes
  * support for adding captchas (maybe)

--

-- 
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] #15600: Add Limitations section in the auth documentation

[Django]

#15600: Add Limitations section in the auth documentation
---+
 Reporter:  rklists@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by rklists@…):

 In your experience, does webserver throttling effectively prevent a brute
 force attack? For example, can an attacker still try a dictionary of the
 500 most frequently used passwords for a single user in 24 hours?

-- 
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] #15600: Add Limitations section in the auth documentation

[Django]

#15600: Add Limitations section in the auth documentation
---+
 Reporter:  rklists@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by PaulM):

 * ui_ux:   => 0


Comment:

 It's worth noting in this ticket that most webservers provide per-url
 configurable throttling. I'd like to see recommendations for configuring
 at least apache and nginx in the docs. It's pretty straightforward. You
 don't need a complicated WAF to get basic rate limiting.

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

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

Re: [Django] #25: Filtering interface on ForeignKey boxes

[Django]

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

Comment (by victorhooi):

 heya,

 Any update on how close this is to hitting trunk?

 I mean, it's flagged "Easy pickings" by Idan *grins*, so surely it's
 close, right? Are there any showstopppers?

 Cheers,
 Victor

 Btw, I also saw this:

 http://harvesthq.github.com/chosen/

 Chosen's a JQuery (or Prototype) plugin that basically similar combo-box
 support, but without the scrollable list underneath.

-- 
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] #16519: mimetype used with HttpResponse should be deprecated

[Django]

#16519: mimetype used with HttpResponse should be deprecated
-+-
 Reporter:  PaulM|Owner:
 Type:   |  yasar11732
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by yasar11732):

 Sorry about marking as RFC. I didn't know I didn't supposed to do that.

-- 
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] #16519: mimetype used with HttpResponse should be deprecated

[Django]

#16519: mimetype used with HttpResponse should be deprecated
-+-
 Reporter:  PaulM|Owner:
 Type:   |  yasar11732
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by yasar11732):

 * stage:  Ready for checkin => 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] #16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional warning.

[Django]

#16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional 
warning.
-+-
 Reporter:  cyclops  |Owner:
 Type:   |  yasar11732
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by yasar11732):

 Replying to [comment:6 aaugustin]:
 > Please don't mark your own patches as RFC — the rule is that patches
 must be reviewed by someone who isn't the author.

 Sorry, I didn't know. I am new to contributing to django.

 Replying to [comment:7 bpeschier]:
 > Thanks for your contribution; I do have a couple of remarks on the
 patch:

 Thanks for the remarks. I attached a new patch file.

-- 
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] #16960: Refactor d.u.translations.trans_real to support xmb files, clean up code

[Django]

#16960: Refactor d.u.translations.trans_real to support xmb files, clean up code
-+-
 Reporter:  arb@…|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  1.3
  Internationalization   |   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 jezdez):

 * component:  Uncategorized => Internationalization
 * stage:  Unreviewed => Design decision needed


Comment:

 While I appreciate the gesture, this is a rather big proposal and needs a
 bit more clarification than what you provided in the ticket description.
 As this is more than a refactor (but an actual feature addition) I'd like
 to encourage you to follow our contribution policy and send a detailed
 proposal to the django-developers list.

 Marking as design decision needed for now..

-- 
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] #16936: CSRF with AJAX documentation is out-of-date

[Django]

#16936: CSRF with AJAX documentation is out-of-date
---+--
 Reporter:  idangazit  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by lukeplant):

 Is there a reason the patch reverts [16183] and removes sameOrigin?

-- 
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] #16960: Refactor d.u.translations.trans_real to support xmb files, clean up code

[Django]

#16960: Refactor d.u.translations.trans_real to support xmb files, clean up code
---+--
 Reporter:  arb@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anonymous):

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


Comment:

 Just to clarify - I'm proposing to refactor the code to clean it up and
 make it so you can supply pluggable translation engines.

-- 
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] #16960: Refactor d.u.translations.trans_real to support xmb files, clean up code

[Django]

#16960: Refactor d.u.translations.trans_real to support xmb files, clean up code
---+
 Reporter:  arb@…  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Right now the .mo file support is baked in pretty deep to the translations
 stuff. It would be useful (to me, and I've seen other people out there
 talking as well) if it could support other formats, such as XMB/XTB format
 (http://cldr.unicode.org/development/development-process/design-
 proposals/xmb)

 In addition, looking at the code in trans_real.py it's a bit nasty, with
 nested functions all over the place. It could do with a bit of a
 cleanup/refactor.

 I'm most likely going to need to do this anyway, but if there's interest I
 can look at contributing the code back upstream.

-- 
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] #16519: mimetype used with HttpResponse should be deprecated

[Django]

#16519: mimetype used with HttpResponse should be deprecated
-+-
 Reporter:  PaulM|Owner:
 Type:   |  yasar11732
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  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:  1
 |UI/UX:  0
-+-
Changes (by yasar11732):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 I made a patch file where I made warning and changed mimetype kwarg, to
 content_type kwarg. However, I didn't write tests for it, as I am not sure
 what I am test for here, something like this maybe?


 {{{
 import warnings
 from django.http import HttpResponse

 with warnings.catch_warnings(record=True) as w:
 warnings.simplefilter("always")
 HttpResponse(mimetype="text/html")

 assert len(w) == 1
 assert issubclass(w[-1].category, DeprecationWarning)
 assert "deprecated" in str(w[-1].message)
 }}}

-- 
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] #16005: Missing and operator in blocktrans documentation

[Django]

#16005: Missing and operator in blocktrans documentation
-+-
 Reporter:  bezidejni|Owner:  bezidejni
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  blocktrans   | Triage Stage:  Ready for
Has patch:  0|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by DrMeers):

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


Comment:

 This has been fixed in #16072

-- 
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] #8060: Admin Inlines do not respect user permissions

[Django]

#8060: Admin Inlines do not respect user permissions
-+-
 Reporter:  p.patruno@…  |Owner:  sjaensch
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  inlines User | Triage Stage:  Accepted
  authentication |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by sjaensch):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
 Reporter:  Manfred Wassmann |Owner:  jgelens
   |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by jgelens):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #16715: Wrong JOIN with nested null-able foreign keys

[Django]

#16715: Wrong JOIN with nested null-able foreign keys
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join, values,|  Needs documentation:  0
  nested, foreign key, null-able |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by sebastian):

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


Comment:

 I attached another, more elaborate test, checking both explicit foreign
 key relations as well as implicit reverse ones (such as used by one-to-one
 relations, e.g. in multi-table inheritance).

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

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


Comment:

 After a discussion with Carl yesterday I'm marking this as wontfix.  This
 idea continues a fundamentally bad trend in Django: treating it as some
 sort of application runner, rather than a library.  To that end, our long
 running goal should be to kill our test harness, and recreate the database
 setup stuff as plugins for unittest2 (which means it's then runnable by
 other test framworks like nose or py.test), once we're firmly in that
 territory users will have the same things available to them: they can
 write unittest plugins to do their own test suite setup.

-- 
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:  new
Component:  Testing framework  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  signals| 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:

 OK, I see - there is an import that needs to be deleted, I think that
 might have been what was throwing me off.

 Also, even though the preceding item mentions it, I think it is redundant
 to say that this signal does not fire during normal operation in each test
 description, since that caveat is introduced in the test signals section.

 Another possible heads up that came from IRC, is that there is some
 discussion about abandoning the Django custom test harness in place of a
 standardized one based on nose or test.py, and so there is some concern
 about adding features to the current harness

-- 
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] #16851: Accessing a forms field value in a template

[Django]

#16851: Accessing a forms field value in a template
---+--
 Reporter:  from_a_far@…   |Owner:  yasar11732
 Type:  Uncategorized  |   Status:  assigned
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by bpeschier):

 * needs_better_patch:  0 => 1


Comment:

 Nice and simple addition to the docs, but I do not really agree with the
 remark about it not being "correct" and one "should" use the default
 filter: an empty string is not technically None either. Encountering None
 in templates is something more general and does not need to get mentioned
 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] #16779: Add a tutorial for first time Django contributors

[Django]

#16779: Add a tutorial for first time Django contributors
---+
 Reporter:  taavi223   |Owner:  taavi223
 Type:  New feature|   Status:  assigned
Component:  Documentation  |  Version:
 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 bpeschier):

 * needs_better_patch:  0 => 1


Comment:

 Oh wow, really nice work!

 One a [http://blip.tv/djangocon/keynote-glyph-lefkowitz-5573264 Glyph
 Lefkowitz-style note], but why not include the python-powered Mercurial?
 O:)

-- 
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] #16777: Contributing guide: github and bitbucket pull requests are acceptable

[Django]

#16777: Contributing guide: github and bitbucket pull requests are acceptable
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  justinlilly
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  SVN
 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 bpeschier):

 * needs_better_patch:  0 => 1


Comment:

 And while you are at it, give !GitHub and Bitbucket a few capital letters
 to reflect their brand names :-)

-- 
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] #16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional warning.

[Django]

#16758: Documentation for TEMPLATE_CONTEXT_PROCESSORS could use additional 
warning.
-+-
 Reporter:  cyclops  |Owner:
 Type:   |  yasar11732
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by bpeschier):

 * needs_better_patch:  0 => 1


Comment:

 Thanks for your contribution; I do have a couple of remarks on the patch:

  1. The suggested text focuses on what people should do instead of WHY
 they should do it, which feels to me to be belittling the reader a bit.
  2. It's not only beginners who should be cautious, everybody should.
  3. I believe Django is commonly referred to with a capital D.

 I would suggest to rewrite it to a more general style ("be careful with
 settings in settings.py, because ...") and focus on the fact settings.py
 overrides the default 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] #16957: Timezone changes on development server after first request

[Django]

#16957: Timezone changes on development server after first request
-+--
 Reporter:  antti.a.laine@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by romain):

 * cc: romain (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I can't reproduce this bug

 - Django 1.3.1
 - Python 2.6.5
 - Dev server running on Linux 2.6.32
 - System clock set to UTC+2 (Europe/Paris)

 tested with a minimal project (no models) and the submitted view code.

-- 
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] #16849: loaddata - --help text incorrect?

[Django]

#16849: loaddata - --help text incorrect?
---+
 Reporter:  EvilDMP|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Brook ):

 A verbosity level of 3 is used to output a couple of messages in the
 commands loaddata and syncdb.

-- 
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] #16936: CSRF with AJAX documentation is out-of-date

[Django]

#16936: CSRF with AJAX documentation is out-of-date
---+--
 Reporter:  idangazit  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by ptone):

 doh - a noisy note to say, FWIW, that the above two comments are from 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.

Re: [Django] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
 Reporter:  Manfred Wassmann |Owner:  jgelens
   |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by jgelens):

 Figured out how to fix that kind of cases. Expect a new patch in a couple
 of hours.

-- 
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] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
 Reporter:  Manfred Wassmann |Owner:  jgelens
   |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anonymous):

 Replying to [comment:47 konk]:
 > I've come up with another case where it fails; added it to the tests in
 the patch.
 >
 > Basically, the error lies in the assumption that all fields in the
 DISTINCT ON set belong to the base model of the QuerySet.

 That patch doesn't apply:

 {{{
 (django)ligfiets$ patch -p1 https://code.djangoproject.com/ticket/6422#comment:48>
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] #16936: CSRF with AJAX documentation is out-of-date

[Django]

#16936: CSRF with AJAX documentation is out-of-date
---+--
 Reporter:  idangazit  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 Also to highlight something I think PaulM saw and commented on in IRC,
 there is either a bug in the original/current snippet in the docs, or my
 logic is failing.

 This line was removed from the current docs in the patch:

 {{{
 126 if (!safeMethod(settings.type) &&
 sameOrigin(settings.url)) {
 }}}

 and this was added:

 {{{
 145 if (!(/^https?:.*/.test(settings.url)) &&
 safeMethod(settings.type) ) {
 }}}

 the logic of safeMethod is reversed - but as I read it, the patch is
 correct, you only want to send the cookie if the method was safe.  If that
 is not the case, that function should be renamed to be much clearer.

 Also not clear in the current patch, nor the original security release
 notes, is why relative URLs should be enforced.  A brief note explaining
 this in the docs would be beneficial.

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

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

Re: [Django] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
--+
 Reporter:  etianen   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by kmike):

 * cc: kmike84@… (added)


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

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

Re: [Django] #16936: CSRF with AJAX documentation is out-of-date

[Django]

#16936: CSRF with AJAX documentation is out-of-date
---+--
 Reporter:  idangazit  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 A minor comment on the docs part, you say:

 {{{

 100 If the CSRF token is not present in markup by use of the
 :ttag:`csrf_token`
 101 template tag, it must be supplied to the client by other
 means. This is common
 102 in cases where the form is dynamically added to the page,
 and Django supplies
 103 a decorator which will set a cookie containing the CSRF
 token:
 104 :func:`~django.views.decorators.csrf.ensure_csrf_cookie`.
 Use the decorator
 105 on any view which will need access to the CSRF token, but
 doesn't include the
 106 token in the actual markup sent to the client.
 }}}

 Small clarification, but I think of view as referring to python code
 specifically, not the more abstract combination of view and content it
 renders for display.

 So perhaps something like "If you need access to the CSRF on the client
 and it is not made available in the markup, use the CSRF decorator on the
 associated view to set the CSRF cookie"

 Specifying that the need is on the client side, instead of in the "view"
 which I think of as the Django side.

-- 
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] #16955: Querying on the reverse of a FK with the wrong class silently returns bad data

[Django]

#16955: Querying on the reverse of a FK with the wrong class silently returns 
bad
data
-+-
 Reporter:  jdunck   |Owner:  dgouldin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by dgouldin):

 The test which was removed is no longer a valid use case.  Passing the
 wrong model type to a queryset filter kwarg should raise a TypeError, even
 in the instance where the PKs happen to always be the same.  The proper
 way to perform such a test would be to use concrete model inheritance, in
 which case isinstance would return True and the check I've added would
 pass.

-- 
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] #16955: Querying on the reverse of a FK with the wrong class silently returns bad data

[Django]

#16955: Querying on the reverse of a FK with the wrong class silently returns 
bad
data
-+-
 Reporter:  jdunck   |Owner:  dgouldin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by dgouldin):

 * 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] #16955: Querying on the reverse of a FK with the wrong class silently returns bad data

[Django]

#16955: Querying on the reverse of a FK with the wrong class silently returns 
bad
data
-+-
 Reporter:  jdunck   |Owner:  dgouldin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (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 dgouldin):

 * owner:  nobody => dgouldin
 * cc: dgouldin (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.

[Changeset] r16914 - django/trunk/django/contrib/contenttypes

[noreply]

Author: lukeplant
Date: 2011-09-29 08:30:37 -0700 (Thu, 29 Sep 2011)
New Revision: 16914

Modified:
   django/trunk/django/contrib/contenttypes/generic.py
Log:
Made GenericRelatedObjectManager consistent with other related managers w.r.t. 
use of core_filters attribute.

Previously it had an unused keyword argument.

Modified: django/trunk/django/contrib/contenttypes/generic.py
===
--- django/trunk/django/contrib/contenttypes/generic.py 2011-09-29 15:30:29 UTC 
(rev 16913)
+++ django/trunk/django/contrib/contenttypes/generic.py 2011-09-29 15:30:37 UTC 
(rev 16914)
@@ -214,6 +214,7 @@
 RelatedManager = create_generic_related_manager(superclass)
 
 qn = connection.ops.quote_name
+content_type = 
ContentType.objects.db_manager(instance._state.db).get_for_model(instance)
 
 manager = RelatedManager(
 model = rel_model,
@@ -221,9 +222,14 @@
 symmetrical = (self.field.rel.symmetrical and instance.__class__ 
== rel_model),
 source_col_name = qn(self.field.m2m_column_name()),
 target_col_name = qn(self.field.m2m_reverse_name()),
-content_type = 
ContentType.objects.db_manager(instance._state.db).get_for_model(instance),
+content_type = content_type,
 content_type_field_name = self.field.content_type_field_name,
-object_id_field_name = self.field.object_id_field_name
+object_id_field_name = self.field.object_id_field_name,
+core_filters = {
+'%s__pk' % self.field.content_type_field_name: content_type.id,
+'%s__exact' % self.field.object_id_field_name: 
instance._get_pk_val(),
+}
+
 )
 
 return manager
@@ -249,7 +255,7 @@
  content_type_field_name=None, object_id_field_name=None):
 
 super(GenericRelatedObjectManager, self).__init__()
-self.core_filters = core_filters or {}
+self.core_filters = core_filters
 self.model = model
 self.content_type = content_type
 self.symmetrical = symmetrical
@@ -262,11 +268,7 @@
 
 def get_query_set(self):
 db = self._db or router.db_for_read(self.model, 
instance=self.instance)
-query = {
-'%s__pk' % self.content_type_field_name : self.content_type.id,
-'%s__exact' % self.object_id_field_name : self.pk_val,
-}
-return super(GenericRelatedObjectManager, 
self).get_query_set().using(db).filter(**query)
+return super(GenericRelatedObjectManager, 
self).get_query_set().using(db).filter(**self.core_filters)
 
 def add(self, *objs):
 for obj in objs:

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16913 - in django/trunk/django: contrib/contenttypes db/models/fields

[noreply]

Author: lukeplant
Date: 2011-09-29 08:30:29 -0700 (Thu, 29 Sep 2011)
New Revision: 16913

Modified:
   django/trunk/django/contrib/contenttypes/generic.py
   django/trunk/django/db/models/fields/related.py
Log:
Cleanups to related manager code, especially in use of closures.

The related manager classes are defined within functions, and the methods
had inconsistent and confusing usage of closures vs. parameters on self to
retrieve needed information. Everything is stored on self now.

Also some methods were not using super() where they should have been.

Modified: django/trunk/django/contrib/contenttypes/generic.py
===
--- django/trunk/django/contrib/contenttypes/generic.py 2011-09-29 15:30:19 UTC 
(rev 16912)
+++ django/trunk/django/contrib/contenttypes/generic.py 2011-09-29 15:30:29 UTC 
(rev 16913)
@@ -266,7 +266,7 @@
 '%s__pk' % self.content_type_field_name : self.content_type.id,
 '%s__exact' % self.object_id_field_name : self.pk_val,
 }
-return superclass.get_query_set(self).using(db).filter(**query)
+return super(GenericRelatedObjectManager, 
self).get_query_set().using(db).filter(**query)
 
 def add(self, *objs):
 for obj in objs:

Modified: django/trunk/django/db/models/fields/related.py
===
--- django/trunk/django/db/models/fields/related.py 2011-09-29 15:30:19 UTC 
(rev 16912)
+++ django/trunk/django/db/models/fields/related.py 2011-09-29 15:30:29 UTC 
(rev 16913)
@@ -414,88 +414,90 @@
 Creates the managers used by other methods (__get__() and delete()).
 """
 rel_field = self.related.field
-rel_model = self.related.model
-
 class RelatedManager(superclass):
-def __init__(self, model=None, core_filters=None, instance=None):
+def __init__(self, model=None, core_filters=None, instance=None,
+ rel_field=None):
 super(RelatedManager, self).__init__()
 self.model = model
 self.core_filters = core_filters
 self.instance = instance
+self.rel_field = rel_field
 
 def get_query_set(self):
-db = self._db or router.db_for_read(rel_model, 
instance=self.instance)
-return 
superclass.get_query_set(self).using(db).filter(**(self.core_filters))
+db = self._db or router.db_for_read(self.model, 
instance=self.instance)
+return super(RelatedManager, 
self).get_query_set().using(db).filter(**(self.core_filters))
 
 def add(self, *objs):
 for obj in objs:
 if not isinstance(obj, self.model):
 raise TypeError("'%s' instance expected" % 
self.model._meta.object_name)
-setattr(obj, rel_field.name, self.instance)
+setattr(obj, self.rel_field.name, self.instance)
 obj.save()
 add.alters_data = True
 
 def create(self, **kwargs):
-kwargs[rel_field.name] = self.instance
-db = router.db_for_write(rel_model, instance=self.instance)
+kwargs[self.rel_field.name] = self.instance
+db = router.db_for_write(self.model, instance=self.instance)
 return super(RelatedManager, 
self.db_manager(db)).create(**kwargs)
 create.alters_data = True
 
 def get_or_create(self, **kwargs):
 # Update kwargs with the related object that this
 # ForeignRelatedObjectsDescriptor knows about.
-kwargs[rel_field.name] = self.instance
-db = router.db_for_write(rel_model, instance=self.instance)
+kwargs[self.rel_field.name] = self.instance
+db = router.db_for_write(self.model, instance=self.instance)
 return super(RelatedManager, 
self.db_manager(db)).get_or_create(**kwargs)
 get_or_create.alters_data = True
 
 # remove() and clear() are only provided if the ForeignKey can 
have a value of null.
 if rel_field.null:
 def remove(self, *objs):
-val = getattr(self.instance, 
rel_field.rel.get_related_field().attname)
+val = getattr(self.instance, 
self.rel_field.rel.get_related_field().attname)
 for obj in objs:
 # Is obj actually part of this descriptor set?
-if getattr(obj, rel_field.attname) == val:
-setattr(obj, rel_field.name, None)
+if getattr(obj, self.rel_field.attname) == val:
+setattr(obj, self.rel_field.name, None)
 obj.save()
 else:
-   

[Changeset] r16912 - django/trunk/django/db/models/fields

[noreply]

Author: lukeplant
Date: 2011-09-29 08:30:19 -0700 (Thu, 29 Sep 2011)
New Revision: 16912

Modified:
   django/trunk/django/db/models/fields/related.py
Log:
Small cleanups of 'related manager' code for consistency

Modified: django/trunk/django/db/models/fields/related.py
===
--- django/trunk/django/db/models/fields/related.py 2011-09-28 14:00:43 UTC 
(rev 16911)
+++ django/trunk/django/db/models/fields/related.py 2011-09-29 15:30:19 UTC 
(rev 16912)
@@ -417,58 +417,63 @@
 rel_model = self.related.model
 
 class RelatedManager(superclass):
+def __init__(self, model=None, core_filters=None, instance=None):
+super(RelatedManager, self).__init__()
+self.model = model
+self.core_filters = core_filters
+self.instance = instance
+
 def get_query_set(self):
-db = self._db or router.db_for_read(rel_model, 
instance=instance)
+db = self._db or router.db_for_read(rel_model, 
instance=self.instance)
 return 
superclass.get_query_set(self).using(db).filter(**(self.core_filters))
 
 def add(self, *objs):
 for obj in objs:
 if not isinstance(obj, self.model):
 raise TypeError("'%s' instance expected" % 
self.model._meta.object_name)
-setattr(obj, rel_field.name, instance)
+setattr(obj, rel_field.name, self.instance)
 obj.save()
 add.alters_data = True
 
 def create(self, **kwargs):
-kwargs[rel_field.name] = instance
-db = router.db_for_write(rel_model, instance=instance)
+kwargs[rel_field.name] = self.instance
+db = router.db_for_write(rel_model, instance=self.instance)
 return super(RelatedManager, 
self.db_manager(db)).create(**kwargs)
 create.alters_data = True
 
 def get_or_create(self, **kwargs):
 # Update kwargs with the related object that this
 # ForeignRelatedObjectsDescriptor knows about.
-kwargs[rel_field.name] = instance
-db = router.db_for_write(rel_model, instance=instance)
+kwargs[rel_field.name] = self.instance
+db = router.db_for_write(rel_model, instance=self.instance)
 return super(RelatedManager, 
self.db_manager(db)).get_or_create(**kwargs)
 get_or_create.alters_data = True
 
 # remove() and clear() are only provided if the ForeignKey can 
have a value of null.
 if rel_field.null:
 def remove(self, *objs):
-val = getattr(instance, 
rel_field.rel.get_related_field().attname)
+val = getattr(self.instance, 
rel_field.rel.get_related_field().attname)
 for obj in objs:
 # Is obj actually part of this descriptor set?
 if getattr(obj, rel_field.attname) == val:
 setattr(obj, rel_field.name, None)
 obj.save()
 else:
-raise rel_field.rel.to.DoesNotExist("%r is not 
related to %r." % (obj, instance))
+raise rel_field.rel.to.DoesNotExist("%r is not 
related to %r." % (obj, self.instance))
 remove.alters_data = True
 
 def clear(self):
 self.update(**{rel_field.name: None})
 clear.alters_data = True
 
-manager = RelatedManager()
 attname = rel_field.rel.get_related_field().name
-manager.core_filters = {'%s__%s' % (rel_field.name, attname):
-getattr(instance, attname)}
-manager.model = self.related.model
+return RelatedManager(model=self.related.model,
+  core_filters = {'%s__%s' % (rel_field.name, 
attname):
+  getattr(instance, attname)},
+  instance=instance
+  )
 
-return manager
-
-def create_many_related_manager(superclass, rel=False):
+def create_many_related_manager(superclass, rel):
 """Creates a manager that subclasses 'superclass' (which is a Manager)
 and adds behavior for many-to-many related objects."""
 through = rel.through

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16371: model fieldname as css class in admin edit view

[Django]

#16371: model fieldname as css class in admin edit view
-+
 Reporter:  thomasbilk   |Owner:  silent1mezzo
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  css class admin  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+
Changes (by julien):

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


Comment:

 The attached patch adds the "field-" prefix to the main form's and inline
 forms' CSS class names.

-- 
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] #9057: allow override of contrib.auth auto creation of permissions and superuser

[Django]

#9057: allow override of contrib.auth auto creation of permissions and superuser
-+-
 Reporter:  hvendelbo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  auth | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by koenb):

 * needs_docs:  0 => 1
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 This patch has a different take: make it a meta option per model (called
 "no_default_permissions") to prevent creating the three default
 permissions for that model.

 Added a test in a new folder regressiontests/auth_permissions since I did
 not know where to put them otherwise.

-- 
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] #11195: add fieldname to admin changelist tags -- eases CSS customization

[Django]

#11195: add fieldname to admin changelist  tags -- eases CSS customization
---+
 Reporter:  akaihola   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  css| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+

Comment (by julien):

 The latest patch re-uses one of the earlier suggested ideas, i.e. using a
 "field-" prefix, as this is more semantic. "cell-" was in fact more about
 presentation, which is best to avoid.

-- 
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] #11707: limit_choices_to on a ForeignKey can render duplicate options in formfield

[Django]

#11707: limit_choices_to on a ForeignKey can render duplicate options in 
formfield
-+-
 Reporter:  Chris.Wesseling@…|Owner:
 Type:  Bug  |  charstring
Component:  Forms|   Status:  new
 Severity:  Normal   |  Version:  SVN
 Keywords:  ForeingKey   |   Resolution:
  limit_choices_to, dceu2011 | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Replying to [comment:19 jacob]:
 > Discussion from IRC:
 > {{{
 > [09:26am] jacobkm: It also needs additions to documentation to mention
 that Q() objects are acceptable in limit_choices_to.
 > }}}

 
[https://docs.djangoproject.com/en/1.3/ref/models/fields/#django.db.models.ForeignKey.limit_choices_to
 Documentation] on ForeignKey.limit_choices_to already mentions: "Instead
 of a dictionary this can also be a Q object for more complex queries."

 Further discussion:
 {{{
 17:00 < chars> jacobkm: The only known case that broke the original
 .distinct()
solution was in Postgres. So maybe if #6422 gets accepted,
 we
could test for the distinct_on_fields feature and then
 distinct
on the pk, which is unique by definition.
 17:00 < jacobkm> chars: see now *that* makes me a lot happier.
 17:00 < chars> And fallback to the vanilla .distinct() if the backend
 doesn't
support it.
 }}}

 That's #6422.

-- 
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:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by koenb):

 * has_patch:  0 => 1


Comment:

 Added a patch with test

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

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

Re: [Django] #8060: Admin Inlines do not respect user permissions

[Django]

#8060: Admin Inlines do not respect user permissions
-+-
 Reporter:  p.patruno@…  |Owner:  sjaensch
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  inlines User | Triage Stage:  Accepted
  authentication |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by sjaensch):

 * needs_better_patch:  0 => 1


Comment:

 I just added a bit of documentation. All of django's tests pass, by the
 way.

-- 
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] #16005: Missing and operator in blocktrans documentation

[Django]

#16005: Missing and operator in blocktrans documentation
-+-
 Reporter:  bezidejni|Owner:  bezidejni
 Type:  Bug  |   Status:  reopened
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  blocktrans   | Triage Stage:  Ready for
Has patch:  0|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by hraban):

 * status:  closed => reopened
 * cc: hraban (added)
 * has_patch:  1 => 0
 * ui_ux:   => 0
 * resolution:  fixed =>


Comment:

 the currently distributed version of Django 1.3 doesn’t understand "and"
 in blocktrans any more, so the documentation has to be reverted to the
 previous state

-- 
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] #6646: included template blocks are not being overrided by parent template.

[Django]

#6646: included template blocks are not being overrided by parent template.
-+-
 Reporter:  anonymous|Owner:
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  include, extends,| Triage Stage:  Accepted
  block  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bberes):

 * cc: botondus@… (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] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
 Reporter:  Manfred Wassmann |Owner:  jgelens
   |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by konk):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 I've come up with another case where it fails; added it to the tests in
 the patch.

 Basically, the error lies in the assumption that all fields in the
 DISTINCT ON set belong to the base model of the QuerySet.

-- 
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] #8995: Add support for https to sitemaps

[Django]

#8995: Add support for https to sitemaps
--+
 Reporter:  john  |Owner:  nobody
 Type:  New feature   |   Status:  reopened
Component:  contrib.sitemaps  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:  sitemaps  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by mpaolini):

 added some documentation for this new feature

-- 
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] #10523: Changing object with long __repr__ causes error

[Django]

#10523: Changing object with long __repr__ causes error
---+
 Reporter:  bromer |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  contrib.admin  |  Version:  1.2-beta
 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 julien):

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


Comment:

 Most likely the issue here is when `__repr__()` returns a unicode, which
 isn't properly cut down to 200 characters by simply using `[:200]`.

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

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

[Django] #16959: Enhanced MultiWidget rendering using a layout

[Django]

#16959: Enhanced MultiWidget rendering using a layout
--+
 Reporter:  maraujop  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Forms |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Hi,

 I have worked on an enhacement of `MultiWidget` that easily lets you
 control the rendering of a subclass using a layout, it's called
 `MultiWidgetLayout`. You can find it here:
 https://github.com/maraujop/django-MultiWidgetLayout

 Cheers,
 Miguel

-- 
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] #9976: Generic Foreign Keys should have a nice widget(ala raw_id)

[Django]

#9976: Generic Foreign Keys should have a nice widget(ala raw_id)
---+
 Reporter:  Alex   |Owner:  Alex
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.0
 Severity:  Normal |   Resolution:
 Keywords:  design_ux  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by julien):

 * has_patch:  0 => 1
 * ui_ux:   => 1
 * easy:   => 0


Comment:

 I've updated the patch to current trunk and fixed the tests. I haven't
 examined the UI in detail yet though. Feedback and patches welcome.

-- 
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] #9718: Reference to 'FormWrapper objects' in auth docs is confusing

[Django]

#9718: Reference to 'FormWrapper objects' in auth docs is confusing
---+--
 Reporter:  hwaara@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.0
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by kmtracey):

 The Django Book is not part of the Django project documentation, it's an
 independent endeavor. In fact the example you point to has also been
 changed in the newest version of that book
 (http://www.djangobook.com/en/2.0/chapter14/)...what you have pointed to
 is a beta version of the 1.0 version...likely you do not want to be using
 that version to go 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.

[Django] #16958: change_password admin view ignores ModelAdmin queryset(request) method

[Django]

#16958: change_password admin view ignores ModelAdmin queryset(request) method
--+-
 Reporter:  mpaolini  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.3
 Severity:  Normal|   Keywords:  admin, auth
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+-
 change_password view in {{{django.contrib.auth.admin.UserAdmin}}} does not
 use
 {{{self.queryset()}}} to retrieve the user instance to act on.

 Let's assume a developer has subclassed UserAdmin overriding its queryset
 method to hide certain users from admin web interface,
 then he would be surprised to find out that someone with change_user
 permission can still change password of these hidden users.

 attached patch (applies to trunk) with test.

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

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

Re: [Django] #9718: Reference to 'FormWrapper objects' in auth docs is confusing

[Django]

#9718: Reference to 'FormWrapper objects' in auth docs is confusing
---+--
 Reporter:  hwaara@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.0
 Severity:  Normal |   Resolution:  fixed
 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 anonymous):

 * severity:   => Normal
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:   => 0
 * needs_docs:   => 0
 * ui_ux:   => 0
 * type:   => Uncategorized


Comment:

 http://www.djangobook.com/en/beta/chapter12/ still there?

-- 
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] #16957: Timezone changes on development server after first request

[Django]

#16957: Timezone changes on development server after first request
-+
 Reporter:  antti.a.laine@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Other) |Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 When using development server, the time returned by datetime, time and
 other modules is in different timezone after the first request has been
 served.

 settings.py:
 {{{#!python
 TIME_ZONE = 'Europe/Helsinki'
 }}}

 Example view:
 {{{#!python
 from datetime import datetime

 now = datetime.now()
 utc = datetime.utcnow()
 return HttpResponse("now = %s\nutc = %s\n" % (now, utc))
 }}}

 At the time of writing in this gives:
 {{{
 now = 2011-09-29 11:55:15.651728
 utc = 2011-09-29 08:55:15.651732
 }}}

 ...when the request is done after starting the development server, and
 {{{
 now = 2011-09-29 08:55:16.631865
 utc = 2011-09-29 08:55:16.631903
 }}}

 ...after making the request the second time.

 It does not matter which request is first handled; the timezone gets
 changed when any request gets run after starting the development server.
 This bug is not present when running on a production server (Google App
 Engine in this 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.

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 julien):

 * easy:   => 0


Comment:

 See also #7028 re: improving the raw_id_fields widget UI.

-- 
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 julien):

 See also #10293 re: ManyToMany raw_id_fields.

-- 
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] #16956: ContentTypes error in test with master/slave configuration

[Django]

#16956: ContentTypes error in test with master/slave configuration
-+-
 Reporter:  Petr Gorodechnyj |  Owner:  nobody
 | Status:  new
 Type:  Bug  |Version:  1.3
Component:   |   Keywords:  contenttypes test
  contrib.contenttypes   |  valueerror
 Severity:  Normal   |  Has patch:  0
 Triage Stage:  Unreviewed   |  UI/UX:  0
Easy pickings:  0|
-+-
 Hello.
 I get strange "ValueError: list.remove(x): x not in list" when I try to
 test my project. This happens only with master/slave configuration. If I
 use single 'default' database everything works ok.
 Database configuration:
 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'NAME': 'dbname',
 'USER': 'gorodechnyj',
 'PASSWORD': 'pass',
 'HOST': 'host',
 'PORT': '5432',
 'TEST_CHARSET': 'UTF-8',
 },
 'slave': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'NAME': 'dbname',
 'USER': 'gorodechnyj',
 'PASSWORD': 'pass',
 'HOST': 'host',
 'PORT': '5432',
 'TEST_CHARSET': 'UTF-8',
 'TEST_MIRROR': 'default'
 }
 }
 if len(DATABASES) > 1 :
 DATABASE_ROUTERS = ['path.to.MasterSlaveRouter']
 }}}

 Router configuration:
 {{{
 import random

 class MasterSlaveRouter(object):
 ''' A router that sets up a simple master/slave configuration '''

 def db_for_read(self, model, **hints):
 return random.choice(['default', 'slave'])

 def db_for_write(self, model, **hints):
 "Point all write operations to the master"
 return 'default'

 def allow_relation(self, obj1, obj2, **hints):
 "Allow any relation between two objects"
 return True

 def allow_syncdb(self, db, model):
 if db == 'default':
 return True
 return False
 }}}

 What I got in case of
 {{{
 python manage.py test
 }}}
 is this stack trace:
 {{{
 Traceback (most recent call last):
   File "manage.py", line 15, in 
 execute_manager(settings)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 438, in execute_manager
 utility.execute()
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 191, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 220, in execute
 output = self.handle(*args, **options)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/commands/test.py", line 37, in handle
 failures = test_runner.run_tests(test_labels)
   File "/usr/local/lib/python2.7/site-packages/django/test/simple.py",
 line 359, in run_tests
 old_config = self.setup_databases()
   File "/usr/local/lib/python2.7/site-packages/django/test/simple.py",
 line 296, in setup_databases
 test_db_name = connection.creation.create_test_db(self.verbosity,
 autoclobber=not self.interactive)
   File "/usr/local/lib/python2.7/site-
 packages/django/db/backends/creation.py", line 366, in create_test_db
 load_initial_data=False)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 166, in call_command
 return klass.execute(*args, **defaults)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 220, in execute
 output = self.handle(*args, **options)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 351, in handle
 return self.handle_noargs(**options)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/commands/syncdb.py", line 109, in
 handle_noargs
 emit_post_sync_signal(created_models, verbosity, interactive, db)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/sql.py", line 190, in
 emit_post_sync_signal
 interactive=interactive, db=db)
   File "/usr/local/lib/python2.7/site-
 packages/django/dispatch/dispatcher.py", line 172, in send
 response = receiver(signal=self, sender=sender, **named)
   File "/usr/local/lib/python2.7/site-
 packages/django/contrib/contenttypes/management.py", line 25, in
 update_contenttypes
 content_types.remove(ct)
 ValueError: list.remove(x): x not in list
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django u