Re: [Django] #21323: Allow migrations.Operation to control their output.

2013-11-26 Thread Django 
#21323: Allow migrations.Operation to control their output.
--+
 Reporter:  loic84|Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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
--+

Comment (by loic84):

 I've cleaned up the code a bit by introducing a `MigrationFormatter`
 class, but ultimately there isn't so much we can do; presentational logic
 in Python is quite verbose. Also the way the serializer is implemented
 requires formatting as we go, fixing that would require a significant
 refactor.

 If we move to a better template system with white spaces handling
 (Jinja2), `CreateModel.serialize()` could be shrunk significantly.

 IMO being able to review the output of `CreateModel` is sufficiently
 critical to justify an imperfect `CreateModel.serialize()` method.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.67eb62ec5fcfa17ae328b09266e1f066%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21483: [RFE] Add WSGI environ to request_started signal emission

2013-11-26 Thread Django 
#21483: [RFE] Add WSGI environ to request_started signal emission
--+-
 Reporter:  jag@… |Owner:  anonymous
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-

Comment (by aaugustin):

 I'm wondering if whatever you're planning to do in the signal receiver
 wouldn't be better implemented in a middleware.

 But maybe that's just my phobia of signals :)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.7ae65c87a12d9de0c8f8d6572917%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21483: [RFE] Add WSGI environ to request_started signal emission

2013-11-26 Thread Django 
#21483: [RFE] Add WSGI environ to request_started signal emission
--+-
 Reporter:  jag@… |Owner:  anonymous
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-

Comment (by Joshua "jag" Ginsberg ):

 PR amended with suggestions. Thanks!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.cdf89bf5e2f3162fdb3eaaa4cffe65ae%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18855: persist a socket across reloads of the dev server

2013-11-26 Thread Django 
#18855: persist a socket across reloads of the dev server
-+-
 Reporter:  dlamotte |Owner:  dlamotte
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by unaizalakain):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


Comment:

 LGTM

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.953a52b9d193e089556273bbd4856cc0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21477: Rename pre/post_migrate argument db to using

2013-11-26 Thread Django 
#21477: Rename pre/post_migrate argument db to using
--+
 Reporter:  akaariai  |Owner:  syphar
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  master
 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 loic84):

 The `DeprecationWarning` is hardcoded, so if we move `DeprecatedSignal`
 with the goal of making it generic it should probably take the warning
 level as an `__init__` 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7da57816a3477696f36241f8290cb612%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21323: Allow migrations.Operation to control their output.

2013-11-26 Thread Django 
#21323: Allow migrations.Operation to control their output.
--+
 Reporter:  loic84|Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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
--+

Comment (by andrewgodwin):

 Me and loic84 discussed this on IRC a while back; I'm not a fan of how
 this currently looks (it makes the operations very hard to read and is
 confusing logic with presentation in a way) but it's a nice idea in
 principle.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.786e52f69657beaae7704aefe74b3c90%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21142: Cannot run migrations that reference django.contrib.auth.models.User

2013-11-26 Thread Django 
#21142: Cannot run migrations that reference django.contrib.auth.models.User
-+
 Reporter:  mario.pfeifer@…  |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  Migration, Auth  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by andrewgodwin):

 Yes, sorry, you probably hit a part of the dependency resolution that was
 failing. It's supposed to depend on __first__, which if the application
 doesn't have migrations is ignored - I'll make sure it's doing 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/082.2f5e1970d6cd33e17a6425506d6a95ca%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21498: Unnecessary migrations after nonrelevat fields changed

2013-11-26 Thread Django 
#21498: Unnecessary migrations after nonrelevat fields changed
+
 Reporter:  foonicorn   |Owner:  MarkusH
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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 MarkusH):

 I think we should find a solution for this: imaging your translators
 change the translation for a help text. All the time they do one developer
 will end up with such a new migration.

 The way I implemented it allows fields to redefine their attributes. It's
 a prove of concept: https://github.com/Markush2010/django/tree/ticket21498

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.3e7e697bd0b1638234dc107c4c03a0e3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21498: Unnecessary migrations after nonrelevat fields changed

