[Django] #19069: improve error when attempting to use a swapped model

[Django]

#19069: improve error when attempting to use a swapped model
--+
 Reporter:  ptone |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently two checks for a swapped model exist when creating a manager:

 *
 
https://github.com/django/django/blob/3b6f980bedbbf091fe29bececa2b262d2084ce4d/django/db/models/manager.py#L16
 *
 
https://github.com/django/django/blob/3b6f980bedbbf091fe29bececa2b262d2084ce4d/django/db/models/manager.py#L61

 These result in an error:


 {{{AttributeError: type object 'User' has no attribute 'objects'}}}

 as opposed to {{{DatabaseError: no such table: <...>}}} which is the error
 when the model is swapped but has the default manager (as syncdb will not
 create tables for swapped models).  Ideally - there should be a manager
 installed that just raises an error explaining that the model has been
 swapped and is unavailable and probably offer information about what model
 it was swapped for - as this is readily available.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18978: Move cleanup management command to contrib.sessions

[Django]

#18978: Move cleanup management command to contrib.sessions
-+-
 Reporter:  rasca|Owner:  rasca
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by ptone):

 Sorry about the confusion on pull requests - it is an area for growth as
 we transition to github.

 I agree about not deprecating cleanup - it can remain as a simple alias
 for now.

 I do think we pull it from the documentation entirely for now (but see
 ramble below)

 Any new features of a future implementation of the cleanup command are
 beyond the scope of this particular ticket, and yes - would require its
 own ticket.  However I can tell you that the approach of using a setting
 is probably a non-starter.  Perhaps allow any app to define a 'cleanup'
 command - and the core cleanup command would use the command discovery
 machinery to find and run each one of them.  However that will take some
 design consideration, as it is an entirely new behavior for management
 commands, and becomes perhaps a bit too implicit/magical.  If this were
 the approach taken, the sessions cleanup - would once again be called
 cleanup - and so perhaps these issues should be coupled. In otherwords,
 make that decision first.

 So to rephrase, cleanup would become a new "special" management command -
 which will simply call the cleanup command in any app, and the current
 sessions cleanup command would be one such example located in
 contrib.sessions.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19067: createsuperuser fails when custom user model has no username

[Django]

#19067: createsuperuser fails when custom user model has no username
---+
 Reporter:  clelland   |Owner:  clelland
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by melinath):

 * needs_better_patch:  0 => 1
 * needs_docs:  0 => 1
 * component:  contrib.auth => Documentation
 * needs_tests:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 The create_superuser management command is actually just a thin wrapper
 around UserManager.create_superuser(), which is pretty tied into the way
 the AbstractUserModel (i.e. the old User model) works. For example, it
 assumes there are is_staff, is_superuser, and is_active fields. It also
 assumes that there's a username.

 I don't think there's an elegant way to rewrite create_superuser to not
 make any assumptions and still present the same contract. If you can find
 a way, that's great.

 Clarifying in the docs that these commands currently only work with User
 models that look a lot like the default model is easy and easy to approve.
 Rewriting create_superuser might be worth bringing up on the django-dev
 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19068: comments in a multiple database context

[Django]

#19068: comments in a multiple database context
--+--
 Reporter:  esimorre  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.comments  |  Version:
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by esimorre):

 my contenttypes' table is in sqlitedb , self.model_class() is stored in
 oracledb

 this expression is incorrect because "self" is a ContentType object
 {{{self.model_class()._base_manager.using(self._state.db).get(**kwargs)}}}

 The commented object (oracledb) is searched in the contenttype sqlitedb.
 If "objects" is used, the db is right.

 I have no trace (the project is deployed in an intranet), but the error
 message is: table xxx not found.

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

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

Re: [Django] #14930: `values_list()` fails on queryset ordered by extra column

[Django]

#14930: `values_list()` fails on queryset ordered by extra column
-+-
 Reporter:  lsaffre  |Owner:  vicould
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by vicould):

 * needs_better_patch:  1 => 0


Comment:

 Alright, this one should be good. I believe I fixed the issues, both
 {{{order_by}}} on a QuerySet and {{{order_by}}} in {{{extra}}} directives
 work.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19068: comments in a multiple database context

[Django]

#19068: comments in a multiple database context
--+--
 Reporter:  esimorre  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.comments  |  Version:
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by melinath):

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


