date:20131003

[Django] #21219: The FILE_UPLOAD_PERMISSIONS should not be used when deploying static files

2013-10-03 Thread Django

#21219: The FILE_UPLOAD_PERMISSIONS should not be used when deploying static 
files
--+
 Reporter:  dblack+django@…   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  File uploads/storage  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The FILE_UPLOAD_PERMISSIONS permission is used in the
 django.contrib.staticfiles.storage.staticfiles_storage backend *and* it
 really shouldn't be. The use of the FILE_UPLOAD_PERMISSIONS permission to
 govern the deployed permission of static files is not documented so it
 should be possible to make a new STATIC_FILE_PERMISSIONS setting which is
 used instead of FILE_UPLOAD_PERMISSIONS during collectstatic :-)

-- 
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.9b60c658f9f386bf146af3fa07099a1c%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18984: TransactionTestCase._fixture_teardown locks under mysql

2013-10-03 Thread Django

#18984: TransactionTestCase._fixture_teardown locks under mysql
-+-
 Reporter:  jdunck   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 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 btimby):

 * cc: btimby@… (added)


Comment:

 I am getting the same condition when running a unit test that uses
 multiple threads. I have a server running in another thread, it is stopped
 in tearDown() yet in _fixture_teardown() during the flush, it hangs.

 show processlist:

 {{{
 | 126 | camden | localhost | test_camden | Sleep   |   69 |
 | NULL   |
 | 128 | camden | localhost | test_camden | Query   |2 | Waiting for
 table metadata lock | TRUNCATE `main_camera` |
 }}}

 I am using Django 1.5.4 and verified that the patch is present in the
 version I am running. At the time that rollback_unless_managed() is run,
 only the first sleeping connection is present, a new one is opened for the
 flush.

 I am not sure if this should be reopened or what other information is
 necessary to reopen this issue, so I will leave the status as-is and just
 provide the above comment for now.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.16310676957f241f8f6d8574fa71147a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #7936: Add Last-Modified header to feeds

2013-10-03 Thread Django

#7936: Add Last-Modified header to feeds
-+-
 Reporter:  julianb  |Owner:  Claude
 Type:  New feature  |  Paroz 
Component:  contrib.syndication  |   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:  syndication last-|   Resolution:  fixed
  modified   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ramiro Morales ):

 In [changeset:"5252885494079cf28a337644a87e61b19340f09c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5252885494079cf28a337644a87e61b19340f09c"
 [1.6.x] Fixed #21165 -- Fix test for syndication feed timestamp field on
 Windows.

 Thanks Michael Manfre for the report, Raphaël Barrois for the patch and
 Claude Paroz, Aymeric Augustin for the reviews.

 Refs #7936

 62dfd79f8b 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/065.8e7aea6120661d4c1368e7953b256635%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 525288: [1.6.x] Fixed #21165 -- Fix test for syndication f...

2013-10-03 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 5252885494079cf28a337644a87e61b19340f09c
  
https://github.com/django/django/commit/5252885494079cf28a337644a87e61b19340f09c
  Author: Ramiro Morales 
  Date:   2013-10-03 (Thu, 03 Oct 2013)

  Changed paths:
M tests/syndication/tests.py

  Log Message:
  ---
  [1.6.x] Fixed #21165 -- Fix test for syndication feed timestamp field on 
Windows.

Thanks Michael Manfre for the report, Raphaël Barrois for the patch and
Claude Paroz, Aymeric Augustin for the reviews.

Refs #7936

62dfd79f8b 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/524e229c7d667_792ed1bd481640bf%40hookshot-fe3-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21165: regressiontests.syndication.tests.SyndicationFeedTest.test_feed_last_modified_time fails on Windows with sqlite

2013-10-03 Thread Django

#21165: 
regressiontests.syndication.tests.SyndicationFeedTest.test_feed_last_modified_time
fails on Windows with sqlite
-+
 Reporter:  manfre   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.syndication  |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Ramiro Morales ):

 In [changeset:"5252885494079cf28a337644a87e61b19340f09c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5252885494079cf28a337644a87e61b19340f09c"
 [1.6.x] Fixed #21165 -- Fix test for syndication feed timestamp field on
 Windows.

 Thanks Michael Manfre for the report, Raphaël Barrois for the patch and
 Claude Paroz, Aymeric Augustin for the reviews.

 Refs #7936

 62dfd79f8b 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/064.d79c544bc27d437b23e67f3c54ac282f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21218: Word typo on Upgrading Django page

2013-10-03 Thread Django

#21218: Word typo on Upgrading Django page
--+
 Reporter:  ryan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"e2e7571035173ed153b38e91a3945a074ceada57"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2e7571035173ed153b38e91a3945a074ceada57"
 [1.6.x] Fixed #21218 -- Typo on docs/howto/upgrade-version.txt

 Thanks ryan at ryangallen.com for the report.

 Backport of 36e220f923 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/077.d8f57969de69d4ead7f2a9b279b5f1e5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 67d887: [1.5.x] Fixed #21218 -- Typo on docs/howto/upgrade...

2013-10-03 Thread GitHub

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 67d887fbae1204f86361aa77edf8104330432e5e
  
https://github.com/django/django/commit/67d887fbae1204f86361aa77edf8104330432e5e
  Author: Tim Graham 
  Date:   2013-10-03 (Thu, 03 Oct 2013)

  Changed paths:
M docs/howto/upgrade-version.txt

  Log Message:
  ---
  [1.5.x] Fixed #21218 -- Typo on docs/howto/upgrade-version.txt

Thanks ryan at ryangallen.com for the report.

Backport of 36e220f923 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/524e085810123_792ed1bd481541fb%40hookshot-fe3-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] e2e757: [1.6.x] Fixed #21218 -- Typo on docs/howto/upgrade...

2013-10-03 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: e2e7571035173ed153b38e91a3945a074ceada57
  
https://github.com/django/django/commit/e2e7571035173ed153b38e91a3945a074ceada57
  Author: Tim Graham 
  Date:   2013-10-03 (Thu, 03 Oct 2013)

  Changed paths:
M docs/howto/upgrade-version.txt

  Log Message:
  ---
  [1.6.x] Fixed #21218 -- Typo on docs/howto/upgrade-version.txt