2013-11-26 Thread Django 
#21498: Unnecessary migrations after nonrelevat fields changed
+
 Reporter:  foonicorn   |Owner:  MarkusH
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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 loic84):

 +1, I'm particularly concerned by the fate of `validators` which were
 blacklisted in the tentative patch presented on IRC.

 Also with the upcoming `VirtualField` we will be blurring the lines more
 and more between the ORM and the underlying schema.

 However there seems to be an valid issue here, i18n locale shouldn't trip
 the autodetector, I haven't had time to look into it but I suspect this is
 due to the fix for #21008.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.96868dc55fccd333fc83da15bd5f243c%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21438: Migrations do not detect many to many fields

2013-11-26 Thread Django 
#21438: Migrations do not detect many to many fields
-+-
 Reporter:  zaharid@…|Owner:
 Type:  Bug  |  andrewgodwin
Component:  Migrations   |   Status:  assigned
 Severity:  Normal   |  Version:  master
 Keywords:  manytomany   |   Resolution:
  foreignkey | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by andrewgodwin):

 * owner:   => andrewgodwin
 * status:  new => assigned


Comment:

 Probably an oversight on my part. I'll look into 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.48615a15cbf23f3f7e69c51c35378a84%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21477: Rename pre/post_migrate argument db to using

2013-11-26 Thread Django 
#21477: Rename pre/post_migrate argument db to using
--+
 Reporter:  akaariai  |Owner:  syphar
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  master
 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 andrewgodwin):

 I like this approach - we get a DeprecationWarning for the old signals out
 of it too, which is a bonus.

 I vote +1 on moving DeprecatedSignal somewhere more general (deprecation
 is probably good, or possibly django.dispatch). Docs look good apart from
 one small typo that I noted on the PR.

 Fix those and make the PR mergeable and I'll pull it in.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.568e523f594c318a0c32da62d489fe75%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 455e28: Fixed #21499 -- Added a paragraph to the docs.

2013-11-26 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 455e2896b122a331057483634bea9c8074bdc97d
  
https://github.com/django/django/commit/455e2896b122a331057483634bea9c8074bdc97d
  Author: Raphael Jasjukaitis 
  Date:   2013-11-24 (Sun, 24 Nov 2013)

  Changed paths:
M docs/topics/migrations.txt

  Log Message:
  ---
  Fixed #21499 -- Added a paragraph to the docs.


  Commit: 0c46ca83e820cd725f5d0fa299c2b5405bfeee1b
  
https://github.com/django/django/commit/0c46ca83e820cd725f5d0fa299c2b5405bfeee1b
  Author: Andrew Godwin 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

  Changed paths:
M docs/topics/migrations.txt

  Log Message:
  ---
  Merge pull request #1985 from raphaa/21499

Fixed #21499 -- Migrations won't work if field signature changes


Compare: https://github.com/django/django/compare/ac17525039b1...0c46ca83e820

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/529505b16d56_44b7a59d5813947b%40hookshot-fe3-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21499: Migrations won't work if field signature changes

2013-11-26 Thread Django 
#21499: Migrations won't work if field signature changes
-+-
 Reporter:  MarkusH  |Owner:
 Type:   |  rjasjukaitis
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Raphael Jasjukaitis ):

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


Comment:

 In [changeset:"455e2896b122a331057483634bea9c8074bdc97d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="455e2896b122a331057483634bea9c8074bdc97d"
 Fixed #21499 -- Added a paragraph to the docs.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c446fcee490466ec2c83842cf5358cc2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21499: Migrations won't work if field signature changes

2013-11-26 Thread Django 
#21499: Migrations won't work if field signature changes
-+-
 Reporter:  MarkusH  |Owner:
 Type:   |  rjasjukaitis
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Andrew Godwin ):

 In [changeset:"0c46ca83e820cd725f5d0fa299c2b5405bfeee1b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0c46ca83e820cd725f5d0fa299c2b5405bfeee1b"
 Merge pull request #1985 from raphaa/21499

 Fixed #21499 -- Migrations won't work if field signature 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8dce5a3c6383bdee5c5aa71916d2a8a7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21498: Unnecessary migrations after nonrelevat fields changed

2013-11-26 Thread Django 
#21498: Unnecessary migrations after nonrelevat fields changed
+
 Reporter:  foonicorn   |Owner:  MarkusH
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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 andrewgodwin):

 I'd rather we included every single field - white/blacklisting fields is
 dangerous. What if a field subclass redefines help_text? What if it uses
 it to help populate ORM objects? I'd like to mark this WONTFIX.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1785e8001c4995ff44618152beb64f6a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ac1752: Replace use of dict.has_key with `key in dict`

