date:20141126

Re: [Django] #21587: Make generic RedirectView default to permanent=False

2014-11-26 Thread Django

#21587: Make generic RedirectView default to permanent=False
-+-
 Reporter:  wraus@…  |Owner:
 Type:   |  berkerpeksag
  Cleanup/optimization   |   Status:  new
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  redirect, view   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by berkerpeksag):

 * has_patch:  0 => 1


Comment:

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

--
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/084.8f1c4d2ad415eb2d9e58d325cb1862ab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23768: Rewrite template_tag.tests.TemplateTests as individual test cases

2014-11-26 Thread Django

#23768: Rewrite template_tag.tests.TemplateTests as individual test cases
--+
 Reporter:  prestontimmons|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by prestontimmons):

 * has_patch:  0 => 1


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

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

Re: [Django] #23768: Rewrite template_tag.tests.TemplateTests as individual test cases

2014-11-26 Thread Django

#23768: Rewrite template_tag.tests.TemplateTests as individual test cases
--+
 Reporter:  prestontimmons|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  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 prestontimmons):

 I added a pull request here:

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

--
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.9626dddcfeab86b2a94124d8124f75a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23916: makemigrations does not detect/like model name case changes

2014-11-26 Thread Django

#23916: makemigrations does not detect/like model name case changes
+
 Reporter:  scoenye |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 MarkusH):

 * cc: info+coding@… (added)


Comment:

 Thank you for the report. The problem you ran into relates to the fact
 that the migration internally don't care about case sensitivity of model
 names (`ProjectState.models` has a dictionary whose keys are `(app_label,
 model_name)` where the latter is lower cased).

 Your work around seems to be valid. I'd need more info to figure out why
 adding the RenameModel manually fails.

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

Re: [Django] #21587: Make generic RedirectView default to permanent=False

2014-11-26 Thread Django

#21587: Make generic RedirectView default to permanent=False
-+-
 Reporter:  wraus@…  |Owner:
 Type:   |  berkerpeksag
  Cleanup/optimization   |   Status:  new
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  redirect, view   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by berkerpeksag):

 I think the patch is wrong too. Here is a WIP version:
 https://gist.github.com/berkerpeksag/4b6d3843a1941593741c
 `RedirectViewDeprecationTest` is failing now, I'll take a look at 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/084.f9c205b49b31a008594e412e5065f1fa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23924: EmailMessage type checks should raise TypeError, not AssertionError

2014-11-26 Thread Django

#23924: EmailMessage type checks should raise TypeError, not AssertionError
-+
 Reporter:  martinblech  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by martinblech):

 * cc: martinblech@… (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/069.c2f9b943cf203e01164606cc14692e3e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23906: "ValueError: Found wrong number (0) of constraints" when migrating backwards with from alter_unique_together migration.

2014-11-26 Thread Django

#23906: "ValueError: Found wrong number (0) of constraints" when migrating
backwards with from alter_unique_together migration.
-+-
Reporter: liavkoren|Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
alter_unique_together migrations | Unreviewed
constraints valueError | Needs documentation: 0
Has patch: 0| Patch needs improvement: 0
Needs tests: 0|UI/UX: 0
Easy pickings: 0|
-+-
Changes (by MarkusH):

* cc: info+coding@… (added)
* status: new => closed
* resolution: => invalid

Comment:

As far as I know the order of the items in the too_together lists does
matter, at least on MySQL a unique constraint on a,b is different to b,a
(or at least was for a very long time). That being said, your "fix" is
wrong and, as Carl already said, your database just doesn't have the same
state as your models represent.

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

Re: [Django] #23910: Add reply_to parameter to EmailMessage

2014-11-26 Thread Django

#23910: Add reply_to parameter to EmailMessage
-+-
 Reporter:  zkanda   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  email, headers   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by berkerpeksag):

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