Thanks ryan at ryangallen.com for the report.

Backport of 36e220f923 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/524e085645367_573d1219d542290a2%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21218: Word typo on Upgrading Django page

2013-10-03 Thread Django

#21218: Word typo on Upgrading Django page
--+
 Reporter:  ryan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"67d887fbae1204f86361aa77edf8104330432e5e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="67d887fbae1204f86361aa77edf8104330432e5e"
 [1.5.x] Fixed #21218 -- Typo on docs/howto/upgrade-version.txt

 Thanks ryan at ryangallen.com for the report.

 Backport of 36e220f923 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/077.d2c62e3271d2885efe92bf5e31e77ec3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21218: Word typo on Upgrading Django page

2013-10-03 Thread Django

#21218: Word typo on Upgrading Django page
--+
 Reporter:  ryan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"36e220f923e0c355c9b0388131f87fbfaf46ac5f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="36e220f923e0c355c9b0388131f87fbfaf46ac5f"
 Fixed #21218 -- Typo on docs/howto/upgrade-version.txt

 Thanks ryan at ryangallen.com 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 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/077.8d04021125444a376b5a62767bc46bd7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 36e220: Fixed #21218 -- Typo on docs/howto/upgrade-version...

2013-10-03 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 36e220f923e0c355c9b0388131f87fbfaf46ac5f
  
https://github.com/django/django/commit/36e220f923e0c355c9b0388131f87fbfaf46ac5f
  Author: Tim Graham 
  Date:   2013-10-03 (Thu, 03 Oct 2013)

  Changed paths:
M docs/howto/upgrade-version.txt

  Log Message:
  ---
  Fixed #21218 -- Typo on docs/howto/upgrade-version.txt

Thanks ryan at ryangallen.com for the report.



-- 
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/524e084044ab2_65bfa47d4c1520c1%40hookshot-fe1-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21218: Word typo on Upgrading Django page

2013-10-03 Thread Django

#21218: Word typo on Upgrading Django page
--+
 Reporter:  ryan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by EvilDMP):

 * cc: EvilDMP (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.5 => master
 * easy:  0 => 1
 * keywords:   => afraid-to-commit
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I've marked this ticket as especially suitable for first-time committers
 or people following the [http://dont-be-afraid-to-commit.readthedocs.org/
 Don't be afraid to commit] tutorial. If you're tackling this ticket,
 please don't hesitate to ask me for guidance if you'd like any, either
 here or on the Django IRC channels, where I can be found as ''EvilDMP''.

-- 
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/077.3d1a50ff760fbbd811c9bf49eeedd1bd%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21218: Word typo on Upgrading Django page

2013-10-03 Thread Django

#21218: Word typo on Upgrading Django page
--+
 Reporter:  ryan@…|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 https://docs.djangoproject.com/en/1.5/howto/upgrade-version/

 Currently says "...you might want to set up a new environment '''will'''
 all the dependencies 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/062.f47ad7948f6732ab4a7c14c1fa62f0cf%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20522: Admin formset validation cannot take submitted model instance into account when form not valid.

2013-10-03 Thread Django

#20522: Admin formset validation cannot take submitted model instance into 
account
when form not valid.
-+-
 Reporter:  meshy|Owner:  kamni
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin formset| Triage Stage:  Accepted
  validation |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by EvilDMP):

 kamni: I've merged your branch with recent updates to django master, at
 https://github.com/evildmp/django/tree/kamni-bug/20522; tests still pass.
 It may be worth merging those updates into your branch as it will make it
 easier for others to work with 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/063.6fe557aa06fcf6dea405ada00860eafb%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21213: Document how to subscribe to mailing lists without a Google account

2013-10-03 Thread Django

#21213: Document how to subscribe to mailing lists without a Google account
-+-
 Reporter:  unaizalakain |Owner:
 Type:   |  unaizalakain
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mailing list,| Triage Stage:  Accepted
  subscription, google   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by unaizalakain):

 What about making it link to the (future) mailing lists docs 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 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.39a622068e799e4da1773aa335b5e30e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 7a97df: Fixed #19277 -- Added LocaleMiddleware.response_re...

2013-10-03 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 7a97df190cb993056aa097befb3813100cfc286e
  
https://github.com/django/django/commit/7a97df190cb993056aa097befb3813100cfc286e
  Author: Emil Stenström 
  Date:   2013-10-03 (Thu, 03 Oct 2013)

  Changed paths:
M django/middleware/locale.py
M docs/ref/middleware.txt
M docs/releases/1.7.txt
M tests/i18n/patterns/tests.py

  Log Message:
  ---
  Fixed #19277 -- Added LocaleMiddleware.response_redirect_class

Thanks ppetrid at yawd.eu for the suggestion.



-- 
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/524dd328ea489_56b5e85d501705f1%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19277: LocaleMiddleware permanent redirects

2013-10-03 Thread Django

#19277: LocaleMiddleware permanent redirects
-+-
 Reporter:  ppetrid@…|Owner:  Tim
 Type:  New feature  |  Graham 
Component:   |   Status:  closed
  Internationalization   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

 * owner:   => Tim Graham 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"7a97df190cb993056aa097befb3813100cfc286e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7a97df190cb993056aa097befb3813100cfc286e"
 Fixed #19277 -- Added LocaleMiddleware.response_redirect_class

 Thanks ppetrid at yawd.eu for the suggestion.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/073.93231832dbdc34286d6a61591ccb49b6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21213: Document how to subscribe to mailing lists without a Google account

2013-10-03 Thread Django

#21213: Document how to subscribe to mailing lists without a Google account
-+-
 Reporter:  unaizalakain |Owner:
 Type:   |  unaizalakain
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mailing list,| Triage Stage:  Accepted
  subscription, google   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by timo):

 It's part of a separate repo: https://github.com/django/djangoproject.com

 I'm a bit hesitant to make that change though since I believe you need to
 be a member of the group in order to post, so it may be confusing to new
 users to click on that link only to have their message rejected.

-- 
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.6ae6a5d47b1e38927857542ea72d35fe%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21213: Document how to subscribe to mailing lists without a Google account