Comment:

 I wouldn't be surprised if contrib.comments had issues related to multiple
 databases. But neither of the changes suggested would improve multiple
 database support. _default_manager, for example, is usually the same as
 .objects, unless a new default manager is being used (in which case that
 should probably be used instead of .objects).

 It would be great if you could gather more information and reopen this
 ticket. What's the exact problem you're seeing? Are you getting any kind
 of traceback?

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18826: A bit changed JavaScript for CSRF with async JS

[Django]

#18826: A bit changed JavaScript for CSRF with async JS
-+-
 Reporter:  panco|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  ajax, csrf   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 My feeling is that the current code is functional and works fine, but I'll
 defer if another core dev wants to accept 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 https://groups.google.com/groups/opt_out.

Re: [Django] #18954: Initial sql data documentation

[Django]

#18954: Initial sql data documentation
---+
 Reporter:  jli|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timo):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19006: Content-Disposition example does not work in certain browsers if the filename has a space

[Django]

#19006: Content-Disposition example does not work in certain browsers if the
filename has a space
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  closed
Component:  Documentation  |Version:  1.4
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+

Comment (by Tim Graham ):

 In [changeset:"8868a067e02b4fe9f1c669f06e90fc28171b9758"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8868a067e02b4fe9f1c669f06e90fc28171b9758"
 [1.4.X] Fixed #19006 - Quoted filenames in Content-Disposition header.

 Backport of 234ca6c61d from master
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 8868a0: [1.4.X] Fixed #19006 - Quoted filenames in Content...

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: 8868a067e02b4fe9f1c669f06e90fc28171b9758
  
https://github.com/django/django/commit/8868a067e02b4fe9f1c669f06e90fc28171b9758
  Author: Tim Graham 
  Date:   2012-10-03 (Wed, 03 Oct 2012)

  Changed paths:
M docs/howto/outputting-csv.txt
M docs/howto/outputting-pdf.txt
M docs/ref/request-response.txt

  Log Message:
  ---
  [1.4.X] Fixed #19006 - Quoted filenames in Content-Disposition header.

Backport of 234ca6c61d from master



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

Re: [Django] #19006: Content-Disposition example does not work in certain browsers if the filename has a space

[Django]

#19006: Content-Disposition example does not work in certain browsers if the
filename has a space
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  closed
Component:  Documentation  |Version:  1.4
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"234ca6c61d27d1cd430a5290ff858c25afb93098"]:
 {{{
 #!CommitTicketReference repository=""
 revision="234ca6c61d27d1cd430a5290ff858c25afb93098"
 Fixed #19006 - Quoted filenames in Content-Disposition header.
 }}}

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

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

[django/django] 234ca6: Fixed #19006 - Quoted filenames in Content-Disposi...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 234ca6c61d27d1cd430a5290ff858c25afb93098
  
https://github.com/django/django/commit/234ca6c61d27d1cd430a5290ff858c25afb93098
  Author: Tim Graham 
  Date:   2012-10-03 (Wed, 03 Oct 2012)

  Changed paths:
M docs/howto/outputting-csv.txt
M docs/howto/outputting-pdf.txt
M docs/ref/request-response.txt

  Log Message:
  ---
  Fixed #19006 - Quoted filenames in Content-Disposition header.



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

Re: [Django] #16039: syncdb with --database option fails

[Django]

#16039: syncdb with --database option fails
-+-
 Reporter:  yedpodtrzitko|Owner:
 Type:  Bug  |  mhaligowski
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  1.4
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mhaligowski):

 * owner:  nobody => mhaligowski
 * needs_better_patch:  0 => 1
 * cc: mhaligowski (added)
 * status:  reopened => new
 * needs_tests:  0 => 1


Comment:

 No tests at all. At the current stage of development.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18413: documentation on delete() should mention that associated file or image is not deleted

[Django]

#18413: documentation on delete() should mention that associated file or image 
is
not deleted
--+
 Reporter:  lawgon|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:  delete FileField  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"b1462e0a36bc6bb2c221bda107da74a6381b9675"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b1462e0a36bc6bb2c221bda107da74a6381b9675"
 [1.4.X] Fixed #18413 - Noted that a model's files are not deleted when the
 model is deleted. Thanks lawgon for the report.

 Backport of 1c03b23567 from master
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] b1462e: [1.4.X] Fixed #18413 - Noted that a model's files ...

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: b1462e0a36bc6bb2c221bda107da74a6381b9675
  