Comment:

 [https://github.com/django/django/pull/3624 PR #3624] LGTM.

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

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

Re: [Django] #23924: EmailMessage type checks should raise TypeError, not AssertionError

2014-11-26 Thread Django

#23924: EmailMessage type checks should raise TypeError, not AssertionError
-+
 Reporter:  martinblech  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+

Comment (by martinblech):

 [https://github.com/django/django/pull/3630 PR here]

 I'm still not sold on the error message, it says `'"to" argument must be a
 list or tuple'` but the actual check is `isinstance(to,
 six.string_types)`. I think we should change one or the other.

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

Re: [Django] #23847: Minor Problem with Auth Documentation

2014-11-26 Thread Django

#23847: Minor Problem with Auth Documentation
-+-
 Reporter:  xmnr |Owner:
 Type:   |  berkerpeksag
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by berkerpeksag):

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


Comment:

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

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

Re: [Django] #21587: Make generic RedirectView default to permanent=False

2014-11-26 Thread Django

#21587: Make generic RedirectView default to permanent=False
-+-
 Reporter:  wraus@…  |Owner:
 Type:   |  berkerpeksag
  Cleanup/optimization   |   Status:  new
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  redirect, view   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * cc: timo (removed)
 * cc: berkerpeksag (added)
 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>


Comment:

 I think the strategy for silencing deprecation warnings is faulty. We need
 to silence when they are used in URLconfs similar to how is done in the
 
[https://github.com/django/django/blob/e9d1f1182aaccaa8b60cf6a3491f0103d2bb0229/tests/urlpatterns_reverse/urls.py#L17-L18
 url tests] although I think it needs to be:
 {{{
 with warnings.catch_warnings(record=True):
 warnings.filterwarnings('ignore', category=RemovedInDjango20Warning)
 }}}
 (at least the `module='...'` approach doesn't seem to work in
 [https://github.com/django/django/pull/3626 PR 3626], although I am not
 sure why.

 Right now the ordering of tests affects whether or not you will see
 errors. For example, run the following and you should get a warning:
 {{{
 python -Wall runtests.py test_client_regress
 }}}
 Since we are running with:
 {{{
 warnings.simplefilter("default", RemovedInDjango19Warning)
 warnings.simplefilter("default", RemovedInDjango20Warning)
 }}}
 in `runtests.py`, I think only the first occurrence of the warning in the
 test suite is output.

--
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/084.e292ebe542b8c1b4d4f913c5d122c375%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23924: EmailMessage type checks should raise TypeError, not AssertionError

2014-11-26 Thread Django

#23924: EmailMessage type checks should raise TypeError, not AssertionError
-+
 Reporter:  martinblech  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by timgraham):

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


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

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

[Django] #23924: EmailMessage type checks should raise TypeError, not AssertionError

2014-11-26 Thread Django

#23924: EmailMessage type checks should raise TypeError, not AssertionError
-+
 Reporter:  martinblech  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Mail)  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+
 If I run the following code:

 {{{#!python
 email = EmailMessage(
 'Subject', 'Content',
 'f...@example.com',
 't...@example.com')

 print(email.message())
 }}}

 With the `-O` option, I get:

 {{{
 Traceback (most recent call last):
   File "x.py", line 6, in 
 't...@example.com')
   File "/home/berker/hacking/django/django/core/mail/message.py", line
 227, in __init__
 assert not isinstance(to, six.string_types), '"to" argument must be a
 list or tuple'
 AssertionError: "to" argument must be a list or tuple
 }}}

 But without it, it fails silently and produces a broken `To` header:

 {{{
 From nobody Wed Nov 26 18:30:08 2014
 MIME-Version: 1.0
 Content-Type: text/plain; charset="utf-8"
 Content-Transfer-Encoding: 7bit
 Subject: Subject
 From: f...@example.com
 To: t, o, @, e, x, a, m, p, l, e, ., c, o, m
 Date: Wed, 26 Nov 2014 18:30:08 -
 Message-ID: <20141126183008.1632.71698@rama>

 Content
 }}}

--
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/054.7540f47069c98f859b21b16ef8c35c4c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23780: Easy to use natural keys from a tuple on meta

2014-11-26 Thread Django

Comment (by freakboy3742):

Personally, I disagree with the original premise - I don't see defining a
pair of natural key functions as "cumbersome". It's two methods, each of
which are relatively straightforward to define for the simple case, but
which can have some interesting edge cases for the complex case - e.g., if
a foreign key is involved in a natural key, do you render the PK value? Or
do you use the natural key of the foreign key? What if that natural key
has a foreign key? What's the precedence of manually defined natural key
function over the Meta defined one? What about if you only define *one* of
the two natural key functions?

I'll note that the provided patch doesn't appear to test any of these edge
cases - it only explores the simple (and obvious) case of "a single value-
based field as natural key".

I see this as a case where explicit is better than implicit. If we
implement this, we're going to have an implementation that is non-trivial
to cover all possible use cases, which means introducing a complexity in
implementation, which will need to be maintained (and will inevitably get
more complex when things like composite fields, and the foreign key
refactor that Anssi is sitting on hit trunk). There's also some
documentation for a new feature, - instead of an explicit API entry point
that implements a specific behavior, you have a configuration value, and
newcomers need to know about and understand the internal behavior before
they can use the feature reliably.

Or, we have a relatively simple 4 lines of explicit code on any project
that needs a natural key; maybe 6 lines of code if it's a complex case
(and it's the complex case that has the complex code - the simple case
doesn't pay any overhead).

So - I'm a -0 on the general idea.

That said, the idea has come up a couple of times in the recent past, so
there's clearly some community interest. If we *must* have an
implementation of this feature, a meta attribute is about as good as it's
going to get - it's certainly better than the "automagically interpret
natural keys from model definition" that has been proposed by others.

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

Re: [Django] #23872: Squashmigration tests dependent on current working directory

2014-11-26 Thread Django

#23872: Squashmigration tests dependent on current working directory
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Carl Meyer ):

 In [changeset:"6f65bd1cf08c7dff9581d9033a6d534f3202eb27"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6f65bd1cf08c7dff9581d9033a6d534f3202eb27"
 [1.7.x] Fixed #23872 -- Removed sensitivity of migrations tests to CWD.

 Backport of 47b7f601eeb93bd7a91f87b77da658212f2f2314 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.6cf37b583008d4083fdbf118d6063e8c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23801: Warn when max_length is used with IntegerField

2014-11-26 Thread Django

#23801: Warn when max_length is used with IntegerField
-+-
 Reporter:  eykd |Owner:
 Type:  New feature  |  MattBlack85
Component:  Database layer   |   Status:  closed
  (models, ORM)  |  Version:  master
 Severity:  Normal   |   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 Tim Graham ):

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


Comment:

 In [changeset:"e9d1f1182aaccaa8b60cf6a3491f0103d2bb0229"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e9d1f1182aaccaa8b60cf6a3491f0103d2bb0229"
 Fixed #23801 -- Added warning when max_length is used with IntegerField
 }}}

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

Re: [Django] #23780: Easy to use natural keys from a tuple on meta

2014-11-26 Thread Django

#23780: Easy to use natural keys from a tuple on meta
-+-
 Reporter:  scrummyin|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core |  Version:  master
  (Serialization)|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * cc: freakboy3742 (added)


Comment:

 Russ, you committed the initial natural keys patch in #7052. How do you
 feel about this shortcut?

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

Re: [Django] #23755: patch_cache_control should special case "no-cache"

2014-11-26 Thread Django

#23755: patch_cache_control should special case "no-cache"
-+
 Reporter:  thenewguy|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Cache system)  |  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 timgraham):

 * type:  Uncategorized => New feature
 * version:  1.7 => master
 * component:  Uncategorized => Core (Cache system)
 * stage:  Unreviewed => Accepted


Old description:

> From my cursory reading of
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, it looks like
> patch_cache_control needs to special case "no-cache".
>

> {{{
> no-cache
> If the no-cache directive does not specify a field-name, then a cache
> MUST NOT use the response to satisfy a subsequent request without
> successful revalidation with the origin server. This allows an origin
> server to prevent caching even by caches that have been configured to
> return stale responses to client requests.
> If the no-cache directive does specify one or more field-names, then a
> cache MAY use the response to satisfy a subsequent request, subject to
> any other restrictions on caching. However, the specified field-name(s)
> MUST NOT be sent in the response to a subsequent request without
> successful revalidation with the origin server. This allows an origin
> server to prevent the re-use of certain header fields in a response,
> while still allowing caching of the rest of the response.
> }}}
>

> For example, to integrate a site that uses "Vary: Cookie" with AWS
> CloudFront, one must use 'Cache-Control: no-cache="Set-Cookie"' if a
> response does not vary by cookie.  (I've confirmed this with AWS support
> as of 10/31/2014).
>
> patch_cache_control does not treat "no-cache" as a list.  If you call
> patch_cache_control(response, no_cache="Set-Cookie") and then
> patch_cache_control(response, no_cache="foo"), you end up with 'Cache-
> Control: no-cache="foo"'
>
> Also, no_cache=True should take precedence over no_cache="foo" regardless
> of the order it is applied.
>
> I found Ticket https://code.djangoproject.com/ticket/13008 which proposes
> to add "no-cache" to @never_cache.  Just wanted to link it here since
> they are related.

New description:

 From my cursory reading of
 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, it looks like
 patch_cache_control needs to special case "no-cache".

  no-cache
  If the no-cache directive does not specify a field-name, then a cache
 MUST NOT use the response to satisfy a subsequent request without
 successful revalidation with the origin server. This allows an origin
 server to prevent caching even by caches that have been configured to
 return stale responses to client requests.
  If the no-cache directive does specify one or more field-names, then a
 cache MAY use the response to satisfy a subsequent request, subject to any
 other restrictions on caching. However, the specified field-name(s) MUST
 NOT be sent in the response to a subsequent request without successful
 revalidation with the origin server. This allows an origin server to
 prevent the re-use of certain header fields in a response, while still
 allowing caching of the rest of the response.

 For example, to integrate a site that uses "Vary: Cookie" with AWS
 CloudFront, one must use 'Cache-Control: no-cache="Set-Cookie"' if a
 response does not vary by cookie.  (I've confirmed this with AWS support
 as of 10/31/2014).

 patch_cache_control does not treat "no-cache" as a list.  If you call
 patch_cache_control(response, no_cache="Set-Cookie") and then
 patch_cache_control(response, no_cache="foo"), you end up with 'Cache-
 Control: no-cache="foo"'

 Also, no_cache=True should take precedence over no_cache="foo" regardless
 of the order it is applied.

 I found Ticket https://code.djangoproject.com/ticket/13008 which proposes
 to add "no-cache" to @never_cache.  Just wanted to link it here since they
 are related.

--

--
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/ms

Re: [Django] #22276: BaseFormSet.is_valid() produces ValidationError when there is no management form

2014-11-26 Thread Django

#22276: BaseFormSet.is_valid() produces ValidationError when there is no 
management
form
---+
 Reporter:  anonymous  |Owner:  patrys
 Type:  Bug|   Status:  assigned
Component:  Forms  |  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 timgraham):

 * version:  1.6 => master
 * 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/067.2bd07713368f14e87f91b13461088666%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23710: ModelForm is not using the plain manager for foreign keys

2014-11-26 Thread Django

#23710: ModelForm is not using the plain manager for foreign keys
-+-
 Reporter:  eagle-r  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:  needsinfo
 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 timgraham):

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


Comment:

 Lacking any follow-up from the reporter, I'm going to close as "needs
 info". Feel free to reopen if you can describe more about the problem
 here.

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

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

Re: [Django] #23801: Warn when max_length is used with IntegerField

2014-11-26 Thread Django

#23801: Warn when max_length is used with IntegerField
-+-
 Reporter:  eykd |Owner:
 Type:  New feature  |  MattBlack85
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #23867: Remove hacks required by .dates() queries

2014-11-26 Thread Django

#23867: Remove hacks required by .dates() queries
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  0|  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:"cbb5cdd155668ba771cad6b975676d3b20fed37b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="cbb5cdd155668ba771cad6b975676d3b20fed37b"
 Fixed #23867 -- removed DateQuerySet hacks

 The .dates() queries were implemented by using custom Query, QuerySet,
 and Compiler classes. Instead implement them by using expressions and
 database converters APIs.
 }}}

--
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.276993197df6545aa8e49db44c2e2a6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23923: Promote Django's deprecation warnings to errors in runtests.py

2014-11-26 Thread Django

#23923: Promote Django's deprecation warnings to errors in runtests.py
--+
 Reporter:  timgraham |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 charettes):

 * 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/067.2bfeae7f33f8b46042cbf361a0e50723%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23923: Promote Django's deprecation warnings to errors in runtests.py

2014-11-26 Thread Django

#23923: Promote Django's deprecation warnings to errors in runtests.py
+
   Reporter:  timgraham |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The Django test suite should run without any visible deprecation warnings.

 By changing:
 {{{
 warnings.simplefilter("default", RemovedInDjango19Warning)
 warnings.simplefilter("default", RemovedInDjango20Warning)
 }}}
 to:
 {{{
 warnings.simplefilter("error", RemovedInDjango19Warning)
 warnings.simplefilter("error", RemovedInDjango20Warning)
 }}}
 in `runtests.py` we can have Jenkins (which runs with -Wall) fail builds
 that introduce unsilenced deprecation warnings. This will save us time
 from having to track them down after the fact.

--
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.5191397b9c85b39f521bb84887ff5193%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23922: Quoting problem in RequestFactory

2014-11-26 Thread Django

#23922: Quoting problem in RequestFactory
---+
 Reporter:  berkerpeksag   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I was trying to convert middleware tests to use `RequestFactory`. I've
 converted all tests easily except
 `CommonMiddlewareTest.test_append_slash_quoted`:

 {{{#!python
 @override_settings(APPEND_SLASH=True)
 def test_append_slash_quoted(self):
 """
 Tests that URLs which require quoting are redirected to their
 slash
 version ok.
 """
 request = self._get_request('needsquoting#')
 r = CommonMiddleware().process_request(request)
 self.assertEqual(r.status_code, 301)
 self.assertEqual(
 r.url,
 'http://testserver/needsquoting%23/')
 }}}

 https://github.com/django/django/blob/master/tests/middleware/tests.py#L94

 The `urlparse` call in the `RequestFactory.generic` method swallows `#` in
 the URL. The test is passing with a plain `HttpRequest` object.

 Here is a try to fix this problem:
 https://github.com/berkerpeksag/django/compare/use-requestfactory

 An alternative fix would be to wrap `path` with `quote(path, safe=b"...")`
 or with `django.utils.encoding.escape_uri_path` in
 `RequestFactory.generic`:

 https://github.com/django/django/blob/master/django/test/client.py#L351

--
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/055.8f5dbdbb489d6577dd956f2169e3113e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23901: Document how to use spatialite with homebrew

2014-11-26 Thread Django

#23901: Document how to use spatialite with homebrew
--+
 Reporter:  kenial|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:  spatialite| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"5f79da581440dba6275f70e8a6ef440a32dbb895"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5f79da581440dba6275f70e8a6ef440a32dbb895"
 [1.7.x] Fixed #23901 -- Documented how to use SpatiaLite with Homebrew.

 Backport of cc870b8ef5e3464c6f051e3ef0a25dfc4b597452 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.43787a9d4079de4c8186147ec4712a53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23792: Create contextmanager to freeze time.time() in tests

2014-11-26 Thread Django

#23792: Create contextmanager to freeze time.time() in tests
--+
 Reporter:  tchaumeny |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by jezdez):

 Makes sense to me, thanks Tim!

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