2013-10-03 Thread Django

Comment (by unaizalakain):

Working on it ;-)

BTW, I haven't found the way of changing the "Questions/Feedback" footer
of Django's documentation pages (maybe is it embedded?). The thing is that
pointing the "post a question" link directly to "mailto:django-
us...@googlegroups.com" would be the correct thing, now it is pointing to
the same place that the "archives of the django-users mailing" link does.

Any thought about how could I make this change happen?

--
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.ddb1cc875d8b0df1ca628d6bf56b4986%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20979: Serialize payload of model.FileField when using manage.py dumpdata

2013-10-03 Thread Django

#20979: Serialize payload of model.FileField when using manage.py dumpdata
-+-
 Reporter:  jrief|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  master
  uploads/storage|   Resolution:  wontfix
 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 timo):

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


Comment:

 Thanks for the suggestion. I don't think we should be promoting fixtures
 as a backup strategy though. Having this in a 3rd party package seems like
 a good fit though.

-- 
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.86edcf589aac27e37c099a773feecf6f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21217: `ImageField` and `GenericForeignKey` shouldn't connect `(pre|post)_init` signals to abstract senders

2013-10-03 Thread Django

#21217: `ImageField` and `GenericForeignKey` shouldn't connect `(pre|post)_init`
signals to abstract senders
-+-
Reporter: charettes | Owner: nobody
Type: | Status: new
Cleanup/optimization |Version: master
Component: Database | Keywords:
layer (models, ORM)| Has patch: 1
Severity: Normal |Needs tests: 0
Triage Stage: | Easy pickings: 0
Unreviewed |
Needs documentation: 0 |
Patch needs improvement: 0 |
UI/UX: 0 |
-+-
Since `(pre|post)_init` is only sent by non abstract models (actually it
is also sent when an abstract model is instantiated but one should not do
that anyway) we should avoid polluting the associated signals registries
with useless entries.

Attaching a patch with testcases making sure the changes didn't affect
`ImageField` and `GenericForeignKey` inherited from abstract bases. The
full test suite pass on Python 2.7 SQLite.

--
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/052.8aa7dba14d07114c96185f3a108cd12d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21182: Extra Column in Group By When Using date_trunc

2013-10-03 Thread Django

#21182: Extra Column in Group By When Using date_trunc
-+-
 Reporter:  anonymous|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
-+-
Changes (by timo):

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


Comment:

 I'm skeptical of your use of `date_trunc_sql` -- this isn't a public API
 that's designed for general use as far as I know.

 Assuming there is a bug in Django though, it would be helpful if you could
 include a test for Django's test suite so we can more easily reproduce the
 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 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.46615bf8328179e2f6e4d144ed90f875%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10554: Response.set_cookie should allow setting two cookies of the same name.

2013-10-03 Thread Django

#10554: Response.set_cookie should allow setting two cookies of the same name.
---+
 Reporter:  jdunck |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  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 unaizalakain):

 While a possible workaround could be to redefine SimpleCookie's method to
 check if some cookie exists, some structural issues would rise. What
 should we do if there're two cookies with the same name and
 SimpleCookie.get('cookie') is called?

 MorselKey's could be used to grab cookies from cookies dict but a lot of
 external code would change.

-- 
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.3e6789dc771fa3dde39634f15dc236cc%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21171: Skip transaction creation for single statement operations

2013-10-03 Thread Django

#21171: Skip transaction creation for single statement operations
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.5
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  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 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.3f11dbfae751d7f1c34e4d82b855c90e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21153: DataSource doesn't seem to work with 'OSM' type

2013-10-03 Thread Django

#21153: DataSource doesn't seem to work with 'OSM' type
---+--
 Reporter:  philipn|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  GIS|  Version:  1.5
 Severity:  Normal |   Resolution:  worksforme
 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):

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


-- 
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.c038f70fefec501e8d0b60253635351b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10554: Response.set_cookie should allow setting two cookies of the same name.

2013-10-03 Thread Django

#10554: Response.set_cookie should allow setting two cookies of the same name.
---+
 Reporter:  jdunck |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  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 unaizalakain):

 I have been fooling around with this little fix and one problem arises
 from the proposed solution: While the custom hash method prevents dict
 collisions, it also prevents from checking if some cookie already exists
 (as done by many contrib apps).

-- 
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.a74899b873c85d0258c3cdaf741f5931%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21156: Inline model admin does not respect model field default values.

2013-10-03 Thread Django

#21156: Inline model admin does not respect model field default values.
---+--
Reporter: tom.vaughan@… |Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.5
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:

Do you have a proposal for how to address this? It seems to be like it
would be prohibitively difficult to address in a general fashion as it
would require doing something like detecting that the default value should
be dynamically generated and then providing an API that could be used to
fetch new values when clicking "Add Another". I think you are better off
customizing the admin yourself if you need this functionality.

--
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/079.89e64677652c2d37ae578c0726751f42%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9682: icontains can be case-sensitive on MySQL

2013-10-03 Thread Django

#9682: icontains can be case-sensitive on MySQL
-+-
 Reporter:   |Owner:  nobody
  to.roma.from.djbug@…   |   Status:  new
 Type:  Bug  |  Version:  1.0
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Same here: MySQL+utf8_bin. I spent an hour to find out that it is a bug in
 Django...

-- 
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/088.d3dabe885b81fef67bfee487afdec272%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21158: Set an implicit wait for selenium.

2013-10-03 Thread Django

#21158: Set an implicit wait for selenium.
--+
 Reporter:  apollo13  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  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
--+
Changes (by timo):

 * 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 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.5edab44bca3c60546d0125a98de97d49%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21211: DEFAULT_DB_ALIAS in settings

2013-10-03 Thread Django

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

Comment:

I haven't used multi-db extensively so I may be off, but the
[https://docs.djangoproject.com/en/dev/topics/db/multi-db/ multi DB docs]
say: "Django requires that a default database entry be defined, but the
parameters dictionary can be left blank if it will not be used." Why not
use this approach and have each of your databases explicitly defined? You
could have 'default' point to nothing or whatever database each machine is
using as the "primary" if that makes sense.

In any case, the barrier to adding new settings in Django is high and I'm
pretty skeptical of this change meeting that criteria. You'll need to
write to the django-developers and explain your rationale. As an aside,
have you tried making the changes in Django for this? I can't say for
sure, but I feel like there will probably be unexpected issues.

--
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.b728f8b169b2130c5ec45da047ce3c87%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21178: Site.objects.get_current() causes circular import while executing collectstatic

2013-10-03 Thread Django

#21178: Site.objects.get_current() causes circular import while executing
collectstatic
-+-
 Reporter:  james@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  1.5
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  site, circular   | Triage Stage:
  reference, circular import |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

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


-- 
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/074.07ae083aa4a08f9bb76d7175e1c6bce1%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20971: Annotating a count of distinct ForeignKey (a) of a reverse foreignkey (b) doesn't work on oracle if (a) has any TextFields

2013-10-03 Thread Django

#20971: Annotating a count of distinct ForeignKey (a) of a reverse foreignkey 
(b)
doesn't work on oracle if (a) has any TextFields
-+-
 Reporter:  kimvais@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timo):

 * 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 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/073.c48732ddda31537985875d066cb179be%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19321: Add django.contrib.redirects setting for redirect status.

2013-10-03 Thread Django

#19321: Add django.contrib.redirects setting for redirect status.
-+-
 Reporter:  Melevir  |Owner:  Melevir
 Type:  New feature  |   Status:  new
Component:  contrib.redirects|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  redirects,   | Triage Stage:  Accepted
  status_code|  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timo):

 * needs_docs:  0 => 1


Comment:

 I think we might as well document these attributes and also include a
 mention in the release notes.

-- 
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.9bfdf40d35ae2e154ba8bc712e82c996%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10554: Response.set_cookie should allow setting two cookies of the same name.

2013-10-03 Thread Django

#10554: Response.set_cookie should allow setting two cookies of the same name.
---+
 Reporter:  jdunck |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  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 jdunck):

 I believe so, yes.  Jacob accepted this ticket; there's been no debate on
 my suggested fix.  I am now a core committer and feel this is a decent way
 to fix the problem.

 I would point out that in the years since I wrote these notes, the
 versions of both django and supported python versions have changed - it's
 possible there's a better way now, though I don't have time to dig into it
 at the moment.

 Thanks for your interest. :)

-- 
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.2259cff7ae62b82c3928d6b6bc098429%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16187: Refactor lookup system

2013-10-03 Thread Django

#16187: Refactor lookup system
-+-
 Reporter:  UloPe|Owner:  akaariai
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by mjtamlyn):

 Anssi - I'd like to review this as and when you're ready, but I'm not
 particularly familiar with how things worked before. I feel it would be a
 good exercise for me getting to know the ORM a bit more, as well as
 hopefully a useful fresh set of eyes. It's not a small patch, so any
 guidance you can give as to where to start would be greatly appreciated.

-- 
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.391afd6eaad5163fe76569c278af0af0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21216: `OneToOneField` reverse accessor cannot be hidden.

2013-10-03 Thread Django

#21216: `OneToOneField` reverse accessor cannot be hidden.
-+-
 Reporter:  charettes|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"fa2e1371cda1e72d82b4133ad0b49a18e43ba411"]:
 {{{
 #!CommitTicketReference repository=""
 revision="fa2e1371cda1e72d82b4133ad0b49a18e43ba411"
 Fixed #21216 -- Allow `OneToOneField` reverse accessor to be hidden.
 }}}

-- 
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.54ed3eeb16248aa20f9edb39a4e20105%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] fa2e13: Fixed #21216 -- Allow `OneToOneField` reverse acce...

2013-10-03 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fa2e1371cda1e72d82b4133ad0b49a18e43ba411
  
https://github.com/django/django/commit/fa2e1371cda1e72d82b4133ad0b49a18e43ba411
  Author: Simon Charette 
  Date:   2013-10-03 (Thu, 03 Oct 2013)

  Changed paths:
M django/db/models/fields/related.py
M docs/releases/1.7.txt
M tests/one_to_one_regress/models.py
M tests/one_to_one_regress/tests.py

  Log Message:
  ---
  Fixed #21216 -- Allow `OneToOneField` reverse accessor to be hidden.



-- 
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/524da78e74a11_577cfe5d5810679%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21216: `OneToOneField` reverse accessor cannot be hidden.

2013-10-03 Thread Django

#21216: `OneToOneField` reverse accessor cannot be hidden.
-+-
 Reporter:  charettes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

 * stage:  Unreviewed => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.586c7b0e4ab00187c36d7bbc04e1fd82%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21213: Document how to subscribe to mailing lists without a Google account

2013-10-03 Thread Django

#21213: Document how to subscribe to mailing lists without a Google account
-+-
 Reporter:  unaizalakain |Owner:
 Type:   |  unaizalakain
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mailing list,| Triage Stage:  Accepted
  subscription, google   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by timo):

 Sure, I think something like `docs/internals/mailing-lists.txt` would be a
 useful addition.

-- 
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.832f678dc82e73c3e531f349d9971bab%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21212: OneToOneField reference does not document the "reverse" name

2013-10-03 Thread Django

#21212: OneToOneField reference does not document the "reverse" name
-+-
 Reporter:  bjb@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  OneToOneField,   |  Needs documentation:  0
  reverse|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by charettes):

 #21216 is fixing an issue with hidden `OneToOneField` reverse descriptor
 that should unify `related_name` across all related fields.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/072.804592ef1bf2c5e540d297c9c26bf7e4%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21216: `OneToOneField` reverse accessor cannot be hidden.

2013-10-03 Thread Django

#21216: `OneToOneField` reverse accessor cannot be hidden.
-+-
 Reporter:  charettes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 All tests pass on Python 2.7 with SQLite.

-- 
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.5e91b25c0daa0a50fde995c4cf59eb73%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21216: `OneToOneField` reverse accessor cannot be hidden.

2013-10-03 Thread Django

#21216: `OneToOneField` reverse accessor cannot be hidden.
-+-
   Reporter:  charettes  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 `ForeignKey` allows to set a `related_name` ending with a `'+'` to hide
 the reverse accessor.

 This can be quite useful when you want to reference a third-party app
 model but want to avoid polluting it when an unnecessary reverse
 descriptor.

 Attaching a patch with tests and a release note. This should help #21212,
 which aims to document `OneToOneField.related_name`, to reuse/reference
 the existing `ForeignKey` one.