2013-11-26 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ac17525039b127e8712c402d0b09ffa864c37ef5
  
https://github.com/django/django/commit/ac17525039b127e8712c402d0b09ffa864c37ef5
  Author: Alex Gaynor 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

  Changed paths:
M docs/_ext/djangodocs.py

  Log Message:
  ---
  Replace use of dict.has_key with `key in dict`



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/5295055b16c5c_30d3b3dd50150467%40hookshot-fe1-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21510: Admin change list search field is missing the "show all" link

2013-11-26 Thread Django 
#21510: Admin change list search field is missing the "show all" link
-+-
 Reporter:  moritz.pfeiffer@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  search field show| Triage Stage:  Accepted
  all missing link   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by claudep):

 * severity:  Normal => Release blocker


Comment:

 Blocker, as a regression in 1.6.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/086.4edab02ecadb83eddb116769e3d5d736%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] bb5ab9: Fixed a typo in the documentation

2013-11-26 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: bb5ab908cc8ab71ddb619daa72a9aa5081af5f8b
  
https://github.com/django/django/commit/bb5ab908cc8ab71ddb619daa72a9aa5081af5f8b
  Author: Alex Gaynor 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

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

  Log Message:
  ---
  Fixed a typo in the documentation



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/5294fb6588c75_5fada8dd4c1505f0%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 655b8b: [1.6.x] Fixed #21448 -- Fixed test client logout w...

2013-11-26 Thread GitHub 
  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 655b8bb10b3c00d6c96e357d085c20b397a2ffa0
  
https://github.com/django/django/commit/655b8bb10b3c00d6c96e357d085c20b397a2ffa0
  Author: Claude Paroz 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

  Changed paths:
M django/test/client.py
M docs/releases/1.6.1.txt
M tests/test_client/tests.py

  Log Message:
  ---
  [1.6.x] Fixed #21448 -- Fixed test client logout with cookie-based sessions

Thanks Gunnar Scherf for the report and the suggested patch.
Backport of 384816fcc from master.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/5294f9df22a0b_30cc120dd4c135621%40hookshot-fe1-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21448: Test Client logout does not work with cookie-based sessions

2013-11-26 Thread Django 
#21448: Test Client logout does not work with cookie-based sessions
-+-
 Reporter:  GunnarScherf |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.6
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  test client logout   | Triage Stage:  Ready for
  cookie session regression  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"655b8bb10b3c00d6c96e357d085c20b397a2ffa0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="655b8bb10b3c00d6c96e357d085c20b397a2ffa0"
 [1.6.x] Fixed #21448 -- Fixed test client logout with cookie-based
 sessions

 Thanks Gunnar Scherf for the report and the suggested patch.
 Backport of 384816fcc 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.dab45e09ee237fef91032968ce09e42a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 384816: Fixed #21448 -- Fixed test client logout with cook...

2013-11-26 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 384816fccb6dfc7fc40f8059811341ba3572d9ff
  
https://github.com/django/django/commit/384816fccb6dfc7fc40f8059811341ba3572d9ff
  Author: Claude Paroz 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

  Changed paths:
M django/test/client.py
M docs/releases/1.6.1.txt
M tests/test_client/tests.py

  Log Message:
  ---
  Fixed #21448 -- Fixed test client logout with cookie-based sessions

Thanks Gunnar Scherf for the report and the suggested patch.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/5294f989735af_313074dd581316d6%40hookshot-fe1-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21448: Test Client logout does not work with cookie-based sessions