Re: [Django] #23792: Create contextmanager to freeze time.time() in tests

2014-11-26 Thread Django

Comment (by timgraham):

Our current policy for test dependencies is to skip any tests when the
dependencies aren't installed, so I'm not sure if adding a dependency is
worth it for the affected tests. On the other hand, if freezegun could be
used more often in our tests (haven't looked), then maybe it's worth
trying to change the policy and make it a hard dependency. Making mock a
hard dependency was proposed in #23289. I think the state of virtualenv,
etc. is at a point where we could make this a requirement, but I'll write
to the mailing list about it if there are no immediate objections here.

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

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

Re: [Django] #23901: Document how to use spatialite with homebrew

2014-11-26 Thread Django

#23901: Document how to use spatialite with homebrew
--+
 Reporter:  kenial|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:  spatialite| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"cc870b8ef5e3464c6f051e3ef0a25dfc4b597452"]:
 {{{
 #!CommitTicketReference repository=""
 revision="cc870b8ef5e3464c6f051e3ef0a25dfc4b597452"
 Fixed #23901 -- Documented how to use SpatiaLite with Homebrew.
 }}}

--
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.8e05c18e97ffc251383801240d21cb9a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23792: Create contextmanager to freeze time.time() in tests

2014-11-26 Thread Django