-- 
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/052.525b85a8615c35c59fe2b37ef841f428%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10554: Response.set_cookie should allow setting two cookies of the same name.

2013-10-03 Thread Django

#10554: Response.set_cookie should allow setting two cookies of the same name.
---+
 Reporter:  jdunck |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  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 unaizalakain):

 Would a MorselKey class implementing the aforementioned methods in
 django.http.cookie be right? If so, I'll submit a 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/064.302b0cda5d17aced9ae22177d52b2b99%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16187: Refactor lookup system

2013-10-03 Thread Django

Comment (by akaariai):

Recent developments: GeoWhereNode, GeoSQLCompiler and GeoQuery are gone.

GeoWhereNode was converted to GeoLookup. GeoLookup could be improved a
lot, but for now on just doing exactly what the old code seems good
enough. In general the new custom lookup and custom annotations features
could be used to make the implementation of GIS a lot better (from ability
to nest lookups to plain bugfixing).

I went into some trouble to remove all usage of GeoSQLCompiler and
GeoQuery. The compiler subclass resulted in lots of clutter in different
DB backends, and there wasn't almost anything left in any case. The
GeoQuery removal was mostly motivated by principle of "least private API
usage".

I am now waiting for composite fields implementation to get in to master.
It should make some parts of custom_lookups code simpler (mainly in
Query.build_lookup()). After that the API still needs to be cleaned up and
documented. Finally I need to check how 3rd party SQL backends or non-SQL
backends can adapt to the 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/063.d89f066e0dcab9a0853943b33eb60711%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14273: Development server does not shutdown cleanly

2013-10-03 Thread Django

#14273: Development server does not shutdown cleanly
--+
 Reporter:  rmboggs   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:  runserver | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timo):

 * needs_better_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 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.d81215149bd5c2304d140b968d61f225%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16084: makemessages command doesn't respect LOCALE_PATHS setting

2013-10-03 Thread Django

#16084: makemessages command doesn't respect LOCALE_PATHS setting
--+
 Reporter:  heylinus  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  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
--+

Comment (by claudep):

 I've just updated the patch to current master and created a pull request:
 https://github.com/django/django/pull/1706

-- 
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.a242da471a08b88684c3437427964ade%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20522: Admin formset validation cannot take submitted model instance into account when form not valid.

2013-10-03 Thread Django

Comment (by timo):

I sympathize with that concern and am ok adding the additional models. I
left a couple more comments on the PR.

In wondering why the code wasn't written like this in the first place, I
recalled a warning in
[https://docs.djangoproject.com/en/1.6/topics/forms/modelforms
/#validation-on-a-modelform Validation on a ModelForm].

"The cleaning process modifies the model instance passed to the
ModelForm constructor in various ways. For instance, any date fields on
the model are converted into actual date objects. Failed validation may
leave the underlying model instance in an inconsistent state and therefore
it’s not recommended to reuse it."

As the OP points out, hopefully "this will be better than the nothing we
currently get", but I mention it in case a documentation update might be
helpful somewhere. It seems like it could actually break existing formset
validation code if model attributes are different types when the form is
invalid which makes me a little nervous.

--
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.954093a318b65f80204b22759cab1b86%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21206: Misleading Exception on emty test class: ImportError: Start directory is not importable

2013-10-03 Thread Django

#21206: Misleading Exception on emty test class: ImportError: Start directory is
not importable
---+--
 Reporter:  thepapermen|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.6-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by carljm):

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


Comment:

 I suggested a few small changes on the PR, but basically I think you've
 got the right approach. Thanks for taking this one on!

-- 
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/069.bbea0c33b7ce662caee3bf72d146fbcc%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21213: Document how to subscribe to mailing lists without a Google account

2013-10-03 Thread Django

#21213: Document how to subscribe to mailing lists without a Google account
-+-
 Reporter:  unaizalakain |Owner:
 Type:   |  unaizalakain
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mailing list,| Triage Stage:  Accepted
  subscription, google   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by unaizalakain):

 Yep, I was planning to submit a patch myself but I wanted to wait for some
 kind of feedback.

 What do you think about creating a mailing list specific page instead of
 mentioning the django-users, django-developers and django-updates mailing
 lists directly on every single page? In this way, secondary information
 can be given without mentioning it on every single page.

-- 
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.5746c25b7a1a0509984a7a0eb961fd3c%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21206: Misleading Exception on emty test class: ImportError: Start directory is not importable

2013-10-03 Thread Django

#21206: Misleading Exception on emty test class: ImportError: Start directory is
not importable
---+--
 Reporter:  thepapermen|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.6-beta-1
 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 prestontimmons):

 I added a fix and PR here:

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

 I'm not happy with the use of import_module. If anyone has another way to
 tell a dotted path is a package, I'll try it out.

-- 
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/069.6c7ad0ab39acd6ffdfcba18338732922%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21212: OneToOneField reference does not document the "reverse" name

2013-10-03 Thread Django

#21212: OneToOneField reference does not document the "reverse" name
-+-
 Reporter:  bjb@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  OneToOneField,   |  Needs documentation:  0
  reverse|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by timo):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.5 => master
 * easy:  0 => 1
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 The reverse attribute is just `` (lowercased). We can also
 mention the name can be customized with `related_name` (just like
 `ForeignKey`).

-- 
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/072.b9dc0bd731e66bb19bccfbaeb99406c0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16260: Ability to change dismissRelatedLookupPopup on custom callback function

2013-10-03 Thread Django

#16260: Ability to change dismissRelatedLookupPopup on custom callback function
--+
 Reporter:  alekam|Owner:  alekam
 Type:  New feature   |   Status:  assigned
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  admin javascript  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  1
--+
Changes (by timo):

 * needs_better_patch:  0 => 1
 * easy:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.cce9826a8f0813f9909a02c78baa292f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21213: Document how to subscribe to mailing lists without a Google account (was: mailing lists subscriptions)

2013-10-03 Thread Django