https://github.com/django/django/commit/b1462e0a36bc6bb2c221bda107da74a6381b9675
  Author: Tim Graham 
  Date:   2012-10-03 (Wed, 03 Oct 2012)

  Changed paths:
M docs/ref/models/fields.txt

  Log Message:
  ---
  [1.4.X] Fixed #18413 - Noted that a model's files are not deleted when the 
model is deleted. Thanks lawgon for the report.

Backport of 1c03b23567 from master



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

Re: [Django] #18413: documentation on delete() should mention that associated file or image is not deleted

[Django]

#18413: documentation on delete() should mention that associated file or image 
is
not deleted
--+
 Reporter:  lawgon|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:  delete FileField  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"1c03b23567a3098b9ab5df64b14e0dea8d1414ea"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1c03b23567a3098b9ab5df64b14e0dea8d1414ea"
 Fixed #18413 - Noted that a model's files are not deleted when the model
 is deleted. Thanks lawgon for the report.
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 1c03b2: Fixed #18413 - Noted that a model's files are not ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1c03b23567a3098b9ab5df64b14e0dea8d1414ea
  
https://github.com/django/django/commit/1c03b23567a3098b9ab5df64b14e0dea8d1414ea
  Author: Tim Graham 
  Date:   2012-10-03 (Wed, 03 Oct 2012)

  Changed paths:
M docs/ref/models/fields.txt

  Log Message:
  ---
  Fixed #18413 - Noted that a model's files are not deleted when the model is 
deleted. Thanks lawgon for the report.



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

Re: [Django] #11027: Storage backends should know about the max_length attribute of the FileFields

[Django]

#11027: Storage backends should know about the max_length attribute of the
FileFields
--+
 Reporter:  apollo13  |Owner:  melinath
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  Version:  master
 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 melinath):

 Yes, .save() (and ._save()) would also need to know about the max_length
 restriction.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #15915: Permission codename duplication is not handled well

[Django]

#15915: Permission codename duplication is not handled well
--+---
 Reporter:  valyagolev|Owner:  mhaligowski
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+---
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"8c427448d53ec0d860e1669f35deed73d0240ba1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8c427448d53ec0d860e1669f35deed73d0240ba1"
 Fixed #15915 -- Cleaned handling of duplicate permission codenames

 Previously, a duplicate model, codename for permission would lead to
 database integrity error. Cleaned the implementation so that this case
 now raises an CommandError instead.
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 8c4274: Fixed #15915 -- Cleaned handling of duplicate perm...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 8c427448d53ec0d860e1669f35deed73d0240ba1
  
https://github.com/django/django/commit/8c427448d53ec0d860e1669f35deed73d0240ba1
  Author: Mateusz Haligowski 
  Date:   2012-10-03 (Wed, 03 Oct 2012)

  Changed paths:
M django/contrib/auth/management/__init__.py
M django/contrib/auth/tests/management.py

  Log Message:
  ---
  Fixed #15915 -- Cleaned handling of duplicate permission codenames

Previously, a duplicate model, codename for permission would lead to
database integrity error. Cleaned the implementation so that this case
now raises an CommandError instead.



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

Re: [Django] #19068: comments in a multiple database context

[Django]

#19068: comments in a multiple database context
--+--
 Reporter:  esimorre  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.comments  |  Version:
 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 esimorre):

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


Comment:

 I would suggest to replace '''_base_manager.using(self._state.db)''' by
 '''objects''' below

  * contenttypes.models.py:
 {{{
 def get_object_for_this_type(self, **kwargs):
 """
 Returns an object of this type for the keyword arguments given.
 Basically, this is a proxy around this object_type's get_object()
 model
 method. The ObjectNotExist exception, if thrown, will not be
 caught,
 so code that calls this method should catch it.
 """
 return
 self.model_class()._base_manager.using(self._state.db).get(**kwargs)
 }}}

 idem for '''_default_manager.using(self.target_object._state.db)''' below

  * comments.forms.py:
 {{{
 def check_for_duplicate_comment(self, new):
 """
 Check that a submitted comment isn't a duplicate. This might be
 caused
 by someone posting a comment twice. If it is a dup, silently
 return the *previous* comment.
 """
 possible_duplicates =
 self.get_comment_model()._default_manager.using(
 self.target_object._state.db
 ).filter(
 content_type = new.content_type,
 object_pk = new.object_pk,
 user_name = new.user_name,
 user_email = new.user_email,
 user_url = new.user_url,
 )
 for old in possible_duplicates:
 if old.submit_date.date() == new.submit_date.date() and
 old.comment == new.comment:
 return old

 return new
 }}}

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

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