#23792: Create contextmanager to freeze time.time() in tests
--+
 Reporter:  tchaumeny |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by jezdez):

 Someone proposed freezegun in the PR
 (https://github.com/spulec/freezegun), which seems like the more complete
 approach than this local monkey patch. So to me the question is whether we
 accept the limitation of the context manager since it's a test utility but
 should point at freezegun as well?

 For formtools I'd like to follow whatever we decide for Django and then
 backport it for versions that support older Djangos.

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

Re: [Django] #23321: Remove .mo files from the Django Git repository

2014-11-26 Thread Django

#23321: Remove .mo files from the Django Git repository
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:   |   Resolution:
  Internationalization   | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jezdez):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Someday/Maybe


Comment:

 I don't think we should go that route as it would introduce a couple of
 issues that make it harder for our users and from a maintenance
 standpoint:

 - The most pressing issues IMO will show up for users that are using not-
 yet-released versions of Django, e.g. translators and contributors.
   - there are differences in gettext versions that we would not be able to
 fix
   - Windows users don't usually have gettext installed
 - The test system would have to compile the po files on every test run to
 make sure to have a consistent set to base tests on
 - Users on system with a non-writable file system may have problems with
 the subprocess call as part of trans_real.py
 - The Django release manager would have to have gettext installed and run
 an additional command to build the tarball, something that I think is
 better suited for the translation manager (who has to pull files from
 Transifex anyways)

 I understand that having compiled files in a VCS aren't good, but the
 proposed plan doesn't convince me to drop the mo files.

 If only we'd use Babel instead.. it does have the ability to compile po
 files to mo files without dependency on gettext.

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

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