#21213: Document how to subscribe to mailing lists without a Google account
-+-
 Reporter:  unaizalakain |Owner:
 Type:   |  unaizalakain
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mailing list,| Triage Stage:  Accepted
  subscription, google   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by timo):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.5 => master
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Were you planning to provide a patch since you assigned this to yourself?
 If not, could you indicate where in the docs you expected to see this
 info?

-- 
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.699ed91f6915779248950f85009bf376%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21215: Migrations for inherited models

2013-10-03 Thread Django

#21215: Migrations for inherited models
-+-
 Reporter:  anant90@…|Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:
  inherited model|  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:

 I'm unable to reproduce this with your given models (changing `BaseModel`
 to `models.Model` and the user FK `django.contrib.auth.models.User` to a
 different model).

 Are you running with the latest master? (migrations is under active
 development)

 If so, could you provide a minimal models file to reproduce?

-- 
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.7fffac80a5f00299eba64e081b3dabc7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21080: collectstatic post-processing fails for references inside comments

2013-10-03 Thread Django

Comment (by pabluk):

I'm agree with the [[comment:1|comment]] of @marfire, the correct way to
do this is with a CSS parser, because there are many cases to be treated
(multi-line comments, nested comments, broken comments, etc.)

Adding an option to skip failed imports was reported in ticket:19650 and
it was marked as a duplicated of ticket:18958.

If you really need ignore these errors, you can create a subclass of
`CachedFilesMixin` on your own project and add a `try...except` statement
to handle these kind of exceptions.

--
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.fd7306db3055028bdaff073ae89d9bea%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] c4db7f: Fixed #19182 -- Fixed ModelAdmin.lookup_allowed to...

2013-10-03 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: c4db7f075e269411287ff14b5518412250ba455f
  
https://github.com/django/django/commit/c4db7f075e269411287ff14b5518412250ba455f
  Author: Anentropic 
  Date:   2013-10-03 (Thu, 03 Oct 2013)

  Changed paths:
M django/contrib/admin/options.py
M tests/admin_filters/tests.py

  Log Message:
  ---
  Fixed #19182 -- Fixed ModelAdmin.lookup_allowed to work with ('fieldname', 
SimpleListFilter) syntax.

Thanks gauss for the report.



-- 
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/524d733fe592_65bfa47d4c562e6%40hookshot-fe1-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19182: ModelAdmin.lookup_allowed should also check for ('fieldname', ClassName) syntax

2013-10-03 Thread Django

#19182: ModelAdmin.lookup_allowed should also check for ('fieldname', ClassName)
syntax
-+-
 Reporter:  gauss|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  modeladmin   | Triage Stage:  Accepted
  lookup_allowed |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"c4db7f075e269411287ff14b5518412250ba455f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c4db7f075e269411287ff14b5518412250ba455f"
 Fixed #19182 -- Fixed ModelAdmin.lookup_allowed to work with ('fieldname',
 SimpleListFilter) syntax.

 Thanks gauss 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 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.ba4184c1a1c747a89640bf61e511bcc5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21143: runtests might execute queries against the normal database instead of the testdatabase

2013-10-03 Thread Django

#21143: runtests might execute queries against the normal database instead of 
the
testdatabase
---+
 Reporter:  apollo13   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 pabluk):

 Can you provide a minimal test project (settings and your testrunner) in
 which the queries are executed again the normal database?
 So that the problem can be reproduced and investigated.

-- 
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.bb640311dd101d337eb5ffea0a4f1bde%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #373: Add support for multiple-column primary keys

2013-10-03 Thread Django

#373: Add support for multiple-column primary keys
-+-
 Reporter:  jacob|Owner:  konk
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  database |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by lars@…):

 * cc: lars@… (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/063.265cd5abfc3bdee47fb6dff1f19adc96%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21215: Migrations for inherited models

2013-10-03 Thread Django

#21215: Migrations for inherited models
+
 Reporter:  anant90@…   |  Owner:
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  master
 Severity:  Normal  |   Keywords:  migrations inherited model
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I have a model BankAccount which inherits from another model PaymentType
 as shown below:

 {{{
 class PaymentType(BaseModel):
 user = models.ForeignKey(StupaUser, related_name =
 "%(app_label)s_%(class)s_related")

 class BankAccount(PaymentType):
 account_number = models.CharField(max_length=20)
 bank_name = models.CharField(max_length=40)
 nickname = models.CharField(max_length=30)
 uri = models.CharField(max_length=200, null=True)
 is_valid = models.BooleanField(default=True)
 }}}

 When I try running python manage.py makemigrations , I get
 "ValueError: No field called user on model BankAccount"

 Here's the stack trace:
 {{{
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/anant/Github/django/django/core/management/__init__.py",
 line 397, in execute_from_command_line
 utility.execute()
   File "/Users/anant/Github/django/django/core/management/__init__.py",
 line 390, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/anant/Github/django/django/core/management/base.py", line
 242, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/Users/anant/Github/django/django/core/management/base.py", line
 289, in execute
 output = self.handle(*args, **options)
   File
 "/Users/anant/Github/django/django/core/management/commands/makemigrations.py",
 line 52, in handle
 changes = autodetector.changes(graph=loader.graph,
 trim_to_apps=app_labels or None)
   File "/Users/anant/Github/django/django/db/migrations/autodetector.py",
 line 34, in changes
 changes = self._detect_changes()
   File "/Users/anant/Github/django/django/db/migrations/autodetector.py",
 line 140, in _detect_changes
 field = model_state.get_field_by_name(field_name),
   File "/Users/anant/Github/django/django/db/migrations/state.py", line
 177, in get_field_by_name
 raise ValueError("No field called %s on model %s" % (name, self.name))
 ValueError: No field called user on model BankAccount
 }}}

 Is this expected? Why can't I use migrations for inherited models?

-- 
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.c244f55ff0d2007990a5e698c32fbf9c%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21105: Implement `PBKDF2PrehashPasswordHasher` to prevent hashing time from depending on password length

2013-10-03 Thread Django

#21105: Implement `PBKDF2PrehashPasswordHasher` to prevent hashing time from
depending on password length
--+--
 Reporter:  coolRR|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  1.6-beta-1
 Severity:  Normal|   Resolution:  worksforme
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by apollo13):

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