2013-11-26 Thread Django 
#21448: Test Client logout does not work with cookie-based sessions
-+-
 Reporter:  GunnarScherf |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.6
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  test client logout   | Triage Stage:  Ready for
  cookie session regression  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"384816fccb6dfc7fc40f8059811341ba3572d9ff"]:
 {{{
 #!CommitTicketReference repository=""
 revision="384816fccb6dfc7fc40f8059811341ba3572d9ff"
 Fixed #21448 -- Fixed test client logout with cookie-based sessions

 Thanks Gunnar Scherf for the report and the suggested patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.4dadf8b1e4c531c46d6cf67daef32e6f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21516: Update the import path for the FormSet classes and factories in documentation.

2013-11-26 Thread Django 
#21516: Update the import path for the FormSet classes and factories in
documentation.
-+-
 Reporter:  loic84   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by loic84):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Someday/Maybe
 * needs_tests:   => 0
 * needs_docs:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.aedb12a53676f5ec414b2a299dab27ca%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21516: Update the import path for the FormSet classes and factories in documentation.

2013-11-26 Thread Django 
#21516: Update the import path for the FormSet classes and factories in
documentation.
--+
 Reporter:  loic84|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Since #21489, FormSet classes and factories are exposed directly on the
 `django.forms` package.

 Examples in the docs should be updated to reflect this change at some
 point. The docs update is delayed for a couple of releases to help people
 who misuse the dev docs with an earlier version of Django so they don't
 get confusing import errors.

 The original ticket (#21489) has a tentative patch and discussions
 relevant to this 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.71b9abf9c530a37b37301f9953d1ec1e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21231: Limiting the number of variables and files that a POST request can contain

2013-11-26 Thread Django 
#21231: Limiting the number of variables and files that a POST request can 
contain
---+--
 Reporter:  epandurski@…   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 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 tomchristie):

 I agree that this is something we should be considering.  Take the
 following...

 {{{
 import time
 from django.http import QueryDict
 content = ('a=1&' * 250).rstrip('&')
 d = QueryDict(content, encoding='utf-8');
 }}}

 That represents parsing a single valid 10MB URLEncoded POST request.  On
 my machine it consumes ~350MB and 100% CPU for ~30secs.
 There's no built-in configurable protection in either Apache or Nginx
 against that type of request without having also installed optional
 plugins, and I'd consider `max_client_body_size = 10m` to be a perfectly
 reasonable nginx setting.

 I'll defer to the core dev team on this, but request parsing really does
 seem to me to be the domain of the application to deal with, rather than
 the server.  For example, suppose you wanted the application to deal with
 JSON requests that can contain base64 encoded file fields, or some other
 content type that can contain a mix of file uploads and standard data -
 the server has no way of parsing and inspecting if the requests are
 malicious or not.  As a further example - would we expect the server to be
 responsible for parsing and validating against malicious XML payloads and
 other content types that the application might parse?

 FWIW, I believe that PHP includes
 [http://stackoverflow.com/questions/8710185/new-limit-within-php-1000
 -fields-per-post-does-someone-know-if-the-number-can built-in protection]
 against this type of request, I've not managed to find information about
 other languages/frameworks.

 The simplest option would prob. be similar to the
 `FORM_DATA_MAX_FIELDS_TOTAL_LENGTH` already noted, but perhaps tweak the
 semantics slightly so that it's simply a setting specifying the maximum
 allowable request size *excluding* any file upload parts
 `REQUEST_MAX_DATA_SIZE` or similar.  That'd allow the developer to
 differentiate between the maximum allowable file upload size per-request,
 and the maximum allowable in-memory data structures per-request.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/078.e784dae4a7e1e82520d50c90418a3874%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21355: Try importing _imaging from PIL namespace first.

2013-11-26 Thread Django 
#21355: Try importing _imaging from PIL namespace first.
-+
 Reporter:  richardxia   |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.6
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  pil pillow   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Anssi Kääriäinen ):

 In [changeset:"6cd5c67b694b3469817e38d02f79ddef7c2a7132"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6cd5c67b694b3469817e38d02f79ddef7c2a7132"
 [1.6.x] Fixed #21355 -- try importing _imaging from PIL namespace first.

 Backport of 5725236c3e 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.19fb313b0e02541a736fd415a56bafbd%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 6cd5c6: [1.6.x] Fixed #21355 -- try importing _imaging fro...

2013-11-26 Thread GitHub 
  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 6cd5c67b694b3469817e38d02f79ddef7c2a7132
  
https://github.com/django/django/commit/6cd5c67b694b3469817e38d02f79ddef7c2a7132
  Author: Richard Xia 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

  Changed paths:
M django/utils/image.py

  Log Message:
  ---
  [1.6.x] Fixed #21355 -- try importing _imaging from PIL namespace first.

Backport of 5725236c3e from master



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/5294d4c5c025e_66e1ba1d50690df%40hookshot-fe5-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21355: Try importing _imaging from PIL namespace first.

2013-11-26 Thread Django 
#21355: Try importing _imaging from PIL namespace first.
-+
 Reporter:  richardxia   |Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.6
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  pil pillow   | 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"5725236c3ee4323203aa681cb54d1ff1d7f376df"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5725236c3ee4323203aa681cb54d1ff1d7f376df"
 Fixed #21355 -- try importing _imaging from PIL namespace first.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.82a88484a1e53938f29b41cb800294bd%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 572523: Fixed #21355 -- try importing _imaging from PIL na...

2013-11-26 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5725236c3ee4323203aa681cb54d1ff1d7f376df
  
https://github.com/django/django/commit/5725236c3ee4323203aa681cb54d1ff1d7f376df
  Author: Richard Xia 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

  Changed paths:
M django/utils/image.py

  Log Message:
  ---
  Fixed #21355 -- try importing _imaging from PIL namespace first.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/5294d3f212bff_215de9dd4c12388f%40hookshot-fe4-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20495: add login failure events to django.security logger

2013-11-26 Thread Django 
#20495: add login failure events to django.security logger
--+
 Reporter:  ptone |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  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
--+

Comment (by unaizalakain):

 Instead of:

 {{{
 if 'username' not in credentials:
 credentials['username'] = None
 }}}

 You could use:

 {{{
 credentials.setdefault('username', None)
 }}}

 The `patch_logger` function's docstring need to be updated because of the
 new `formatstr` argument.

 The `versionadded`s should also be updated to 1.7 (1.6 is feature frozen)
 and the one in `django.security.*` section should be placed above the
 update.

 If you have the opportunity, create a PR in github (it makes it easier to
 comment).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.6618e8ef5fbcc6a7a7cad164514d2539%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21515: template.Context Documentation: c.pop() and c.push() return nothing in the example

2013-11-26 Thread Django 
#21515: template.Context Documentation: c.pop() and c.push() return nothing in 
the
example
---+
 Reporter:  oubiga |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.6
 Severity:  Normal |   Keywords:  context, pop, push
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 
https://docs.djangoproject.com/en/1.6/ref/templates/api/#django.template.Context.pop
 shows:


 {{{
 >>> c = Context()
 >>> c['foo'] = 'first level'
 >>> c.push()
 >>> c['foo'] = 'second level'
 >>> c['foo']
 'second level'
 >>> c.pop()
 >>> c['foo']
 'first level'
 }}}


 Is my suggestion more understandable?


 {{{
 >>> c = Context()
 >>> c['foo'] = 'first level'
 >>> c.push()
 {}
 >>> c['foo'] = 'second level'
 >>> c['foo']
 'second level'
 >>> c.pop()
 {'foo': 'second level'}
 >>> c['foo']
 'first level'
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.566da21ab9cf09e8d3566b2b6d228e66%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21514: Session expiry dates should be in an ISO string instead of datetime

2013-11-26 Thread Django 
#21514: Session expiry dates should be in an ISO string instead of datetime
--+--
 Reporter:  n142857@… |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.6
 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 timo):

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


Comment:

 Where is the code that calls `set_expiry()` with a datetime? My guess is
 that it's somewhere in your own project or a third party module, not in
 Django itself. See also the documentation for
 
[https://docs.djangoproject.com/en/dev/topics/http/sessions/#django.contrib.sessions.backends.base.SessionBase.set_expiry
 set_expiry()].

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.e6d91ec4ce915d0976798cf6b839de19%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13165: Display edit link beside add button for ForeignKey fields in admin

2013-11-26 Thread Django 
#13165: Display edit link beside add button for ForeignKey fields in admin
-+-
 Reporter:  DrMeers  |Owner:  charettes
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin foreign key| Triage Stage:  Accepted
  edit link  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by danielsamuels):

 * cc: danielsamuels (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.17ce2633841538ae7dbb0333c5ed9b76%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21514: Session expiry dates should be in an ISO string instead of datetime

2013-11-26 Thread Django 
#21514: Session expiry dates should be in an ISO string instead of datetime
--+
 Reporter:  n142857@… |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.sessions  |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The documentation for Django 1.6 says
 (https://docs.djangoproject.com/en/dev/topics/http/sessions/):

 Note that datetime and timedelta values are only serializable if you
 are using the PickleSerializer.

 And that's true. For instance, using django-social-auth I got this session
 data:

 {'facebook_state': 'zyuqNJsGiXBPubpnwV7Lgh5pqbkKiqk5',
 'social_auth_last_login_backend': u'facebook', '_auth_user_id': 4,
 '_auth_user_backend': 'social_auth.backends.facebook.FacebookBackend',
 '_session_expiry': datetime.datetime(2013, 11, 18, 9, 21, 20, 75255,
 tzinfo=)}.

 Which will give this error on login when using JSONSerializer:

datetime.datetime(2013, 11, 18, 9, 21, 20, 75255, tzinfo=) is not
 JSON serializable

 Django ships now with JSONSerializer enabled, but Django is still actively
 putting datetimes in sessions, concretely in
 django/contrib/sessions/backends/base.py:251. Since it's not a Django
 extension which is incompatible with the default behaviour, but Django
 itself, I think it's Django which must be fixed.

 A solution is to serialize the datetime to ISO 8601 before storing it in
 the session.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.65297eace9842912781464a3f9f5e172%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 9d6c48: Use str.isupper() to test if a string is uppercase...

2013-11-26 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9d6c48aeb02320fd33b4314928c4a3bcfc49f667
  
https://github.com/django/django/commit/9d6c48aeb02320fd33b4314928c4a3bcfc49f667
  Author: Baptiste Mispelon 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

  Changed paths:
M django/conf/__init__.py

  Log Message:
  ---
  Use str.isupper() to test if a string is uppercased.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/52949df54c03b_214d12fdd4c27764%40hookshot-fe4-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21513: method_decorator doesn't work with argumented Class-Based Decorator

2013-11-26 Thread Django 
#21513: method_decorator doesn't work with argumented Class-Based Decorator
-+-
 Reporter:  dpwrussell   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Utilities|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  decorator,   | Triage Stage:
  functools, CBV, method_decorator   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by dpwrussell):

 PR with these changes: https://github.com/django/django/pull/1997

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.cabac530e72c997b9e211f928670a48b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21513: method_decorator doesn't work with argumented Class-Based Decorator

2013-11-26 Thread Django 
#21513: method_decorator doesn't work with argumented Class-Based Decorator
-+-
 Reporter:  dpwrussell   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Utilities|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  decorator,   | Triage Stage:
  functools, CBV, method_decorator   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by dpwrussell):

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


Comment:

 FYI It seems the https://code.djangoproject.com/ticket/13879 was going
 down a route of adding an method_decorator_with_args decorator and I
 wanted to differentiate from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.001971dd1e0e946d9b7d279383241823%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21513: method_decorator doesn't work with argumented Class-Based Decorator

2013-11-26 Thread Django 
#21513: method_decorator doesn't work with argumented Class-Based Decorator
-+-
 Reporter:   |  Owner:  nobody
  dpwrussell | Status:  new
 Type:   |Version:  1.6
  Uncategorized  |   Keywords:  decorator, functools, CBV,
Component:   |  method_decorator
  Utilities  |  Has patch:  0
 Severity:  Normal   |  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 https://code.djangoproject.com/ticket/13093 was a similar example of this.
 decorator_from_middleware has been adapted to use available_attrs. The
 same treatment is needed in method_decorator:

 method_decorator blindly attempts to access attributes which are not
 present on an object, only on a class. This causes method_decorator to
 fail completely if it is used on any decorator used like this (with or
 without actual arguments):

 {{{
 class MyDecorator(object):
 def __init__(self, extra):
 self.extra = extra

 def __call__(self, f):

 def wrapped(a,b):
 return f(a,b) + self.extra
 return update_wrapper(wrapped, f)

 class C(object):
 def __init__(self):
 @method_decorator(MyDecorator(5))
 def addStuff(self, a, b):
 return a+b

 c = C()
 print(c.addStuff(1,2)) # Should return 1+2+5=8
 }}}

 Something like this would be a fix, although I'm not really familiar
 enough with the nuances to know for 100% if this will work in all cases.
 Seems to be ok though:


 {{{
 from functools import update_wrapper
 from django.utils.decorators import available_attrs, WRAPPER_ASSIGNMENTS


 def method_decorator(decorator):
 """
 Converts a function decorator into a method decorator
 """
 # 'func' is a function at the time it is passed to _dec, but will
 eventually
 # be a method of the class it is defined it.
 def _dec(func):
 def _wrapper(self, *args, **kwargs):
 @decorator
 def bound_func(*args2, **kwargs2):
 return func(self, *args2, **kwargs2)
 # bound_func has the signature that 'decorator' expects i.e.
 no
 # 'self' argument, but it is a closure over self so it can
 call
 # 'func' correctly.
 return bound_func(*args, **kwargs)
 # In case 'decorator' adds attributes to the function it
 decorates, we
 # want to copy those. We don't have access to bound_func in this
 scope,
 # but we can cheat by using it on a dummy function.

 @decorator
 def dummy(*args, **kwargs):
 pass
 update_wrapper(_wrapper, dummy)

 # Need to preserve any existing attributes of 'func', including
 the name.

 update_wrapper(_wrapper, func)

 return _wrapper

 update_wrapper(_dec, decorator, assigned=available_attrs(decorator))
 # Change the name to aid debugging.
 if hasattr(decorator, '__name__'):
 _dec.__name__ = 'method_decorator(%s)' % decorator.__name__
 else:
 _dec.__name__ = 'method_decorator(%s)' %
 decorator.__class__.__name__
 return _dec
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.00a2f7922a0518ab51506f1b0dcbd188%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15053: Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion

2013-11-26 Thread Django 
#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  unaizalakain
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  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
-+

Comment (by unaizalakain):

 Before opening the PR we need to document and test all the loader related
 functions that we had changed exhaustively. I'll do it before this
 weekend.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8d792207435418e5cea71f814e9d41df%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21489: Expose FormSet on the django.forms package.

2013-11-26 Thread Django 
#21489: Expose FormSet on the django.forms package.
-+-
 Reporter:  loic84   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Forms|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

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


Comment:

 Fixed in 1c7a83ee8e3da431d9d21dae42da8f1f89973f7c.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.7ab7eb8f3f816d05d88bdd2766b737e4%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21510: Admin change list search field is missing the "show all" link

2013-11-26 Thread Django 
#21510: Admin change list search field is missing the "show all" link
-+-
 Reporter:  moritz.pfeiffer@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  search field show| Triage Stage:  Accepted
  all missing link   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by bmispelon):

 Looks like the problem was introduced by commit
 f07a5f0a21857204465019b4e68f914d31cb396a (found with `git bisect`).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/086.d8b31970250474e2f0d752c45c4a0528%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21510: Admin change list search field is missing the "show all" link

2013-11-26 Thread Django 
#21510: Admin change list search field is missing the "show all" link
-+-
 Reporter:  moritz.pfeiffer@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  search field show| Triage Stage:  Accepted
  all missing link   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by bmispelon):

 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 I can indeed reproduce the issue you're describing.

 From what I can tell, this removal wasn't intentional since the code in
 `django/contrib/admin/templates/admin/search_form.html` was basically
 untouched between 1.5 and 1.6 [1]

 [1]
 
https://github.com/django/django/commits/master/django/contrib/admin/templates/admin/search_form.html

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/086.edc36c7a60301f6ffedb437e05f93ab7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21512: Test of model_fields and model_forms gives incomplete information about Pillow/PIL situation

2013-11-26 Thread Django 
#21512: Test of model_fields and model_forms gives incomplete information about
Pillow/PIL situation
--+
 Reporter:  vajrasky  |Owner:  vajrasky
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Uncategorized |  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:  1 |UI/UX:  0
--+
Changes (by Baptiste Mispelon ):

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


Comment:

 In [changeset:"16d73d7416a7902703ee8022f093667f7ac9ef5b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="16d73d7416a7902703ee8022f093667f7ac9ef5b"
 Fixed #21512 -- Added more complete information about Pillow and PIL in
 model_fields and model_forms tests.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.4bc939389006b9ea86dda0afd5c46896%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 16d73d: Fixed #21512 -- Added more complete information ab...

2013-11-26 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 16d73d7416a7902703ee8022f093667f7ac9ef5b
  
https://github.com/django/django/commit/16d73d7416a7902703ee8022f093667f7ac9ef5b
  Author: Vajrasky Kok 
  Date:   2013-11-26 (Tue, 26 Nov 2013)

  Changed paths:
M tests/model_fields/test_imagefield.py
M tests/model_forms/tests.py

  Log Message:
  ---
  Fixed #21512 -- Added more complete information about Pillow and PIL in 
model_fields and model_forms tests.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/529467dfe824b_343cf35d541545a%40hookshot-fe1-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15053: Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion

2013-11-26 Thread Django 
#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  unaizalakain
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  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
-+

Comment (by pmartin):

 Replying to [comment:29 unaizalakain]:
 > Sorry for the delay, suggestions noted at the PR ;)

 Me too. This saturday I will update this PR. I really would like if we
 could to do a PR to django soon.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.4d6bfc6387304717fad45a555b7fb2c9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14051: Signals for transaction commit/rollback

2013-11-26 Thread Django 
#14051: Signals for transaction commit/rollback
-+-
 Reporter:  Ask Solem |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 kux, I won't include in Django partial features that vaguely cover some
 needs of some users. I either do things correctly or not at all.

 Transactions guarantee a very high level of reliability, enforced by the
 database. I refuse to mix them with a less reliable system that could
 leave data in an inconsistent state — especially signals, which are the
 most misused feature of Django.

 Your use case is easily implemented by adding cleanup tasks to a
 request.cleanup_on_errors list, and running them with a middleware in
 process_exception when ATOMIC_REQUESTS triggers a rollback. Besides, this
 allows you to register specific tasks rather than having to write and
 register a global signal handler that can cleanup anything left behind by
 any part of your 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/091.5a668f601c5be89cc57895b23998f4fb%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21508: ForeignKey cast to int despite being varchar

2013-11-26 Thread Django 
#21508: ForeignKey cast to int despite being varchar
-+-
 Reporter:  fiomtec@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (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
-+-

Comment (by fiomtec@…):

 Ok, I've been doing a bit more testing. It seems that it doesn't have to
 do with the column being a ForeignKey, but with the db column being a
 foreign key. I've redefined my model like this:


 {{{
 class Confirmacion(models.Model):
 cliente = models.CharField(db_column='entidad_propietaria',
 max_length=8)
 fecha_orden = models.CharField(max_length=8)
 [...]other fields[...]
 }}}

 When I query some objects, fecha_orden will always be a string (despite it
 being a date in the form MMDD), but cliente will be a string if it's
 something like 'MADRID', but an integer if it can be converted.

 Both columns are defined as varchar(8) not null in the database, the only
 difference is that entidad_propietaria is a foreign key to another table,
 and fecha_orden isn't.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.ae1a8ffa063f3a4b3b1ae28b29ef55d2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.