2014-11-26 Thread Django

#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  unaizalakain
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by prestontimmons):

 * needs_better_patch:  1 => 0


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

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

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

2014-11-26 Thread Django

#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  unaizalakain
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by prestontimmons):

 I've updated my pull request with Aymeric's latest changes.

 It now includes integration with engine.get_template, the debug view, and
 docs.

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

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

Re: [Django] #23901: Document how to use spatialite with homebrew (was: Unable to load the SpatiaLite library extension "/usr/local/lib/libspatialite.dylib")

2014-11-26 Thread Django

#23901: Document how to use spatialite with homebrew
--+
 Reporter:  kenial|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  spatialite| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

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

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

Re: [Django] #23921: Can't hide a hidden field in the django admin

2014-11-26 Thread Django

#23921: Can't hide a hidden field in the django admin
---+--
 Reporter:  DoctorMalboro  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.6
 Severity:  Normal |   Resolution:  invalid
 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 timgraham):

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


Comment:

 Have you tried
 
[https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.form
 ModelAdmin.form]?

 Please see TicketClosingReasons/UseSupportChannels for ways to get help.
 Thanks!

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

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

[Django] #23921: Can't hide a hidden field in the django admin

2014-11-26 Thread Django

#23921: Can't hide a hidden field in the django admin
---+
 Reporter:  DoctorMalboro  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Forms  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have a form in django 1.6.5 like this:

 {{{
 #!python
 class ExampleForm(forms.ModelForm):

id_image = forms.CharField(widget=forms.HiddenInput())
image = forms.ImageField(widget=CustomImageUploader())

# Tried this
 def __init__(self, *args, **kwargs):
 super(ExampleForm, self).__init__(*args, **kwargs)
 if self.instance and self.instance.pk:
 self.fields['id_image'].widget = forms.HiddenInput()

class Meta:
   fields = ('id_image', 'image',)
 }}}

 And I couldn't find a way to hide the form in the django's admin. I can't
 exclude it because I have a custom form with a javascript function that
 fills the id_image field, so the only way I have to do this is by hiding
 the value, because it doesn't look nice for the end user.