Comment:

 I don't see any improvement over
 
https://github.com/django/django/commit/68540fe4df44492571bc610a0a043d3d02b3d320
 here; hence closing 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 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.a67c37c3ea3d78002f32a78f40286472%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21214: Why does Django display all datetimes in UTC by default?

2013-10-03 Thread Django

Comment (by aaugustin):

Replying to [comment:2 anonymous]:
> If PostgreSQL stores datetimes in UTC internally, but translates them to
the connection's time zone as they come back out, doesn't that mean Django
is receiving those datetimes in the connection's time zone? Because if
so, my point is still that it doesn't make sense for Django to then
convert those values back to UTC again.

Django doesn't convert values to UTC. The connection's time zone is set to
UTC and Django gets the values in UTC.

> [https://docs.djangoproject.com/en/1.4/topics/i18n/timezones/#other-
databases This] is why. It says right there in the documentation that
while PostgreSQL stores time zone information, other database backends
don't. That's why my suggestion was for Django to just leave datetimes in
whatever format PostgreSQL gives them, unless the developer explicitly
chooses otherwise.

That's what Django does.

> Of course, I am basing this on the assumption that Django gets the same
data from PostgreSQL as I do when I use `psql mydatabase` to look at the
database directly (for instance, `2013-10-07 01:00:00+08`).

This isn't true, unless you run SET TIME ZONE 'UTC' first.

> If that's not true and Django *is* directly accessing the UTC-formatted
datetimes stored internally by PostgreSQL, then obviously my point is
moot.

It is :)

--
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.fece3909411c78eeafd7a59ec4ecd09b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21111: generic.View.init should call super

2013-10-03 Thread Django