Re: [Django] #15915: Permission codename duplication is not handled well

[Django]

#15915: Permission codename duplication is not handled well
--+---
 Reporter:  valyagolev|Owner:  mhaligowski
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+---

Comment (by akaariai):

 Doing a final test run and then committing the patch with some final
 polishing.

 This brings back the idea of validating globally that 
 pairs are unique. Doing that would of course solve also this ticket's
 issue. In my opinion we should do that validation sooner rather than
 later. Still, it seems adding the currently available implementation is a
 step forward, and it will not hurt anybody even if the global validation
 is 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 https://groups.google.com/groups/opt_out.

[Django] #19068: comments in a multiple database context

[Django]

#19068: comments in a multiple database context
--+
 Reporter:  esimorre  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.comments  |Version:
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 a legacy database, another database to store
 (django.contrib.admin.)comments: it does not work.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18996: better document overridden model save not called on bulk update.

[Django]

#18996: better document overridden model save not called on bulk update.
-+-
 Reporter:  bram.dejong@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs overriding  |  Needs documentation:  1
  save bulk update   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by Elvard):

 * cc: tomas.ehrlich@… (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 https://groups.google.com/groups/opt_out.

Re: [Django] #18978: Move cleanup management command to contrib.sessions

[Django]

#18978: Move cleanup management command to contrib.sessions
-+-
 Reporter:  rasca|Owner:  rasca
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-
Changes (by Elvard):

 * cc: tomas.ehrlich@… (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 https://groups.google.com/groups/opt_out.

Re: [Django] #18978: Move cleanup management command to contrib.sessions

[Django]

#18978: Move cleanup management command to contrib.sessions
-+-
 Reporter:  rasca|Owner:  rasca
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-

Comment (by Elvard):

 Ok, it was easier for me to pull request rather than submit patch here…

 I just don't agree with any deprecation warning. The '''cleanup''' command
 do the same job as it always did -- it cleans expired sessions and it
 requires Sessions installed. I don't think it will be removed in future.
 Each app will probably provide it's own '''clean*''' method and
 '''cleanup''' will collect them.

 Possible feature in this scenario would be new setting, where one could
 define list of all '''clean*''' commands triggered by '''cleanup'''
 command. This would be handy, eg: django-registration provides
 '''cleanupregistration'''. This would be quiet easily implemented. Should
 I post a patch for it or open new ticket for this feature?

 Last thing, I just can't find any tests for old '''cleanup''' command. I
 have to probably write them…

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18996: better document overridden model save not called on bulk update.

[Django]

#18996: better document overridden model save not called on bulk update.
-+-
 Reporter:  bram.dejong@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs overriding  |  Needs documentation:  1
  save bulk update   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by akaariai):

 * needs_better_patch:  0 => 1


Comment:

 The patch isn't correct - you can't use pre/post_save for update
 operations. In addition, bulk_create would be good to mention at the same
 time, too. It is a bit sad that there isn't anything you can use for
 .update() operations currently...

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #11027: Storage backends should know about the max_length attribute of the FileFields

[Django]

#11027: Storage backends should know about the max_length attribute of the
FileFields
--+
 Reporter:  apollo13  |Owner:  melinath
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  Version:  master
 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 akaariai):

 I kind of like the idea that get_valid_name() just converts the name to be
 something valid for the storage backend. Then, get_available_name has the
 final control of how to truncate the name, and to make sure the name is
 within the name length limit. The contract is altered from "gimme an
 available file name as close to the requested name" to "gimme an available
 file name as close to the requested name, max length N".

 It seems the final name is determined by .save() - if the file name
 clashes due to race conditions, then .save() can alter the file name. This
 brings another point to the discussion: if final file name is determined
 by .save(), then shouldn't .save() also know the file name length
 restriction?

 As for implementation, I like the try-except approach most.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18996: better document overridden model save not called on bulk update.

[Django]

#18996: better document overridden model save not called on bulk update.
-+-
 Reporter:  bram.dejong@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  docs overriding  |  Needs documentation:  1
  save bulk update   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by Elvard):

 * 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 https://groups.google.com/groups/opt_out.

Re: [Django] #14567: ModelMultipleChoiceField inconsistently returns a list if empty.

[Django]

#14567: ModelMultipleChoiceField inconsistently returns a list if empty.
--+
 Reporter:  melinath  |Owner:  akaariai
 Type:  Bug   |   Status:  closed
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by akaariai):

 Committed with some docs additions and some changes to the tests to avoid
 even larger HTML output comparisons.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #14567: ModelMultipleChoiceField inconsistently returns a list if empty.

[Django]

#14567: ModelMultipleChoiceField inconsistently returns a list if empty.
--+
 Reporter:  melinath  |Owner:  akaariai
 Type:  Bug   |   Status:  closed
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"218abcc9e550d266a9979e10f562fc21b8f34c6a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="218abcc9e550d266a9979e10f562fc21b8f34c6a"
 Fixed #14567 -- Made ModelMultipleChoiceField return EmptyQuerySet as
 empty value
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 218abc: Fixed #14567 -- Made ModelMultipleChoiceField retu...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 218abcc9e550d266a9979e10f562fc21b8f34c6a
  
https://github.com/django/django/commit/218abcc9e550d266a9979e10f562fc21b8f34c6a
  Author: Stephen Burrows 
  Date:   2012-10-03 (Wed, 03 Oct 2012)

  Changed paths:
M django/forms/models.py
M docs/ref/forms/fields.txt
M docs/releases/1.5.txt
M tests/modeltests/model_forms/tests.py
M tests/regressiontests/forms/models.py
M tests/regressiontests/forms/tests/models.py

  Log Message:
  ---
  Fixed #14567 -- Made ModelMultipleChoiceField return EmptyQuerySet as empty 
value



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

Re: [Django] #19067: createsuperuser fails when custom user model has no username

[Django]

#19067: createsuperuser fails when custom user model has no username
--+--
 Reporter:  clelland  |Owner:  clelland
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by clelland):

 I've just re-re-read the docs, and realized that the api contract for
 `create_user` and `create_superuser` explicitly shows `username` being the
 first argument, and that seems to imply that it refers to the
 USERNAME_FIELD, and not specifically a field named `username`

 Please feel free to mark this as invalid if that's the case, and I'll add
 a note to the docs instead :)

 However,  that interpretation does mean that you wouldn't be able to
 create a model like this:

 {{{
 class MyUser(AbstractBaseUser):
 email = models.CharField(max_length=254, unique=True)
 username = models.CharField(max_length=20, unique=True)
 USERNAME_FIELD = 'email'
 REQUIRED_FIELDS = ['username']
 }}}

 As the required fields would be passed into `create_user` as keyword
 arguments, and this would conflict with the named `username` parameter.

 It's an edge case, but one that we can easily get around by not
 constraining the parameter names in the manager methods.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #14567: ModelMultipleChoiceField inconsistently returns a list if empty.

[Django]

#14567: ModelMultipleChoiceField inconsistently returns a list if empty.
--+
 Reporter:  melinath  |Owner:  akaariai
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by akaariai):

 * status:  assigned => new
 * owner:  melinath => akaariai


Comment:

 To me it seems this needs a minor note as a backwards incompatible change.
 In any case, this is a change we should do. The return value should always
 be of consistent type (that is, a queryset). The docs aren't exactly
 accurate currently anyways as of the return value.

 I will take care of committing 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19067: createsuperuser fails when custom user model has no username

[Django]

#19067: createsuperuser fails when custom user model has no username
--+--
 Reporter:  clelland  |Owner:  clelland
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by clelland):

 * owner:  nobody => clelland
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 1
 * needs_better_patch:   => 0


Comment:

 The fix for this is on my github branch
 https://github.com/clelland/django/tree/ticket_19067

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19067: createsuperuser fails when custom user model has no username

[Django]

#19067: createsuperuser fails when custom user model has no username
--+
 Reporter:  clelland  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There is a dependency in the createsuperuser management command on the
 existence of a field called 'username' in a user model.

 Since #3011 was fixed, user models do not necessarily have that field.
 They are required to have a single identifying field, which is passed in
 as the first parameter to their create_superuser() method, but it is not
 necessarily named `username`.

 As a result, if syncdb installs django.contrib.auth, and the user model
 does not have a 'username' field, then the creation of the initial
 superuser will fail.

 I have a (one line) patch which fixes this, and will try to get tests
 written for it later today.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #16211: using negated F()-expression in update query

[Django]

#16211: using negated F()-expression in update query
-+-
 Reporter:  wdoekes  |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 See pull https://github.com/django/django/pull/419 for suggested changes.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #13181: ChoiceField.choices need to accept callable, not only list or tuple

[Django]

#13181: ChoiceField.choices need to accept callable, not only list or tuple
--+
 Reporter:  mariarchi |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  1.2-beta
 Severity:  Normal|   Resolution:
 Keywords:  ChoiceField, choices  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by t.zander@…):

 * cc: t.zander@… (added)


Comment:

 I'm interested in this, what's the status of it?

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

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

Re: [Django] #19066: ManyToMany Field doesn't allow help_text override

[Django]

#19066: ManyToMany Field doesn't allow help_text override
-+-
 Reporter:  rjalves  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by rjalves):

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


Comment:

 I couldn't find documentation specific to the behavior of help_text in
 ManyToManyField.
 Since this affects public API, should documentation be created? If so,
 please point out where it should be added.

 Thanks

 PS: Possible duplicate of #9321 (only found it afterwards) but with
 different patch target.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19066: ManyToMany Field doesn't allow help_text override

[Django]

#19066: ManyToMany Field doesn't allow help_text override
--+
 Reporter:  rjalves   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 When using ModelForms with Models that include ManyToManyField's there's a
 default help_text message:
 "Hold down "Control", or "Command" on a Mac, to select more than one."

 If you use a different widget for fields of this type, such as
 CheckboxSelectMultiple, the help_text message makes no sense.

 The way it's currently implemented the message is always appended to what
 is passed.

 The attached patch changes this such that the message is only displayed if
 the empty string is passed (which is also the default by omission).

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19065: The FilteredManyToMany widget needs javascript in 'stacked.html' and 'tabular.html' when using inline content

[Django]

#19065: The FilteredManyToMany widget needs javascript in 'stacked.html' and
'tabular.html' when using inline content
-+-
 Reporter:  replytosander@…  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


Comment:

 Code used in overridden stacked.html template:


 {{{
 var updateOrderedSelectFilter = function() {
 // If any SelectFilter widgets are a part of the new form,
 // instantiate a new SelectFilter instance for it.
 if (typeof OrderdSelectFilter != "undefined"){
 $(".selectfilter").each(function(index, value){
 var namearr = value.name.split('-');
 OrderdSelectFilter.init(value.id,
 namearr[namearr.length-1], false, "{% admin_media_prefix %}");
 });
 $(".selectfilterstacked").each(function(index, value){
 var namearr = value.name.split('-');
 OrderdSelectFilter.init(value.id,
 namearr[namearr.length-1], true, "{% admin_media_prefix %}");
 });
 }
 }
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19065: The FilteredManyToMany widget needs javascript in 'stacked.html' and 'tabular.html' when using inline content

[Django]

#19065: The FilteredManyToMany widget needs javascript in 'stacked.html' and
'tabular.html' when using inline content
--+
 Reporter:  replytosander@…   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.admin |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I'm developing a custom sortable manytomany widget which allows the user
 to order the items in the widget.

 You can find it here: https://github.com/fabrique/django-sortedm2m

 When using inline models the widget needs the javascript in stacked.html
 and/or tabular.html. It initializes a new instance when adding an inline
 item.

 To keep the sortedm2m library as pluggable as possible I would like to
 know how I can provide this javascript in the library. This way a
 developer doesn't need to override the admin templates.

 This doesn't seem possible at the moment. Maybe there should be a way to
 provide document ready javascript in the scope of the widget.

 Any ideas on 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 https://groups.google.com/groups/opt_out.

Re: [Django] #14930: `values_list()` fails on queryset ordered by extra column

[Django]

#14930: `values_list()` fails on queryset ordered by extra column
-+-
 Reporter:  lsaffre  |Owner:  vicould
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by vicould):

 * status:  new => assigned


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

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

Re: [Django] #14930: `values_list()` fails on queryset ordered by extra column

[Django]

#14930: `values_list()` fails on queryset ordered by extra column
-+-
 Reporter:  lsaffre  |Owner:  vicould
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by vicould):

 * owner:  simon29 => vicould
 * status:  assigned => new


Comment:

 Yes you're right, I just tested without the patch and the tests I wrote
 failed. But with the patch, and the {{{order_by}}} argument inside the
 {{{extra}}} instead of as an additional call the test for
 {{{values_list}}} pass. However, the test with the {{{values}}} fails, as
 the additional ordering column is inserted in the list.
 Here is the output of the test:
 {{{
 First differing element 0:
 {u'num': 72, u'value_plus_one': 73}
 {u'num': 72}
 }}}
 I tested with two extra columns, and only the one on which the results are
 sorted is inserted in the values list. I will try to find the cause, but
 it seems related to the {{{order_by}}} argument.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19063: gml(version=3) does not work for PostGIS

[Django]

#19063: gml(version=3) does not work for PostGIS
-+
 Reporter:  lmisek@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgis gml  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"d25a599dca9b7644b238f6c89a66545dfdabe393"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d25a599dca9b7644b238f6c89a66545dfdabe393"
 Fixed #19063 -- Fixed version parameter of gml GeoQuerySet method

 Thanks lmi...@go2.pl for the report.
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] d25a59: Fixed #19063 -- Fixed version parameter of gml Geo...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d25a599dca9b7644b238f6c89a66545dfdabe393
  
https://github.com/django/django/commit/d25a599dca9b7644b238f6c89a66545dfdabe393
  Author: Claude Paroz 
  Date:   2012-10-03 (Wed, 03 Oct 2012)

  Changed paths:
M django/contrib/gis/db/models/query.py
M django/contrib/gis/tests/geoapp/tests.py

  Log Message:
  ---
  Fixed #19063 -- Fixed version parameter of gml GeoQuerySet method

Thanks lmi...@go2.pl for the report.



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

Re: [Django] #19063: gml(version=3) does not work for PostGIS

[Django]

#19063: gml(version=3) does not work for PostGIS
-+
 Reporter:  lmisek@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  postgis gml  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by claudep):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19063: gml(version=3) does not work for PostGIS

[Django]

#19063: gml(version=3) does not work for PostGIS
-+--
 Reporter:  lmisek@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  postgis gml  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by anonymous):

 * needs_docs:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_better_patch:   => 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 https://groups.google.com/groups/opt_out.

[django/django] c76877: Added a note about postgis_topology in install doc...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: c76877c1d2985e37c3c988d107c44e829fb118af
  
https://github.com/django/django/commit/c76877c1d2985e37c3c988d107c44e829fb118af
  Author: Claude Paroz 
  Date:   2012-10-03 (Wed, 03 Oct 2012)

  Changed paths:
M docs/ref/contrib/gis/install.txt

  Log Message:
  ---
  Added a note about postgis_topology in install docs

Thanks Paolo Corti for the suggestion.



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

Re: [Django] #19055: DateField uses date() which might not be correct in timezone aware situations

[Django]

#19055: DateField uses date() which might not be correct in timezone aware
situations
---+--
 Reporter:  mitar  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  1.4
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 My personal opinion is that `DateField` shouldn't accept `datetime`
 objects. However it did long before I started using Django :)

 My advice is [http://lanyrd.com/2012/djangocon-europe/srptc/ not to mix
 dates and datetimes].

 Could you clarify why you need to feed a `datetime` into a `DateField`?

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19064: select_related doesn't work for reverse one-to-one with inheritance

[Django]

#19064: select_related doesn't work for reverse one-to-one with inheritance
-+-
 Reporter:  zimnyx   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


Comment:

 Marking as duplicate of #13781.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #17922: Add default "required" css classes to form labels

[Django]

#17922: Add default "required" css classes to form labels
-+
 Reporter:  hanson2010   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+

Comment (by claudep):

 Replying to [comment:6 claudep]:
 > The fact that `required_css_class` is not set by default on forms might
 be the subject of another ticket...

 This is tracked in #14322

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #17922: Add default "required" css classes to form labels

[Django]

#17922: Add default "required" css classes to form labels
-+
 Reporter:  hanson2010   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+
Changes (by claudep):

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


Comment:

 Note that there is already a `required_css_class` settable attribute for
 forms, documented here:
 https://docs.djangoproject.com/en/dev/ref/forms/api/#styling-required-or-
 erroneous-form-rows (see also #3512)

 So when a form is output with `as_p`, `as_ul` or `as_tr`, the row itself
 is already marked with the `required_css_class` value, hence the CSS to
 style them is trivial. However, the problem remains when the field is
 output with dict access (`{{ form.myfield.label_tag }}: {{ form.myfield
 }}`). See for example the TODO comments in `auth/user/change_password.html
 template`.

 I will propose a new patch that only set the `required_css_class` in this
 latter case.

 The fact that `required_css_class` is not set by default on forms might be
 the subject of another ticket...

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19055: DateField uses date() which might not be correct in timezone aware situations

[Django]

#19055: DateField uses date() which might not be correct in timezone aware
situations
---+--
 Reporter:  mitar  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  1.4
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by mitar):

 I think about this lines:
  *
 [https://github.com/django/django/blob/master/django/forms/fields.py#L366
 timezone information is lost]

 Otherwise, such [https://github.com/mitar/django-
 missing/blob/master/missing/timezone.py function] used everywhere instead
 of `.date()` call would not really break backwards compatibility, I
 believe.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #19064: select_related doesn't work for reverse one-to-one with inheritance

[Django]

#19064: select_related doesn't work for reverse one-to-one with inheritance
-+-
 Reporter:  zimnyx   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by zimnyx):

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


Comment:

 Patch from #13781 fixes this issue.

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

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

[Django] #19064: select_related doesn't work for reverse one-to-one with inheritance

[Django]

#19064: select_related doesn't work for reverse one-to-one with inheritance
--+
 Reporter:  zimnyx|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 == Docs say... ==
 You can also refer to the reverse direction of a !OneToOneField in the
 list of fields passed to select_related — that is, you can traverse a
 !OneToOneField back to the object on which the field is defined. Instead
 of specifying the field name, use the related_name for the field on the
 related object.


 == How to reproduce ==

 {{{
 # myapp/models.py
 class Dam(models.Model):
 name = models.CharField(max_length=32)

 class Animal(models.Model):
 nickname = models.CharField(max_length=32)

 class Beaver(Animal):
 dam = models.OneToOneField(Dam, related_name='beaver')
 favourite_meal = models.CharField(max_length=32)

 }}}


 {{{
 # myapp/fixtures/initial_data.yaml

 - model: myapp.Dam
   pk: 1
   fields:
 name: Hoover

 - model: myapp.Animal
   pk: 1
   fields:
 nickname: Harold

 - model: myapp.Beaver
   pk: 1
   fields:
 dam: 1
 favourite_meal: spagetti

 }}}


 {{{
 # /tmp/mypro$ python2.7 manage.py shell

 In [1]: from mypro.myapp.models import *

 In [2]: Beaver.objects.select_related('dam')
 Out[2]: []

 In [3]: Dam.objects.select_related('beaver')
 Out[3]: []

 In [4]: len(Dam.objects.select_related('beaver'))
 ERROR: An unexpected error occurred while tokenizing input
 The following traceback may be corrupted or invalid
 The error message is: ('EOF in multi-line statement', (494, 0))

 ---
 AttributeErrorTraceback (most recent call
 last)
 /tmp/mypro/django/core/management/commands/shell.pyc in ()
 > 1 len(Dam.objects.select_related('beaver'))

 /tmp/mypro/django/db/models/query.pyc in __len__(self)
  87 self._result_cache = list(self._iter)
  88 else:
 ---> 89 self._result_cache = list(self.iterator())
  90 elif self._iter:
  91 self._result_cache.extend(self._iter)

 /tmp/mypro/django/db/models/query.pyc in iterator(self)
 298 if fill_cache:
 299 obj, _ = get_cached_row(row, index_start, db,
 klass_info,
 --> 300
 offset=len(aggregate_select))
 301 else:
 302 # Omit aggregates in object creation.


 /tmp/mypro/django/db/models/query.pyc in get_cached_row(row, index_start,
 using, klass_info, offset)
1457 for rel_field, rel_model in
 rel_obj._meta.get_fields_with_model():
1458 if rel_model is not None:
 -> 1459 setattr(rel_obj, rel_field.attname,
 getattr(obj, rel_field.attname))
1460 # populate the field cache for any related
 object

1461 # that has already been retrieved


 AttributeError: 'Dam' object has no attribute 'nickname'
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #19063: gml(version=3) does not work for PostGIS

[Django]

#19063: gml(version=3) does not work for PostGIS
+-
 Reporter:  lmisek@…|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  GIS |Version:  master
 Severity:  Normal  |   Keywords:  postgis gml
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+-
 using function {{{gml()}}} with {{{version=3}}} does not work for PostGIS.
 Instead {{{version=2}}} is always used.

 The problem is in /trunk/django/contrib/gis/db/models/query.py
 {{{def gml(self, precision=8, version=2, **kwargs):}}}

 parameter {{{procedure_fmt}}} is correctly prepared but not passed to
 {{{_spatial_attribute}}} function

 It seems that
 {{{s['procedure_fmt'] = procedure_fmt}}}
 is missing

-- 
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 https://groups.google.com/groups/opt_out.