--
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/056.1c545a82facbeed9ec71ae4f1dff7327%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23792: Create contextmanager to freeze time.time() in tests (was: Random test failure of TestCookieStorage.test_reset_cookie)

2014-11-26 Thread Django

#23792: Create contextmanager to freeze time.time() in tests
--+
 Reporter:  tchaumeny |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * component:  Uncategorized => Testing framework
 * stage:  Unreviewed => Accepted


Comment:

 The contextmanager approach looks good, but formtools is being split into
 a separate repo (#23677). If formtools is going to use this, then I guess
 we should make this a public API. What do you think?

 I created [https://github.com/django/django-formtools/issues/30 a ticket
 in the django-formtools] issue tracker.

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

Re: [Django] #23677: Move django.contrib.formtools to own repo and packaged app

2014-11-26 Thread Django

#23677: Move django.contrib.formtools to own repo and packaged app
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  contrib.formtools|   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 Tim Graham ):

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


Comment:

 In [changeset:"14a3b60981f63334520c713bb3a2c9c694c49a1f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="14a3b60981f63334520c713bb3a2c9c694c49a1f"
 Fixed #23677 -- Removed contrib.formtools
 }}}

--
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.7159b783fa17c4147e383fe84b162510%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23901: Unable to load the SpatiaLite library extension "/usr/local/lib/libspatialite.dylib"