#2: generic.View.__init__ should call super
--+
 Reporter:  glin@…|Owner:  gmeno
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Generic views |  Version:  1.5
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by tomchristie):

 As noted in the discussion group thread, the issue there is that you're
 declaring the classes in the wrong order.

  If you subclass the View class correctly there's no issue, like so:

 {{{
 class MyView(SomeMixin, View)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/072.48f768621704c7158f6c4522d523fc1b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21157: Problems with ResolverMatch

2013-10-03 Thread Django

#21157: Problems with ResolverMatch
--+--
 Reporter:  marfire   |Owner:  marfire
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by marfire):

 * status:  new => assigned
 * owner:  nobody => marfire
 * has_patch:  0 => 1


Comment:

 Patch here: https://github.com/django/django/pull/1704

 Although this brings the implementation into compliance with the
 documentation, there's one situation I can think of where the user could
 see a change: if they have an unused url entry that points to an invalid
 view that happens to not have a `'.'` in it, an application that was
 previously working will now produce an exception when `reverse()` / `url`
 is used. As described in Malcolm's comment to #6568, this exception
 raising is purposeful behavior; it just happened to be masked by this bug.
 This is an obscure (but possible) scenario, so I'm not sure if a warning
 in the documentation is called for. (I came across it because some parts
 of the existing test suite have this problem.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.9275d5ae5f78a146b21c6f358707e6a4%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21214: Why does Django display all datetimes in UTC by default?

2013-10-03 Thread Django

#21214: Why does Django display all datetimes in UTC by default?
-+-
 Reporter:  guillaumechorn@… |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  1.4
  Internationalization   |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  time zone, datetime  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by anonymous):

 Thank you for your quick response.



 > This paragraph doesn't talk about PostgreSQL (model layer), it talks
 about `cleaned_data` (form layer).

 I understand that this part doesn't refer specifically to PostgreSQL or
 the model layer.  I just meant that it means the form captures time zone
 information.  I assumed it is this time zone information that is passed on
 to the database eventually.



 > As an implementation detail, PostgreSQL always stores the data as UTC
 internally, even when `USE_TZ = False`, and it deals with conversions
 between UTC and the database connection's time zone when the latter isn't
 UTC.

 I missed that part when I originally read the docs, but it doesn't really
 change my point. From the docs: "In practice, this means it converts
 datetimes from the connection’s time zone to UTC on storage, and from UTC
 to the connection’s time zone on retrieval." If PostgreSQL stores
 datetimes in UTC internally, but translates them to the connection's time
 zone as they come back out, doesn't that mean Django is receiving those
 datetimes in the connection's time zone?  Because if so, my point is still
 that it doesn't make sense for Django to then convert those values back to
 UTC again.



 > I don't get why you think it's specific to PostgreSQL. Django provides
 good cross-database compatibility for something as trivial as datetimes.

 [https://docs.djangoproject.com/en/1.4/topics/i18n/timezones/#other-
 databases This] is why.  It says right there in the documentation that
 while PostgreSQL stores time zone information, other database backends
 don't.  That's why my suggestion was for Django to just leave datetimes in
 whatever format PostgreSQL gives them, unless the developer explicitly
 chooses otherwise.

 Of course, I am basing this on the assumption that Django gets the same
 data from PostgreSQL as I do when I use `psql mydatabase` to look at the
 database directly (for instance, `2013-10-07 01:00:00+08`).  If that's not
 true and Django *is* directly accessing the UTC-formatted datetimes stored
 internally by PostgreSQL, then obviously my point is moot.



 > > Obviously it's meant to work as an invisible template tag that you
 don't have to type in yourself, and I understand that the same template
 tag wouldn't work for both `{{ object.datetime }}` and `{{
 object.datetime.day }}`.
 >
 > I didn't get that part.
 Django automatically converting aware datetime objects to the current time
 zone in templates is similar to using `{% localtime on %}` or `{{
 object.datetime|localtime }}`, is it not?  My intention was just to say
 that something like `|localtime` doesn't work on both `{{ object.datetime
 }}` and `{{ object.datetime.hour }}`, so I get why the current "Time zone
 aware output in templates" functionality doesn't work for `{{
 object.datetime.hour }}` either.  Hence my suggestion to convert datetimes
 (or not convert them) prior to the template layer.


 I guess my concrete proposal would be for Django to *not* automatically
 convert non-UTC datetimes to UTC when dealing with PostgreSQL, based on my
 understanding that it gets non-UTC datetimes from PostgreSQL.  But as I
 mentioned above, if that's an incorrect understanding, then case closed.

 Replying to [comment:1 aaugustin]:
 > (All my comments assume `USE_TZ = True`.)
 >
 > Replying to [ticket:21214 guillaumechorn@…]:
 > > As is mentioned
 [https://docs.djangoproject.com/en/1.4/topics/i18n/timezones/#time-zone-
 aware-input-in-forms here] in the docs, Django has time zone aware input
 in forms, and as a result, PostgreSQL databases store datetime values
 expressed in the time zone of which the form was aware--''not'' UTC.
 >
 > This paragraph doesn't talk about PostgreSQL (model layer), it talks
 about `cleaned_data` (form layer).
 >
 > As an implementation detail, PostgreSQL always stores the data as UTC
 internally, even when `USE_TZ = False`, and it deals with conversions
 between UTC and the database connection's time zone when the latter isn't
 UTC.
 >
 > When `USE_TZ = True`, Django converts datetimes to UTC if they're
 originally in another timezone. (psycopg2 would

Re: [Django] #21211: DEFAULT_DB_ALIAS in settings

2013-10-03 Thread Django

#21211: DEFAULT_DB_ALIAS in settings
-+-
 Reporter:  martyn.clement@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.5
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  database, settings,  |  Needs documentation:  0
  DEFAULT_DB_ALIAS   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Martyn CLEMENT ):

 Sorry, I forgot to authenticate.

-- 
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.7aaed8486d1095754dfbb246397401c9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21211: DEFAULT_DB_ALIAS in settings

2013-10-03 Thread Django

Comment (by anonymous):

My project is splitting in 2 different database but has to use all the
same basecode.
The code has to know on which database it is running and has also to know
which database is the other one so that I can retrieve some information
with Model.objects.using(...) .

So I made 2 projects (by project I mean, 2 folders containing manage.py,
individual settings etc...).
There is no idea of a "default". I use a custom router to tell django on
which database it has to run.

But the problem come when I run django commands (for ex: .manage.py shell)
or when I have to use the django.db.connection.
I thought the router had a global effect, but it affects only the ORM.

In my settings, if I could set the DEFAULT_DB_ALIAS to the concerned
database, it should be ok.

Moreover, I don't see why this variable has to be immutable.
By default, it's "default" but user can set it if needed.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To 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.11220a006f9be5ee07714ccddb6d30a9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21214: Why does Django display all datetimes in UTC by default?

2013-10-03 Thread Django

#21214: Why does Django display all datetimes in UTC by default?
-+-
 Reporter:  guillaumechorn@… |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  1.4
  Internationalization   |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  time zone, datetime  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 (All my comments assume `USE_TZ = True`.)

 Replying to [ticket:21214 guillaumechorn@…]:
 > As is mentioned
 [https://docs.djangoproject.com/en/1.4/topics/i18n/timezones/#time-zone-
 aware-input-in-forms here] in the docs, Django has time zone aware input
 in forms, and as a result, PostgreSQL databases store datetime values
 expressed in the time zone of which the form was aware--''not'' UTC.

 This paragraph doesn't talk about PostgreSQL (model layer), it talks about
 `cleaned_data` (form layer).

 As an implementation detail, PostgreSQL always stores the data as UTC
 internally, even when `USE_TZ = False`, and it deals with conversions
 between UTC and the database connection's time zone when the latter isn't
 UTC.

 When `USE_TZ = True`, Django converts datetimes to UTC if they're
 originally in another timezone. (psycopg2 would do it if Django didn't,
 but it was necessary to implement it in Django to cater for less capable
 databases.)

 > So why then have Django go through the trouble of constantly converting
 all datetime values queried from the database to UTC?

 They are in UTC in the database. Keeping them in UTC until another
 timezone is needed avoids unecessary work.

 In hindsight, I reckon that always converting them the the default time
 zone may have been a better choice, even though it would have been slower.


 > Why not just make the developer need to explicitly tell Django (either
 through a simple setting in `settings.py`, or using an optional function
 in their views) that they want values expressed in UTC?

 You mean, that they want values expressed in the default time zone?

 If you want to have everything in local time with no time zone support you
 can just set `USE_TZ = False` (and deal with DST issues by yourself).


 > The issue with having Django automatically convert all datetime values
 to UTC, as is the case now, is that in the case that the developer wants
 datetimes expressed to the user in the same time zone as they were entered
 by the user (which is quite often, I would imagine), they must actually
 write code to convert the values ''back'' to what is already (!) stored in
 the database before rendering them in templates.  I realize that this is
 only strictly the case when using PostgreSQL, but it still makes very
 little sense to me.

 I don't get why you think it's specific to PostgreSQL. Django provides
 good cross-database compatibility for something as trivial as datetimes.


 > The "Time Zone aware output in templates" referred to
 [https://docs.djangoproject.com/en/1.4/topics/i18n/timezones/#time-zone-
 aware-output-in-templates here] only works in the most basic invocation of
 a datetime value (something like `{{ object.datetime }}`).  It doesn't
 convert the hours if you use something like `{{ object.datetime.hour }}`,
 or the day if you use `{{ object.datetime.day }}`.

 Fair enough. Why didn't you bring it up while I was writing the feature?
 :) Now it's impossible to change :(

 I recommend using the `|date` filter or turning time zone support off.

 If only we had a better time zone implementation if Python's stdlib. (In
 Python 3.5 maybe...)


 > I find this extremely limited, and quite far removed from Django's usual
 ability to abstract common tasks.

 Thank you.


 > Obviously it's meant to work as an invisible template tag that you don't
 have to type in yourself, and I understand that the same template tag
 wouldn't work for both `{{ object.datetime }}` and `{{ object.datetime.day
 }}`.

 I didn't get that part.


 > But that's why I think it would make more sense for Django to return
 datetime values as they are formatted in the database by default, rather
 than automatically converting them to UTC (at least when usage of
 PostgreSQL has been declared in `settings.py`).

 Like I said above Django *does* return datetime values as stored in the
 database.

 

 To sum up, you misunderstood parts of Django's time zone handling, and I
 couldn't extract an actionable item

68 matches

Mail list logo