2014-11-26 Thread Django

#23901: Unable to load the SpatiaLite library extension
"/usr/local/lib/libspatialite.dylib"
--+
 Reporter:  kenial|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  spatialite| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_docs:  1 => 0
 * has_patch:  0 => 1
 * 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/064.7eb2106441a700df70e3ecac77a4e061%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23677: Move django.contrib.formtools to own repo and packaged app

2014-11-26 Thread Django

#23677: Move django.contrib.formtools to own repo and packaged app
-+-
 Reporter:  jezdez   |Owner:  jezdez
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  contrib.formtools|   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
-+-

Comment (by Tim Graham ):

 In [changeset:"6302893112a67343b3f5eff3f09f91b245346877"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6302893112a67343b3f5eff3f09f91b245346877"
 Updated formtools docs to point at new package outside the Django repo.

 Refs #23677.
 }}}

--
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.379f5bf38324cda7e68afd5de997f216%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23913: = comparison does work in templates although it shouldn't

2014-11-26 Thread Django

#23913: = comparison does work in templates although it shouldn't
-+-
 Reporter:  googol7  |Owner:
 Type:   |  olasitarska
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  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 googol7):

 BTW - I used this grep now to find occurrences in our code:

 grep -e "if \w*[[:space:]]*=\{1\}[^=]" . -H -r -i -n -s -C 1
 --include=*.{htm*,}

--
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.892b618be5b4b8e4097e4e6a0d8e496b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23903: Update docs/man/django-admin.1 (was: Remove (or update) docs/man/django-admin.1)

2014-11-26 Thread Django

#23903: Update docs/man/django-admin.1
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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 timgraham):

 * stage:  Unreviewed => Accepted


Comment:

 On the mailing list thread it was noted that sphinx should be able to
 build a man page automatically from the reStructuredText documentation.

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

Re: [Django] #23337: CircularDependencyError when squashing migrations

2014-11-26 Thread Django

#23337: CircularDependencyError when squashing migrations
+
 Reporter:  Naddiseo|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Ian-Foote):

 * cc: python@… (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/066.0d029c1964d5cc6fba9411ee1597aa98%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23920: MySQL: migrate TextField() to TextField(blank=True) fails

2014-11-26 Thread Django

#23920: MySQL: migrate TextField() to TextField(blank=True) fails
---+
 Reporter:  wkornewald |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When adding blank=True to an existing TextField and running manage.py
 makemigrations and manage.py migrate with MySQL I get the following error:

 BLOB/TEXT column 'sometextfield' can't have a default value

 BTW, why do changes to blank require new migrations?

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

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

44 matches

Mail list logo