date:20151107

Re: [Django] #25708: cannot annotate with geometry value

2015-11-07 Thread Django

#25708: cannot annotate with geometry value
---+--
 Reporter:  sir-sigurd |Owner:  sir-sigurd
 Type:  Uncategorized  |   Status:  assigned
Component:  GIS|  Version:  1.8
 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 sir-sigurd):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * owner:  nobody => sir-sigurd
 * 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/068.2df34ccec9b568133506de1d9f0f2fba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25708: cannot annotate with geometry value

2015-11-07 Thread Django

#25708: cannot annotate with geometry value
---+
 Reporter:  sir-sigurd |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  GIS|Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 {{{
 In [4]: Test.objects.annotate(p=Value(Point(1,1),
 output_field=GeometryField()))
 Out[4]:
 ---
 ProgrammingError  Traceback (most recent call
 last)
 /home/sergey/tmp/django-venv/local/lib/python2.7/site-
 packages/IPython/core/formatters.pyc in __call__(self, obj)
 693 type_pprinters=self.type_printers,
 694 deferred_pprinters=self.deferred_printers)
 --> 695 printer.pretty(obj)
 696 printer.flush()
 697 return stream.getvalue()

 /home/sergey/tmp/django-venv/local/lib/python2.7/site-
 packages/IPython/lib/pretty.pyc in pretty(self, obj)
 399 if callable(meth):
 400 return meth(obj, self, cycle)
 --> 401 return _default_pprint(obj, self, cycle)
 402 finally:
 403 self.end_group()

 /home/sergey/tmp/django-venv/local/lib/python2.7/site-
 packages/IPython/lib/pretty.pyc in _default_pprint(obj, p, cycle)
 519 if _safe_getattr(klass, '__repr__', None) not in
 _baseclass_reprs:
 520 # A user-provided repr. Find newlines and replace them
 with p.break_()
 --> 521 _repr_pprint(obj, p, cycle)
 522 return
 523 p.begin_group(1, '<')

 /home/sergey/tmp/django-venv/local/lib/python2.7/site-
 packages/IPython/lib/pretty.pyc in _repr_pprint(obj, p, cycle)
 701 """A pprint that just redirects to the normal repr
 function."""
 702 # Find newlines and replace them with p.break_()
 --> 703 output = repr(obj)
 704 for idx,output_line in enumerate(output.splitlines()):
 705 if idx:

 /home/sergey/dev/django/django/db/models/query.pyc in __repr__(self)
 232
 233 def __repr__(self):
 --> 234 data = list(self[:REPR_OUTPUT_SIZE + 1])
 235 if len(data) > REPR_OUTPUT_SIZE:
 236 data[-1] = "...(remaining elements truncated)..."

 /home/sergey/dev/django/django/db/models/query.pyc in __iter__(self)
 256- Responsible for turning the rows into model
 objects.
 257 """
 --> 258 self._fetch_all()
 259 return iter(self._result_cache)
 260

 /home/sergey/dev/django/django/db/models/query.pyc in _fetch_all(self)
1072 def _fetch_all(self):
1073 if self._result_cache is None:
 -> 1074 self._result_cache = list(self.iterator())
1075 if self._prefetch_related_lookups and not
 self._prefetch_done:
1076 self._prefetch_related_objects()

 /home/sergey/dev/django/django/db/models/query.pyc in __iter__(self)
  50 # Execute the query. This will also fill compiler.select,
 klass_info,
  51 # and annotations.
 ---> 52 results = compiler.execute_sql()
  53 select, klass_info, annotation_col_map = (compiler.select,
 compiler.klass_info,
  54
 compiler.annotation_col_map)

 /home/sergey/dev/django/django/db/models/sql/compiler.pyc in
 execute_sql(self, result_type)
 837 cursor = self.connection.cursor()
 838 try:
 --> 839 cursor.execute(sql, params)
 840 except Exception:
 841 cursor.close()

 /home/sergey/dev/django/django/db/backends/utils.pyc in execute(self, sql,
 params)
  77 start = time()
  78 try:
 ---> 79 return super(CursorDebugWrapper, self).execute(sql,
 params)
  80 finally:
  81 stop = time()

 /home/sergey/dev/django/django/db/backends/utils.pyc in execute(self, sql,
 params)
  62 return self.cursor.execute(sql)
  63 else:
 ---> 64 return self.cursor.execute(sql, params)
  65
  66 def executemany(self, sql, param_list):

 /home/sergey/dev/django/django/db/utils.pyc in __exit__(self, exc_type,
 exc_value, traceback)
  90 if dj_exc_type not in (DataError, IntegrityError):
  91 self.wrapper.errors_occurred = True
 ---> 92 six.reraise(dj_exc_type, dj_exc_value, traceback)
  93
  94 def __call__(self, func):

 /home/sergey/dev/django/django/db/backends/utils.pyc in execute(self, sql,
 params)
  62 return self.cursor.execute(sql)
  63 else:
 ---> 64 return self.cursor.execute(sql, params)
  65
  66 def ex

Re: [Django] #25544: prefetch_related sends duplicate ids to database

2015-11-07 Thread Django

#25544: prefetch_related sends duplicate ids to database
-+-
 Reporter:  spectras |Owner:  Ian-Foote
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch duplicate   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 @carljm, what do you think of simply special casing `ArrayField`'s `__in`
 lookup which is something we already do for `__exact` anyway.

 Something like the following comes to mind.

 {{{#!python
 @ArrayField.register_lookup
 class ArrayInLookup(InLookup):
 def get_prep_lookup(self):
 values = super(ArrayInLookup, self).get_prep_lookup()
 return [tuple(value) for value in values]
 }}}

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

Re: [Django] #25653: Provide a way to run only the selenium tests

2015-11-07 Thread Django

#25653: Provide a way to run only the selenium tests
---+
 Reporter:  timgraham  |Owner:  mrbox
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  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
---+
Changes (by carljm):

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


Comment:

 Yes, I think you're right. The patch is small and useful, and I don't
 think switching to nose or py.test is a good or feasible plan in the
 medium-term anyway (posted more rationale for that just now in #25707).

 PR just needs some cleanup, and there's a question about whether we want
 an `--exclude-tags` flag as well. I think probably we'll end up wanting
 it, but it could also always be added later if we do.

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

Re: [Django] #25467: Excluding an object with no ID excludes everything.

2015-11-07 Thread Django

Comment (by skorokithakis):

I think that thinking about this in terms of the value of the ID field is
misleading. The ID value being None is just an implementation detail, it
could very well be the future numeric ID (if Django could know this before
talking to the DB), in which case the query would become
`.exclude(related_field=)`, which matches
the intuitive reasoning behind that `exclude` call.

For that reason, i would strongly suggest option (a) that you mentioned
over the other two.

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

Re: [Django] #25467: Excluding an object with no ID excludes everything.

2015-11-07 Thread Django

#25467: Excluding an object with no ID excludes everything.
-+-
 Reporter:  skorokithakis|Owner:
 |  HuffAndPuff
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 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 carljm):

 Some more musings on this:

 Our strongest existing precedent for the meaning of `None` in an ORM
 comparison is that `__exact=None` is equivalent to `__isnull=True`, or SQL
 `IS NULL`.

 If we accept that as a consistent semantic, it would imply that we should
 fix `__in=[val, None]` generally (not just for related fields) to remove
 the `None` from the `in` list and add an `OR IS NULL` clause alongside it.
 This seems better than the current behavior to me, but perhaps low
 priority.

 It would also imply that `.exclude(related_field=unsaved_instance)` would
 exclude records where the `related_field` FK is `NULL`. This is subtly
 different from the OPs requested behavior, which is that such an `exclude`
 would never exclude anything. I find the latter behavior (to consider
 `unsaved_instance` to match nothing, rather than matching NULL) more
 intuitive. Which means we  either a) use different semantics for instance-
 with-None-pk in comparisons than we use for `None` in comparisons
 otherwise, b) accept a less-intuitive behavior for instance-with-None-pk
 for consistency with use of `None` elsewhere, or c) declare that the
 choice between (a) and (b) is too ambiguous (that I was wrong earlier when
 I said "there's no ambiguity"), and therefore we should just raise an
 exception after all.

 I think I would put these in preference order (a) (c) (b), but could live
 with any of them; and complexity-of-implementation could easily sway me to
 prefer (c) over (a).

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

Re: [Django] #25707: Use py.test for internal testing

2015-11-07 Thread Django

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

Comment:

I've certainly had the same thought; in the abstract, I don't think it
makes much sense for us to be maintaining our own test runner atop
unittest when there are well-maintained existing runners with similar
features. But unless we are ready to tell the entire Django community they
must start using py.test, the change would need to only affect internal
testing. In that case we are still maintaining a custom test runner (for
users of Django), just no longer dogfooding it ourselves. That seems like
an unfortunate situation, and not much of a win. We have a lot of test
utilities which in a pytest world ought to be rewritten as pytest
fixtures, but then they are no longer available to non-pytest users.

So I can't really see how the change practically works until/unless we are
ready to just say "the blessed way of doing all Django testing is with
py.test." I'd be ok with that in theory - I think py.test is a very good
test runner, and it could be seen as another svn/git/hg situation, where
we should just make a choice (even if controversial) rather than muddling
along with the lowest common denominator. But it would be the second
recent big breaking change to testing (1.6 DiscoverRunner being the last);
I don't want to put the community through another change like that right
now, and I don't think the support is there in the core team to do it.
(It's a bigger change in a way than svn/git/hg, since that one didn't
affect non-contributor users at all).

So, reluctantly, I have to say that despite some possible benefits, I
don't think this is likely to happen anytime soon. Moving into the
Someday/maybe category.

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

[Django] #25707: Use py.test for internal testing

2015-11-07 Thread Django

#25707: Use py.test for internal testing
---+
 Reporter:  olethanh   |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Testing framework  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 pytest (or py.test ) offer some nice options that the current runtests.py
 script does not, for example: dropping into a debugger in case of error or
 a more accurate tests selection and more readable error reporting.
 It also allow custom plugin and validation (e.g. pep8 and flake) and is
 becoming more and more standard in the Python community so new comer could
 use a tool they already know how to use.

 So maybe we should discuss using it instead of the current homegrown
 solution?

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

Re: [Django] #25544: prefetch_related sends duplicate ids to database

2015-11-07 Thread Django

Comment (by carljm):

@IanFoote Oops, my fault. I didn't consider the possibility that non-
hashable values (e.g. lists for an ArrayField) could be passed to `__in`
lookups. I don't really see a way to preserve this fix in the face of that
possibility (going through the value and trying to convert everything to
something hashable doesn't seem like a good plan), so unless you have any
ideas I'm not seeing, I think we may need to revert to your previous fix
at the `prefetch_related` layer.

Sorry for the bad direction!

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

Re: [Django] #25706: Support CSP default-src 'self' on Django Admin GIS

2015-11-07 Thread Django

#25706: Support CSP default-src 'self' on Django Admin GIS
-+-
 Reporter:  graingert|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  CSP inline   | Triage Stage:
  javascript |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by graingert:

Old description:

> Currently there's work (https://github.com/django/django/pull/5567) to
> comply with Content-Security-Policy: default-src 'self' on the base
> admin.
>
> It's going to require further re-factoring to apply the same to django
> GIS
>
> This change will also require the addition of Selenium tests for the
> Django GIS Admin
>
> See also #15727

New description:

 Currently there's work (https://github.com/django/django/pull/5567) to
 comply with Content-Security-Policy: default-src 'self' on the base admin.

 It's going to require further re-factoring to apply the same to django GIS

 This change will also require the addition of Selenium tests for the
 Django Admin GIS UI
 See also #15727

--

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

Re: [Django] #25706: Support CSP default-src 'self' on Django Admin GIS

2015-11-07 Thread Django

#25706: Support CSP default-src 'self' on Django Admin GIS
-+-
 Reporter:  graingert|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  CSP inline   | Triage Stage:
  javascript |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by graingert:

Old description:

> Currently there's work (https://github.com/django/django/pull/5567) to
> comply with Content-Security-Policy: default-src 'self' on the base
> admin.
>
> It's going to require further re-factoring to apply the same to django
> GIS
>
> This change will also require the addition of Selenium tests for the
> Django
>
> See also #15727

New description:

 Currently there's work (https://github.com/django/django/pull/5567) to
 comply with Content-Security-Policy: default-src 'self' on the base admin.

 It's going to require further re-factoring to apply the same to django GIS

 This change will also require the addition of Selenium tests for the
 Django GIS Admin

 See also #15727

--

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

Re: [Django] #25706: Support CSP default-src 'self' on Django Admin GIS

2015-11-07 Thread Django

#25706: Support CSP default-src 'self' on Django Admin GIS
-+-
 Reporter:  graingert|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  CSP inline   | Triage Stage:
  javascript |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by graingert):

 * keywords:   => CSP inline javascript
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> Currently there's work to comply with Content-Security-Policy: default-
> src 'self' on the base admin.
>
> It's going to require further re-factoring to apply the same to django
> GIS
>
> This change will also require the addition of Selenium tests for the
> Django

New description:

 Currently there's work (https://github.com/django/django/pull/5567) to
 comply with Content-Security-Policy: default-src 'self' on the base admin.

 It's going to require further re-factoring to apply the same to django GIS

 This change will also require the addition of Selenium tests for the
 Django

 See also #15727

--

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

[Django] #25706: Support CSP default-src 'self' on Django Admin GIS

2015-11-07 Thread Django

#25706: Support CSP default-src 'self' on Django Admin GIS
---+
 Reporter:  graingert  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Currently there's work to comply with Content-Security-Policy: default-src
 'self' on the base admin.

 It's going to require further re-factoring to apply the same to django GIS

 This change will also require the addition of Selenium tests for the
 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/052.1206ac42c0aeb889a0d069bcaf41710f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25680: Feature request: support python manage.py shell -e 'run_some_code_as_django()'

2015-11-07 Thread Django

#25680: Feature request: support python manage.py shell -e
'run_some_code_as_django()'
-+-
 Reporter:  hakanw   |Owner:
 |  nielsvanoch
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  1.8
  commands)  |
 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 nielsvanoch):

 * Attachment "add_command_option_to_shell.diff.txt" 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/064.7faadf544429a16bab319ddbff3ff6e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #8936: admin databrowse (read-only view-only permissions)

2015-11-07 Thread Django

#8936: admin databrowse (read-only view-only permissions)
---+--
 Reporter:  simon  |Owner:  PetrDlouhy
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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 collinanderson):

 This would solve #11561 (raw_id_fields requires that the user has change
 permissions on the model class that is being linked to)

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

Re: [Django] #8936: admin databrowse (read-only view-only permissions) (was: add databrowse-like functionality to the admin)

2015-11-07 Thread Django

#8936: admin databrowse (read-only view-only permissions)
---+--
 Reporter:  simon  |Owner:  PetrDlouhy
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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
---+--
Changes (by collinanderson):

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

Re: [Django] #25705: Parameters are not adapted or quoted in Query.str

2015-11-07 Thread Django

#25705: Parameters are not adapted or quoted in Query.__str__
-+-
 Reporter:  Stranger6667 |Owner:
 Type:   |  Stranger6667
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Stranger6667):

 Commit:
 
https://github.com/Stranger6667/django/commit/b2e36668a6877fe29923493e5669402dd30d6421
 This issue is more general case of #24991

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

Re: [Django] #25705: Parameters are not adapted or quoted in Query.str

2015-11-07 Thread Django

#25705: Parameters are not adapted or quoted in Query.__str__
-+-
 Reporter:  Stranger6667 |Owner:
 Type:   |  Stranger6667
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Stranger6667):

 * Attachment "ticket25705.patch" added.

 Initial draft

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

Re: [Django] #25705: Parameters are not adapted or quoted in Query.str

2015-11-07 Thread Django

#25705: Parameters are not adapted or quoted in Query.__str__
-+-
 Reporter:  Stranger6667 |Owner:
 Type:   |  Stranger6667
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Stranger6667):

 * status:  new => assigned
 * needs_better_patch:   => 1
 * needs_tests:   => 1
 * owner:  nobody => Stranger6667
 * needs_docs:   => 0
 * 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/070.55568e0060890eee870e1bae4b9d96a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25705: Parameters are not adapted or quoted in Query.str

2015-11-07 Thread Django

#25705: Parameters are not adapted or quoted in Query.__str__
--+
 Reporter:  Stranger6667  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Now it is just string interpolation of the SQL template with parameters
 and in most cases produces invalid queries for the following reasons:

 - No quoting
 - No adaptation. So, some python objects will be used as is, not like
 their SQL equivalents

 Yes, there are situations, when output of `Query.__str__` is equal to
 actual query. But for debugging reasons, it will be better to see real
 query here. Also it is logical and expected behavior of this method - to
 show actual query.

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

Re: [Django] #2651: ForeignKey search/filter/autocomplete widget

2015-11-07 Thread Django

#2651: ForeignKey search/filter/autocomplete widget
-+-
 Reporter:  zaur |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  FilterSelector   | Triage Stage:  Accepted
  filter_interface nfa   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by collinanderson):

 patch using select2: https://github.com/django/django/pull/5609

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

Re: [Django] #14370: Adding support for Autocomplete in contrib.admin

2015-11-07 Thread Django

#14370: Adding support for Autocomplete in contrib.admin
-+-
 Reporter:  tyrion   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  autocomplete,| Triage Stage:  Accepted
  jquery, javascript, widgets,   |
  admin  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-

Comment (by collinanderson):

 patch using select2: https://github.com/django/django/pull/5609

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

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

2015-11-07 Thread Django

#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  assigned
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by fcurella):

 According to https://docs.djangoproject.com/en/1.8/topics/logging/#django-
 request-logger, the logger should be under `django.request`. Additionally,
 4xx should warning and 5xx should be errors.

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

2015-11-07 Thread Django

#23714: `date` filter raises an exception for naive datetimes during DST change
-+
 Reporter:  mbertheau|Owner:
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Aymeric Augustin ):

 In [changeset:"94d13415d81f24743045bcaa43027c737e2bcf5f" 94d1341]:
 {{{
 #!CommitTicketReference repository=""
 revision="94d13415d81f24743045bcaa43027c737e2bcf5f"
 [1.8.x] Fixed debug view crash during autumn DST change.

 This only happens if USE_TZ = False and pytz is installed (perhaps not
 the most logical combination, but who am I to jugde?)

 Refs #23714 which essentially fixed the same problem when USE_TZ = True.

 Thanks Florian and Carl for insisting until I wrote a complete patch.

 Backport of 1014ba026e 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/067.d8f4e9fc6509cdc8a6dfc245d1ed645b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

2015-11-07 Thread Django

#23714: `date` filter raises an exception for naive datetimes during DST change
-+
 Reporter:  mbertheau|Owner:
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Aymeric Augustin ):

 In [changeset:"1014ba026e879e56e0f265a8d9f54e6f39843348" 1014ba02]:
 {{{
 #!CommitTicketReference repository=""
 revision="1014ba026e879e56e0f265a8d9f54e6f39843348"
 Fixed debug view crash during autumn DST change.

 This only happens if USE_TZ = False and pytz is installed (perhaps not
 the most logical combination, but who am I to jugde?)

 Refs #23714 which essentially fixed the same problem when USE_TZ = True.

 Thanks Florian and Carl for insisting until I wrote a complete 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/067.0a256958a73992891d4cab79c40ae169%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25469: Add an auto escape setting to the Django template engine

2015-11-07 Thread Django

#25469: Add an auto escape setting to the Django template engine
-+
 Reporter:  aidanlister  |Owner:  jgeskens
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  templates| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * Attachment "autoescape-setting.patch" 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.6a63c4084d7e975ce0aecb0621018a0e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25469: Add an auto escape setting to the Django template engine

2015-11-07 Thread Django

#25469: Add an auto escape setting to the Django template engine
-+
 Reporter:  aidanlister  |Owner:  jgeskens
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  templates| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 I discussed this with aaronelliotross at the very end of the DutH sprints
 and quickly wrote a tentative implementation, which I'm attaching to this
 ticket. Aaron was planning to try it and write tests. You should attempt
 to coordinate in order not to duplicate efforts.

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

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

2015-11-07 Thread Django

#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  assigned
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by andreif):

 I've just realized that this feature will finally allow to filter out
 static requests using logging filters instead of messing in the Django
 source code. This is great! :)

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

Re: [Django] #24424: Removing a model's last field results in SQL syntax error (was: Removing a model's last field results in SQL syntax error on SQLite)

2015-11-07 Thread Django

#24424: Removing a model's last field results in SQL syntax error
+
 Reporter:  adnam   |Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 charettes):

 Note that the issue also exists for MySQL.

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

Re: [Django] #25698: App without migrations depending on app with migrations fails on initial migrate call (postgres)

2015-11-07 Thread Django

#25698: App without migrations depending on app with migrations fails on initial
migrate call (postgres)
--+--
 Reporter:  lucasmoeskops |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:  invalid
 Keywords:  migrate postgres  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by timgraham):

 I think improving the error message (about missing migrations) is tracked
 in #24484.

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

Re: [Django] #25531: Document the fact that admin_order_field allows query lookups

2015-11-07 Thread Django

#25531: Document the fact that admin_order_field allows query lookups
-+-
 Reporter:  rfleschenberg|Owner:
 Type:   |  Gayathrimenakath
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  admin_order_field| Triage Stage:  Accepted
  sort related list_display  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #25531: Document the fact that admin_order_field allows query lookups

2015-11-07 Thread Django

#25531: Document the fact that admin_order_field allows query lookups
-+-
 Reporter:  rfleschenberg|Owner:
 Type:   |  Gayathrimenakath
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  admin_order_field| Triage Stage:  Accepted
  sort related list_display  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by rfleschenberg):

 I had some spare time today and took the liberty to submit a pull request
 for this (5608). I hope you don't mind, Gayathrimenakath :)

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

Re: [Django] #25473: Consistently use dashes instead of underscores in URL names

2015-11-07 Thread Django

#25473: Consistently use dashes instead of underscores in URL names
-+-
 Reporter:  guettli  |Owner:
 Type:   |  thijsvandien
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"78a28cca200e6e03432bab9bf73856b8f778c6f0" 78a28cca]:
 {{{
 #!CommitTicketReference repository=""
 revision="78a28cca200e6e03432bab9bf73856b8f778c6f0"
 [1.8.x] Fixed #25473 -- Changed underscores in url() names to dashes in
 docs.

 To improve consistency, sample URL names that had underscores
 in them now use dashes instead. That excludes URL names that
 have some relation to the code, such as those generated by
 the admin.

 Thanks guettli for reporting this.

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

Re: [Django] #25473: Consistently use dashes instead of underscores in URL names

2015-11-07 Thread Django

#25473: Consistently use dashes instead of underscores in URL names
-+-
 Reporter:  guettli  |Owner:
 Type:   |  thijsvandien
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"f5e1d72de2e111ef2449f858b672c9cf4ecbb9ff" f5e1d72]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5e1d72de2e111ef2449f858b672c9cf4ecbb9ff"
 [1.9.x] Fixed #25473 -- Changed underscores in url() names to dashes in
 docs.

 To improve consistency, sample URL names that had underscores
 in them now use dashes instead. That excludes URL names that
 have some relation to the code, such as those generated by
 the admin.

 Thanks guettli for reporting this.

 Backport of 1679472165e840aef4c8c9ece2fbf4620b87beab 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.2163ddbd8db2f76e69f80b8a41b54536%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25473: Consistently use dashes instead of underscores in URL names

2015-11-07 Thread Django

#25473: Consistently use dashes instead of underscores in URL names
-+-
 Reporter:  guettli  |Owner:
 Type:   |  thijsvandien
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"1679472165e840aef4c8c9ece2fbf4620b87beab" 16794721]:
 {{{
 #!CommitTicketReference repository=""
 revision="1679472165e840aef4c8c9ece2fbf4620b87beab"
 Fixed #25473 -- Changed underscores in url() names to dashes in docs.

 To improve consistency, sample URL names that had underscores
 in them now use dashes instead. That excludes URL names that
 have some relation to the code, such as those generated by
 the admin.

 Thanks guettli for reporting 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/065.8a44c713c07f18041d24892c9fb08d80%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24424: Removing a model's last field results in SQL syntax error on SQLite

2015-11-07 Thread Django

#24424: Removing a model's last field results in SQL syntax error on SQLite
+
 Reporter:  adnam   |Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 timgraham):

 #25690 is a duplicate.

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

Re: [Django] #25690: Migration operations should be ordered to prevent all columns from being removed

2015-11-07 Thread Django

#25690: Migration operations should be ordered to prevent all columns from being
removed
+--
 Reporter:  mcrowson|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  mysql   | 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
 * resolution:   => duplicate


Comment:

 Duplicate of #24424

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

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

2015-11-07 Thread Django

#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  assigned
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by andreif):

 1. I believe it would be better to use `django.server` instead of
 `django.request.runserver` for logger name:

 {{{
 INFOdjango.server: [07/Nov/2015 20:38:22] "GET / HTTP/1.1" 200 2
 }}}
 vs
 {{{
 INFOdjango.request.runserver: [07/Nov/2015 20:38:22] "GET / HTTP/1.1"
 200 2
 }}}

 2. The date-time should probably not be a part of the message since it's
 usually configured in formatter. However, by default python logs without
 time info. Maybe `LOGGING` dict in `global_settings.py` can have
 `django.server` logging config...

 {{{
 2015-11-07 20:38:22,627 INFO  django.server: [07/Nov/2015 20:38:22] "GET /
 HTTP/1.1" 200 2
 }}}

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

Re: [Django] #25704: Response time in WSGIRequestHandler.log_request

2015-11-07 Thread Django

#25704: Response time in WSGIRequestHandler.log_request
---+
 Reporter:  andreif|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by andreif):

 If #25684 will change order of parts in the log message, we could have
 something like

 {{{
 [07/Nov/2015 17:37:05] HTTP/1.1 200 "GET /inbox/" 216874 5301ms
 [07/Nov/2015 17:37:05] HTTP/1.1 304 "GET
 /static/CACHE/css/f090a416387d.css" 0 4ms
 [07/Nov/2015 17:37:05] HTTP/1.1 304 "GET
 /static/CACHE/css/df20af4b0d04.css" 0 3ms
 [07/Nov/2015 17:37:05] HTTP/1.1 304 "GET /static/img/logo.svg" 0 2ms
 }}}

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

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

2015-11-07 Thread Django

#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  assigned
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by andreif):

 It would also be great to have response time in the log message, see
 #25704

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

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

2015-11-07 Thread Django

#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  assigned
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by andreif):

 It would be great if we could place the response code at the beginning of
 the log message ;)

 so it is

 {{{
 [07/Nov/2015 17:37:05] HTTP/1.1 200 "GET /inbox/" 216874
 [07/Nov/2015 17:37:05] HTTP/1.1 304 "GET
 /static/CACHE/css/f090a416387d.css" 0
 [07/Nov/2015 17:37:05] HTTP/1.1 304 "GET
 /static/CACHE/css/df20af4b0d04.css" 0
 [07/Nov/2015 17:37:05] HTTP/1.1 304 "GET /static/img/logo.svg" 0
 }}}

 instead of

 {{{
 [07/Nov/2015 17:37:05] "GET /inbox/ HTTP/1.1" 200 216874
 [07/Nov/2015 17:37:05] "GET /static/CACHE/css/f090a416387d.css HTTP/1.1"
 304 0
 [07/Nov/2015 17:37:05] "GET /static/CACHE/css/df20af4b0d04.css HTTP/1.1"
 304 0
 [07/Nov/2015 17:37:05] "GET /static/img/logo.svg HTTP/1.1" 304 0 0ms 2ms
 }}}

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

Re: [Django] #19536: in ModelAdmin disabling has_add_permission results in not showing any object-tools

2015-11-07 Thread Django

#19536: in ModelAdmin disabling has_add_permission results in not showing any
object-tools
--+
 Reporter:  a.fazeli@…|Owner:  ikks
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  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
--+
Changes (by timgraham):

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


Comment:

 Left some minor comments.

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

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

Re: [Django] #25692: Add natural keys support to Site model

2015-11-07 Thread Django

#25692: Add natural keys support to Site model
-+-
 Reporter:  j0hnsmith|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.sites|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"0115f9faa517bba882a31b0ade076601b5a41de6" 0115f9fa]:
 {{{
 #!CommitTicketReference repository=""
 revision="0115f9faa517bba882a31b0ade076601b5a41de6"
 Fixed #25692 -- Added natural keys support to Site model.
 }}}

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

Re: [Django] #25704: Response time in WSGIRequestHandler.log_request

2015-11-07 Thread Django

#25704: Response time in WSGIRequestHandler.log_request
---+
 Reporter:  andreif|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by andreif):

 Example of time:

 {{{
 [07/Nov/2015 17:37:05] "GET /inbox/ HTTP/1.1" 200 216874 0ms 5301ms
 [07/Nov/2015 17:37:05] "GET /static/CACHE/css/f090a416387d.css HTTP/1.1"
 304 0 0ms 4ms
 [07/Nov/2015 17:37:05] "GET /static/CACHE/css/df20af4b0d04.css HTTP/1.1"
 304 0 0ms 3ms
 [07/Nov/2015 17:37:05] "GET /static/img/logo.svg HTTP/1.1" 304 0 0ms 2ms
 }}}

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

Re: [Django] #20846: Increase contrib.auth's User.username length

2015-11-07 Thread Django

#20846: Increase contrib.auth's User.username length
-+
 Reporter:  ivoras@… |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   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 collinanderson):

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

Re: [Django] #25704: Response time in WSGIRequestHandler.log_request

2015-11-07 Thread Django

#25704: Response time in WSGIRequestHandler.log_request
---+
 Reporter:  andreif|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by charettes):

 By kwargs I meant using the `extra` kwarg of `logger.log()`.

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

Re: [Django] #25701: Add warning to an admin list_view if too many queries are being used

2015-11-07 Thread Django

#25701: Add warning to an admin list_view if too many queries are being used
---+--
 Reporter:  jacinda|Owner:  jacinda
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timgraham):

 After some thought, I'm a bit hesitant to duplicate functionality (to some
 extent) provided by django-debug-toolbar. I think there's consensus to
 recommend that package in the docs (perhaps in the tutorial). While this
 will require the developer to understand things at a slightly deeper
 level, it seems like a more teachable solution in the long run. What do
 you think?

 One partial solution would be to use the checks framework (at the INFO
 level, perhaps) to detect relations in `list_display` that aren't in
 `list_select_related`. Of course this won't cover O(n) queries in
 callables, but I'm not yet convinced a more sophisticated solution is
 worthwhile. I guess your proposal would only work in DEBUG mode (which
 makes sense to me since we probably wouldn't want end users to see the
 warning) since `connection.queries` is disabled otherwise.

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

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

Re: [Django] #25704: Response time in WSGIRequestHandler.log_request

2015-11-07 Thread Django

#25704: Response time in WSGIRequestHandler.log_request
---+
 Reporter:  andreif|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by andreif):

 Kwarg sounds fine to me, but in this case we need kwargs for the other
 parts which requires overriding `log_request` instead of `log_format`. I
 this is ok then I will make a PR to #25684
 (https://github.com/fcurella/django/tree/runserver-logging) to help with
 the change. As soon as it's done, adding response time should be trivial.

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

Re: [Django] #25469: Add an auto escape setting to the Django template engine

2015-11-07 Thread Django

#25469: Add an auto escape setting to the Django template engine
-+
 Reporter:  aidanlister  |Owner:  jgeskens
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  templates| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by jgeskens):

 Ok, I understand the vision. I will create a new patch :-) Thanks for the
 review!

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

Re: [Django] #20846: Increase contrib.auth's User.username length

2015-11-07 Thread Django

#20846: Increase contrib.auth's User.username length
-+
 Reporter:  ivoras@… |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   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 collinanderson):

 * status:  closed => new
 * resolution:  fixed =>
 * severity:  Normal => Release blocker


Comment:

 Yeah, we should really fix this, ideally by resolving #18392. (hint: add a
 DATABASES OPTIONS on mysql for max index length that defaults to either
 191 or 255.) I was under the impression that utf8mb4 _really_ didn't work
 with django but apparently you can get by ok besides this 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/074.b4d16a5a06dcc52c12f1cb0a3c615d5d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15727: Add support for Content-Security-Policy (CSP) to core

2015-11-07 Thread Django

#15727: Add support for Content-Security-Policy (CSP) to core
---+
 Reporter:  db.pub.mail@…  |Owner:  Rudolph
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timgraham):

 The work to remove inline JavaScript in the admin is tracked in #25165.

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

Re: [Django] #25704: Response time in WSGIRequestHandler.log_request

2015-11-07 Thread Django

#25704: Response time in WSGIRequestHandler.log_request
---+
 Reporter:  andreif|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by andreif):

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

Re: [Django] #25702: Port ModelAdmin.fieldset to BaseForm

2015-11-07 Thread Django

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

Comment:

This looks like a duplicate of #6630. I have to say I agree with Carl that
formsets are too much display logic in Python.

They make a bit more sense at the admin level since you want a quick an
dirty way to order your fields without having to write a template.

In the case of forms efforts have been made to move the whole logic to the
template level and eventually deprecate the `as_(p|table|ul)` methods
which are the only methods that would rely on this option.

If you disagree with these ticket resolutions please voice your opinion on
the developer mailing list. In the meanwhile I'll just mark this ticket as
a duplicate.

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

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

Re: [Django] #25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval" warnings

2015-11-07 Thread Django

#25165: Move JavaScript calls out of HTML to fix JavaScript "no-script-eval"
warnings
--+
 Reporter:  timgraham |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  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):

 * status:  assigned => new
 * owner:  zedr =>
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/5567 PR]

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

Re: [Django] #25290: Warn against modifying objects created in setUpTestData

2015-11-07 Thread Django

#25290: Warn against modifying objects created in setUpTestData
-+-
 Reporter:  MarkusH  |Owner:
 Type:   |  Anjaliunni96
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"bd55e8063544e0f7990bab7d9c981a6dc22c1654" bd55e80]:
 {{{
 #!CommitTicketReference repository=""
 revision="bd55e8063544e0f7990bab7d9c981a6dc22c1654"
 [1.8.x] Fixed #25290 -- Warned against modifying objects created in
 setUpTestData() in tests.

 Backport of 81006b9657534a21c3eadb2bc4a87c46db54c099 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.2a55b732dc3d8092093c0cd61a639d99%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25290: Warn against modifying objects created in setUpTestData

2015-11-07 Thread Django

#25290: Warn against modifying objects created in setUpTestData
-+-
 Reporter:  MarkusH  |Owner:
 Type:   |  Anjaliunni96
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"1eb2ff3ff75b0f08276e0c3e10c99ed111572d8c" 1eb2ff3]:
 {{{
 #!CommitTicketReference repository=""
 revision="1eb2ff3ff75b0f08276e0c3e10c99ed111572d8c"
 [1.9.x] Fixed #25290 -- Warned against modifying objects created in
 setUpTestData() in tests.

 Backport of 81006b9657534a21c3eadb2bc4a87c46db54c099 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.5cd3669a17cd2d6854076e987608a654%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25704: Response time in WSGIRequestHandler.log_request

2015-11-07 Thread Django

#25704: Response time in WSGIRequestHandler.log_request
---+--
 Reporter:  andreif|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by andreif):

 * stage:  Accepted => Unreviewed


Old description:

> It's often useful to know how much time it takes for `runserver` to
> respond without setting up a middleware or using the debug toolbar.
> Currently, one could monkeypatch WSGIRequestHandler (e.g. in `manage.py`)
> in order to get the time:
>
> {{{
> #!python
> from django.core.servers.basehttp import WSGIRequestHandler
> _handle = WSGIRequestHandler.handle
>
> def handle(self):
> self.request_started = time.time()
> _handle(self)
>
> def log_request(self, code='-', size='-'):
> self.log_message('"%s" %s %s %dms',
>  self.requestline, str(code), str(size),
>  (time.time() - self.request_started) * 1e3)
>
> WSGIRequestHandler.handle = handle
> WSGIRequestHandler.log_request = log_request
> }}}
>
> It seems easy to add it in the WSGIRequestHandler e.g.
> https://github.com/django/django/pull/5606. The response time is slightly
> longer than actual response time due to late measuring but think an easy
> implementation is better than the exact duration.
>
> This feature is blocked by https://code.djangoproject.com/ticket/25684

New description:

 It's often useful to know how much time it takes for `runserver` to
 respond without setting up a middleware or using the debug toolbar.
 Currently, one could monkeypatch WSGIRequestHandler (e.g. in `manage.py`)
 in order to get the time:

 {{{
 #!python
 from django.core.servers.basehttp import WSGIRequestHandler
 _handle = WSGIRequestHandler.handle

 def handle(self):
 self.request_started = time.time()
 _handle(self)

 def log_request(self, code='-', size='-'):
 self.log_message('"%s" %s %s %dms',
  self.requestline, str(code), str(size),
  (time.time() - self.request_started) * 1e3)

 WSGIRequestHandler.handle = handle
 WSGIRequestHandler.log_request = log_request
 }}}

 or via middleware

 {{{
 #!python
 class ResponseTimeMiddleware(object):
 def process_view(self, request, view_func, view_args, view_kwargs):
 start = time.time()
 response = view_func(request, *view_args, **view_kwargs)

 if response and getattr(response, 'is_rendered', True) is False:
 response.rendered_content

 logging.getLogger('response_time').debug(
 'Response time %dms', (time.time() - start) * 1000)
 return response
 }}}


 It seems easy to add it in the WSGIRequestHandler e.g.
 https://github.com/django/django/pull/5606. The response time is slightly
 longer than actual response time due to late measuring but think an easy
 implementation is better than the exact duration.

 This feature is blocked by https://code.djangoproject.com/ticket/25684

--

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

Re: [Django] #25290: Warn against modifying objects created in setUpTestData

2015-11-07 Thread Django

#25290: Warn against modifying objects created in setUpTestData
-+-
 Reporter:  MarkusH  |Owner:
 Type:   |  Anjaliunni96
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"81006b9657534a21c3eadb2bc4a87c46db54c099" 81006b9]:
 {{{
 #!CommitTicketReference repository=""
 revision="81006b9657534a21c3eadb2bc4a87c46db54c099"
 Fixed #25290 -- Warned against modifying objects created in
 setUpTestData() in tests.
 }}}

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

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

Re: [Django] #24991: Range types not properly converted to SQL in QuerySet.query.str()

2015-11-07 Thread Django

#24991: Range types not properly converted to SQL in QuerySet.query.__str__()
--+
 Reporter:  unklphil  |Owner:  Stranger6667
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.8
 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 Stranger6667):

 Based on `psycopg2.extensions.adapt` output it should be converted as:
 `NumericRange(1, 5)` to `'[1,5)'`
 `DateRange(datetime.date(2015, 5, 1), datetime.date(2015, 6, 1))` to
 `daterange('2015-05-01'::date, '2015-06-01'::date, '[)')`
 `DateTimeTZRange(datetime.datetime(2015, 5, 1, tzinfo=utc),
 datetime.datetime(2015, 6, 1, tzinfo=utc))` to
 `tstzrange('2015-05-01T00:00:00+00:00'::timestamptz,
 '2015-06-01T00:00:00+00:00'::timestamptz, '[)')`

 Please correct me if I'm wrong. If it is true, then I'll try to provide PR
 for that.

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

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

Re: [Django] #25704: Response time in WSGIRequestHandler.log_request

2015-11-07 Thread Django

#25704: Response time in WSGIRequestHandler.log_request
---+
 Reporter:  andreif|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by charettes):

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


Old description:

> It's often useful to know how much time it takes for ` runserver`  to
> respond without setting up a middleware or using the debug toolbar.
> Currently, one could monkeypatch WSGIRequestHandler (e.g. in `manage.py`)
> in order to get the time:
>
> {{{
> #!python
> from django.core.servers.basehttp import WSGIRequestHandler
> _handle = WSGIRequestHandler.handle
>
> def handle(self):
> self.request_started = time.time()
> _handle(self)
>
> def log_request(self, code='-', size='-'):
> self.log_message('"%s" %s %s %dms',
>  self.requestline, str(code), str(size),
>  (time.time() - self.request_started) * 1e3)
>
> WSGIRequestHandler.handle = handle
> WSGIRequestHandler.log_request = log_request
> }}}
>
> It seems easy to add it in the WSGIRequestHandler e.g.
> https://github.com/django/django/pull/5606. The response time is slightly
> longer than actual response time due to late measuring but think an easy
> implementation is better than the exact duration.
>
> This feature is blocked by https://code.djangoproject.com/ticket/25684

New description:

 It's often useful to know how much time it takes for `runserver` to
 respond without setting up a middleware or using the debug toolbar.
 Currently, one could monkeypatch WSGIRequestHandler (e.g. in `manage.py`)
 in order to get the time:

 {{{
 #!python
 from django.core.servers.basehttp import WSGIRequestHandler
 _handle = WSGIRequestHandler.handle

 def handle(self):
 self.request_started = time.time()
 _handle(self)

 def log_request(self, code='-', size='-'):
 self.log_message('"%s" %s %s %dms',
  self.requestline, str(code), str(size),
  (time.time() - self.request_started) * 1e3)

 WSGIRequestHandler.handle = handle
 WSGIRequestHandler.log_request = log_request
 }}}

 It seems easy to add it in the WSGIRequestHandler e.g.
 https://github.com/django/django/pull/5606. The response time is slightly
 longer than actual response time due to late measuring but think an easy
 implementation is better than the exact duration.

 This feature is blocked by https://code.djangoproject.com/ticket/25684

--

Comment:

 I'm not sure this should be part of the actual output of runserver but it
 would make sense to at least provide it as a kwarg to the logger calls to
 allow third party and users to refer to it in a formater or filter.

 e.g. one could write a formatter that turns the text bold if request
 latest more than X ms.

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

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

2015-11-07 Thread Django

#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  assigned
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

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

[Django] #25704: Response time in WSGIRequestHandler.log_request

2015-11-07 Thread Django

#25704: Response time in WSGIRequestHandler.log_request
---+
 Reporter:  andreif|  Owner:  nobody
 Type:  New feature| Status:  new
Component:  HTTP handling  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 It's often useful to know how much time it takes for ` runserver`  to
 respond without setting up a middleware or using the debug toolbar.
 Currently, one could monkeypatch WSGIRequestHandler (e.g. in `manage.py`)
 in order to get the time:

 {{{
 #!python
 from django.core.servers.basehttp import WSGIRequestHandler
 _handle = WSGIRequestHandler.handle

 def handle(self):
 self.request_started = time.time()
 _handle(self)

 def log_request(self, code='-', size='-'):
 self.log_message('"%s" %s %s %dms',
  self.requestline, str(code), str(size),
  (time.time() - self.request_started) * 1e3)

 WSGIRequestHandler.handle = handle
 WSGIRequestHandler.log_request = log_request
 }}}

 It seems easy to add it in the WSGIRequestHandler e.g.
 https://github.com/django/django/pull/5606. The response time is slightly
 longer than actual response time due to late measuring but think an easy
 implementation is better than the exact duration.

 This feature is blocked by https://code.djangoproject.com/ticket/25684

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

Re: [Django] #25696: Add sphinx extension to django.contrib

2015-11-07 Thread Django

#25696: Add sphinx extension to django.contrib
---+--
 Reporter:  codingjoe  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  sphinx, docs   | 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:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I'm not yet convinced that this is something that needs to live in Django
 itself at this time. I'd like to see it (at least initially) as a third-
 party package which should allow you to iterate more quickly before we
 consider it for inclusion in Django. Please let the DevelopersMailingList
 know when you have something to share, or feel free to reach out to me
 directly for feedback. 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/067.82fe3344ff1720c0e50940a927886732%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #6727: django.utils.cache.patch_cache_control enhancement when response has empty cache control header

2015-11-07 Thread Django

#6727: django.utils.cache.patch_cache_control enhancement when response has 
empty
cache control header
-+-
 Reporter:  pascal@… |Owner:
 Type:   |  dwightgunning
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


Comment:

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

Re: [Django] #25544: prefetch_related sends duplicate ids to database

2015-11-07 Thread Django

#25544: prefetch_related sends duplicate ids to database
-+-
 Reporter:  spectras |Owner:  Ian-Foote
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch duplicate   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 `postgres_tests.test_array.TestQuerying.test_in` 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/066.fcfd84f86c329a512b6ebbd09ae2889d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25412: Migrate command does not create index with operator class for CharField

2015-11-07 Thread Django

#25412: Migrate command does not create index with operator class for CharField
+
 Reporter:  synasius|Owner:  synasius
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by charettes):

 * needs_better_patch:  0 => 1


Comment:

 Left some comments on the 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/066.5b6816b449d1d46173308a340513e066%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25703: Create topic documentation for Expressions

2015-11-07 Thread Django

#25703: Create topic documentation for Expressions
-+-
 Reporter:  thatdocslady |Owner:
 Type:   |  thatdocslady
  Cleanup/optimization   |   Status:  assigned
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


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

Re: [Django] #24991: Range types not properly converted to SQL in QuerySet.query.str()

2015-11-07 Thread Django

#24991: Range types not properly converted to SQL in QuerySet.query.__str__()
--+
 Reporter:  unklphil  |Owner:  Stranger6667
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.8
 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 Stranger6667):

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


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

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

Re: [Django] #25666: ArrayField exact querying doesn't work with CharField

2015-11-07 Thread Django

#25666: ArrayField exact querying doesn't work with CharField
--+
 Reporter:  ecederstrand  |Owner:  Stranger6667
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.8
 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 Stranger6667):

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


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

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

Re: [Django] #21221: Widgets and Admin's Media should use the configured staticfiles storage to create the right path to a file

2015-11-07 Thread Django

#21221: Widgets and Admin's Media should use the configured staticfiles storage 
to
create the right path to a file
-+-
 Reporter:  Guilherme Gondim |Owner:  codingjoe
  |
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  staticfiles, admin,  | Triage Stage:  Accepted
  CachedFilesMixin, media, widgets   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by codingjoe):

 I wouldn't. I don't see a big performance opportunity, but the risk that
 someone wants to manipulate the storage during runtime.

 I added a second commit that should clean up a little.

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

Re: [Django] #20869: Prevent repetitive output to counter BREACH-type attacks

2015-11-07 Thread Django

#20869: Prevent repetitive output to counter BREACH-type attacks
-+
 Reporter:  patrys   |Owner:  shaib
 Type:  New feature  |   Status:  assigned
Component:  CSRF |  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 shaib):

 New PR (in work): https://github.com/django/django/pull/5605

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

Re: [Django] #25703: Create topic documentation for Expressions

2015-11-07 Thread Django

#25703: Create topic documentation for Expressions
-+-
 Reporter:  thatdocslady |Owner:
 Type:   |  thatdocslady
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by thatdocslady):

 * owner:  nobody => thatdocslady
 * needs_docs:   => 0
 * status:  new => assigned
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

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

[Django] #25703: Create topic documentation for Expressions

2015-11-07 Thread Django

#25703: Create topic documentation for Expressions
--+
 Reporter:  thatdocslady  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently this feature has the following docs:

 Conditional Expressions - Reference document that contains descriptions
 and examples of conditional expressions
 https://docs.djangoproject.com/en/1.8/ref/models/conditional-expressions/

 Query Expressions - Full reference about all expressions
 https://docs.djangoproject.com/en/1.8/ref/models/expressions/

 Proposed new content:

 - Overview and benefits of expressions
 - Use-case example(s)
 - Tutorial (move from ref and expand)
 - General guidelines and limitations

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

Re: [Django] #12233: Redirect logged in user

2015-11-07 Thread Django

#12233: Redirect logged in user
-+-
 Reporter:  dmathieu |Owner:
 |  aaronbassett
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  authentication,login   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by olethanh):

 I've updated my branch, rebased it on master, improved the documentation
 and the tests.

 Opened a PR here : https://github.com/django/django/pull/5604

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

Re: [Django] #25702: Port ModelAdmin.fieldset to BaseForm

2015-11-07 Thread Django

#25702: Port ModelAdmin.fieldset to BaseForm
-+-
 Reporter:  Psycojoker   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form modeladmin  | Triage Stage:
  layout admininterface  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Psycojoker):

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


Old description:

> In the admin interface it is possible to control the admin forms layout
> using the //fieldset// attribute. This feature is described here:
> https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fieldsets
>
> Here is the example from the documentation (modified to display the
> feature that allows to display multiple fields in the same line):
>
> {{{#!python
> from django.contrib import admin
>
> class FlatPageAdmin(admin.ModelAdmin):
> fieldsets = (
> (None, {
> 'fields': (('url', 'title'), ('content', 'sites'))
> }),
> ('Advanced options', {
> 'classes': ('collapse',),
> 'fields': ('enable_comments', 'registration_required',
> 'template_name')
> }),
> )
> }}}
>
> The idea of this feature would be to port this exact behavior to the
> standard django forms. Taking the first form example from the
> documentation, this could look like this:
>
> {{{#!python
> from django import forms
>
> class ContactForm(forms.Form):
> subject = forms.CharField(max_length=100)
> message = forms.CharField(widget=forms.Textarea)
> sender = forms.EmailField()
> cc_myself = forms.BooleanField(required=False)
>
> fieldset = (
> (None, {
> "fields": (('sender', 'cc_myself'),),
> }),
> ("Content", {
> "fields": ("subject", "message"),
> }),
> )
> }}}
>
> Currently, there is no way to modify the form layout beside the field
> order. This is very frustrating because this mean that if you want modify
> the layout of a form, you need to explode it totally to do that or you
> need to use another project (like django-crispy-forms [#point1 (1)] or
> another one).
>
> While not going to all the extend of what django-cripsy-forms or another
> project is doing, //fieldset// is an already known and used convention
> accross the django project and allowing it in standard forms seems like a
> natural and intuitive choice.
>
> [=#point1 (1)] http://django-crispy-
> forms.readthedocs.org/en/latest/layouts.html

New description:

 In the admin interface it is possible to control the admin forms layout
 using the //fieldset// attribute. This feature is described here:
 
https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fieldsets

 Here is the example from the documentation (modified to display the
 feature that allows to display multiple fields in the same line):

 {{{#!python
 from django.contrib import admin

 class FlatPageAdmin(admin.ModelAdmin):
 fieldsets = (
 (None, {
 'fields': (('url', 'title'), ('content', 'sites'))
 }),
 ('Advanced options', {
 'classes': ('collapse',),
 'fields': ('enable_comments', 'registration_required',
 'template_name')
 }),
 )
 }}}

 The idea of this feature would be to port this exact behavior to the
 standard django forms. Taking the first form example from the
 documentation, this could look like this:

 {{{#!python
 from django import forms

 class ContactForm(forms.Form):
 subject = forms.CharField(max_length=100)
 message = forms.CharField(widget=forms.Textarea)
 sender = forms.EmailField()
 cc_myself = forms.BooleanField(required=False)

 fieldset = (
 (None, {
 "fields": (('sender', 'cc_myself'),),
 }),
 ("Content", {
 "fields": ("subject", "message"),
 }),
 )
 }}}

 Currently, there is no way to modify the form layout beside the field
 order. This is very frustrating because this mean that if you want modify
 the layout of a form, you need to explode it totally to do that or you
 need to use another project (like django-crispy-forms [#point1 (1)] or
 another one).

 While not going to all the extend of what django-cripsy-forms or another
 project is doing, //fieldset// is an already known and used convention
 accross the django project and allowing it in standard forms seems like a
 natural and intuitive choice.

 Regardin

Re: [Django] #25412: Migrate command does not create index with operator class for CharField

2015-11-07 Thread Django

#25412: Migrate command does not create index with operator class for CharField
+
 Reporter:  synasius|Owner:  synasius
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by synasius):

 * has_patch:  0 => 1


Comment:

 Pull request here: https://github.com/django/django/pull/5603

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

Re: [Django] #25504: Django test teardown fails when there is no default database

2015-11-07 Thread Django

#25504: Django test teardown fails when there is no default database
---+
 Reporter:  Sjord  |Owner:  mihaicc
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  Version:  1.9a1
 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 mihaicc):

 I didn't manage to finish this ticket.

 Progress so far:
 - have 2 tests (one broader and one narrower to the exception)
 - found out this happens for fixtures setup as well
 - debated two solutions with Michael Manfre and Tim and will follow soon
 with a pull request

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

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

Re: [Django] #25624: Autoreload fails if jinja2.ModuleLoader used

2015-11-07 Thread Django

#25624: Autoreload fails if jinja2.ModuleLoader used
-+-
 Reporter:  svartalf |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  autoreload, jinja2,  | Triage Stage:  Accepted
  ModuleLoader   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Indeed there are a few tests for `gen_filenames()` in
 `tests/utils_tests/test_autoreload.py`. Could you try to add one as Carl
 says?

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

Re: [Django] #25697: Default error views shouldn't silence TemplateDoesNotExist errors if a custom template name was specified

2015-11-07 Thread Django

#25697: Default error views shouldn't silence TemplateDoesNotExist errors if a
custom template name was specified
--+
 Reporter:  charettes |Owner:  yakky
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Generic views |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by yakky):

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

Re: [Django] #25349: ModelForm regression when setting None into a ForeignKey

2015-11-07 Thread Django

#25349: ModelForm regression when setting None into a ForeignKey
--+
 Reporter:  jpaulett  |Owner:  haxoza
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.8
 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 haxoza):

 Hi! I was digging this issue for a few hours and here are my findings:

 * I run the tests proposed above by jpaulett and they failed as it's
 described
 * I was trying to prepare a fix digging in `django/forms/models.py` but
 with no luck
 * then I discovered then it is a wider misbehaviour of model forms fields
 with `required=False` and generated from model fields with `blank=False`
 (below there is a test)
 * I've tried to run git bisect but with no luck - however the sure thing
 is the issue wasn't there in 1.7.10

 Here's a test for more general issue I found:

 models.py:
 {{{
 from django.db import models


 class Writer(models.Model):
 name = models.CharField(max_length=30, blank=False)
 }}}

 tests.py:

 {{{
 from django import forms
 from django.test.testcases import TestCase
 from .models import Writer


 class CustomWriterForm(forms.ModelForm):
 name = forms.CharField(required=False)

 class Meta(object):
 model = Writer
 fields = '__all__'


 class ModelFormTest(TestCase):

 def test_save_blank_false_with_required_false(self):
 obj = Writer.objects.create(name='test')
 value = ''
 form = CustomWriterForm(data={'name': value}, instance=obj)
 self.assertTrue(form.is_valid())

 obj = form.save()

 self.assertEqual(obj.name, value)  # ASSERTION FAILS
 }}}

 When running the test in master branch:

 {{{
 $ python tests/runtests.py
 a.tests.ModelFormTest.test_save_blank_false_with_required_false
 Testing against Django installed in
 '/Users/haxoza/dev/projects/django/django' with up to 4 processes
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 F
 ==
 FAIL: test_save_blank_false_with_required_false
 (a.tests.ModelFormTest)
 --
 Traceback (most recent call last):
   File "/Users/haxoza/dev/projects/django/tests/a/tests.py", line 24,
 in test_save_blank_false_with_required_false
 self.assertEqual(obj.name, value)
 AssertionError: 'test' != ''

 --
 Ran 1 test in 0.002s

 FAILED (failures=1)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

 The test fails and I think what should actually happen is that the model
 should be saved with empty string value.

 In my opinion it should be reported as a separate issue and referenced to
 this one because it looks quite serious.

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

Re: [Django] #25544: prefetch_related sends duplicate ids to database

2015-11-07 Thread Django

#25544: prefetch_related sends duplicate ids to database
-+-
 Reporter:  spectras |Owner:  Ian-Foote
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch duplicate   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

 * stage:  Accepted => Ready for checkin


Comment:

 Patch is ready, IMO. Waiting for actual merge until the CI catches up...

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

Re: [Django] #25388: Allow disabling of all migrations during tests

2015-11-07 Thread Django

#25388: Allow disabling of all migrations during tests
---+
 Reporter:  MarkusH|Owner:  viciu
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by viciu):

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


Comment:

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

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

[Django] #25702: Port ModelAdmin.fieldset to BaseForm

2015-11-07 Thread Django

#25702: Port ModelAdmin.fieldset to BaseForm
-+-
 Reporter:   |  Owner:  nobody
  Psycojoker |
 Type:  New  | Status:  new
  feature|
Component:  Forms|Version:  master
 Severity:  Normal   |   Keywords:  form modeladmin layout
 Triage Stage:   |  admininterface
  Unreviewed |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 In the admin interface it is possible to control the admin forms layout
 using the //fieldset// attribute. This feature is described here:
 
https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fieldsets

 Here is the example from the documentation (modified to display the
 feature that allows to display multiple fields in the same line):

 {{{#!python
 from django.contrib import admin

 class FlatPageAdmin(admin.ModelAdmin):
 fieldsets = (
 (None, {
 'fields': (('url', 'title'), ('content', 'sites'))
 }),
 ('Advanced options', {
 'classes': ('collapse',),
 'fields': ('enable_comments', 'registration_required',
 'template_name')
 }),
 )
 }}}

 The idea of this feature would be to port this exact behavior to the
 standard django forms. Taking the first form example from the
 documentation, this could look like this:

 {{{#!python
 from django import forms

 class ContactForm(forms.Form):
 subject = forms.CharField(max_length=100)
 message = forms.CharField(widget=forms.Textarea)
 sender = forms.EmailField()
 cc_myself = forms.BooleanField(required=False)

 fieldset = (
 (None, {
 "fields": (('sender', 'cc_myself'),),
 }),
 ("Content", {
 "fields": ("subject", "message"),
 }),
 )
 }}}

 Currently, there is no way to modify the form layout beside the field
 order. This is very frustrating because this mean that if you want modify
 the layout of a form, you need to explode it totally to do that or you
 need to use another project (like django-crispy-forms [#point1 (1)] or
 another one).

 While not going to all the extend of what django-cripsy-forms or another
 project is doing, //fieldset// is an already known and used convention
 accross the django project and allowing it in standard forms seems like a
 natural and intuitive choice.

 [=#point1 (1)] http://django-crispy-
 forms.readthedocs.org/en/latest/layouts.html

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

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

Re: [Django] #16859: CSRF Improvements

2015-11-07 Thread Django

#16859: CSRF Improvements
--+
 Reporter:  PaulM |Owner:  PaulM
 Type:  Cleanup/optimization  |   Status:  new
Component:  CSRF  |  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 raphaelm):

 * cc: mail@… (added)


Comment:

 I submitted a first version of a patch for session storage of CSRF tokens:
 https://github.com/django/django/pull/5600

 I'd love to have some review on this, but I'm fine with postponing the
 merge after Shai landed his changes to CSRF handling, as those two will
 get merge conflicts and his one will be the bigger 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/063.a3e5994c2f1d8b6de6d8027e51695ac4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25606: Add support for "__" lookup in RelatedOnlyFieldListFilter

2015-11-07 Thread Django

#25606: Add support for "__" lookup in RelatedOnlyFieldListFilter
-+-
 Reporter:  quarkness|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by slurms):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks good.

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

Re: [Django] #17834: ETag generated from empty content can break http caching

2015-11-07 Thread Django

#17834: ETag generated from empty content can break http caching
---+-
 Reporter:  paulegan   |Owner:  dwightgunning
 Type:  Bug|   Status:  assigned
Component:  HTTP handling  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by dwightgunning):

 * owner:  nobody => dwightgunning
 * status:  new => assigned


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

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

Re: [Django] #25316: Can't use order_by and values(_list) together after annotating

2015-11-07 Thread Django

#25316: Can't use order_by and values(_list) together after annotating
-+-
 Reporter:  adrian17 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  annotate, order_by   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 We do add "unselected" fields to the end of select list for some cases
 already. It is perhaps possible to do so here, too.

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

Re: [Django] #25624: Autoreload fails if jinja2.ModuleLoader used

2015-11-07 Thread Django

Comment (by carljm):

@hackerdd That fix looks fine to me. I don't think it should actually
change the behavior, since modules without `__file__` were excluded later
on anyway. There's nothing we can do in the autoreloader with a module
that doesn't have a `__file__`.

I think this should be testable without too much difficulty, just by
inserting a problematic entry into `sys.modules` (in the test - and make
sure it gets removed after the test, using a `finally` block) and then
calling the `gen_filenames` function.

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

Re: [Django] #25467: Excluding an object with no ID excludes everything.

2015-11-07 Thread Django

#25467: Excluding an object with no ID excludes everything.
-+-
 Reporter:  skorokithakis|Owner:
 |  HuffAndPuff
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Quick comments, I'm not sure if these apply to this ticket.
   - .filter() and exclude() should return complements of each other. This
 causes problems for queries like lt=None.
   - None is only allowed for exact and iexact lookup. The same should
 apply for relational lookups.
- in=[val, None] doesn't work correctly in the pythonic sense
 currently. It never matches anything.

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

Re: [Django] #25316: Can't use order_by and values(_list) together after annotating

2015-11-07 Thread Django

Comment (by lucasmoeskops):

I think this is not an issue.

The problem is that the example is annotating a field and then sorts on
this field. To do this, the field needs to exist still in the select. It
is however thrown away by values, so it can't sort on it.

The example will work correctly if the annotated field is added to the
values list as well. It will also work correctly if no order on the
annotated field is applied.

If this were to work, the resulting query would be considerably more
complex, involving a different final select than the select to apply the
ordering on.

What could be improved though is the error message. This is clear when no
annotation is used. Maybe something like "Can't deselect annotated value"
or "Can't order on unselected annotated field `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/066.b0467438159c1a7dddef7d3240e6cb23%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #494: Collapse in admin interface for inline related objects

2015-11-07 Thread Django

#494: Collapse in admin interface for inline related objects
-+-
 Reporter:  jcstover@…   |Owner:
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  edit_inline, nfa-| Triage Stage:  Accepted
  someday|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by kmtracey):

 * owner:  kmtracey =>
 * status:  assigned => new
 * needs_tests:  1 => 0
 * 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/077.04f1455f7b564d8ef58f379c9ce7bae3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25701: Add warning to an admin list_view if too many queries are being used

2015-11-07 Thread Django

#25701: Add warning to an admin list_view if too many queries are being used
---+--
 Reporter:  jacinda|Owner:  jacinda
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by jacinda:

Old description:

> If you use a related field in a callable, and then use that callable in
> list_display, Django doesn't currently have a way to automatically detect
> that select_related should be used and performs a query for every row in
> the list.
>
> While it might be possible to do this automatically, a quick way to help
> with this problem would be to warn a developer with something like
> django.contrib.messages (if enabled) that a list_view is performing O(n)
> queries and that they should investigate this as a potential performance
> issue.

New description:

 If you use a related field in a callable on a Model or ModelAdmin, and
 then use that callable in list_display, Django doesn't currently have a
 way to automatically detect that select_related should be used and
 performs a query for every row in the list.

 While it might be possible to do this automatically, a quick way to help
 with this problem would be to warn a developer with something like
 django.contrib.messages (if enabled) that a list_view is performing O(n)
 queries and that they should investigate this as a potential performance
 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/065.34d195097e376d35d01bcb819b85d4e7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25701: Add warning to an admin list_view if too many queries are being used

2015-11-07 Thread Django

#25701: Add warning to an admin list_view if too many queries are being used
---+--
 Reporter:  jacinda|Owner:  jacinda
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by jacinda):

 * status:  new => assigned
 * cc: jacinda.shelly@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => jacinda
 * 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/065.6c408b73d6980e130c01096695905740%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25701: Add warning to an admin list_view if too many queries are being used

2015-11-07 Thread Django

#25701: Add warning to an admin list_view if too many queries are being used
---+
 Reporter:  jacinda|  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If you use a related field in a callable, and then use that callable in
 list_display, Django doesn't currently have a way to automatically detect
 that select_related should be used and performs a query for every row in
 the list.

 While it might be possible to do this automatically, a quick way to help
 with this problem would be to warn a developer with something like
 django.contrib.messages (if enabled) that a list_view is performing O(n)
 queries and that they should investigate this as a potential performance
 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/050.2714927a2477c67a5340a66294edb52e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25469: Add an auto escape setting to the Django template engine

2015-11-07 Thread Django

#25469: Add an auto escape setting to the Django template engine
-+
 Reporter:  aidanlister  |Owner:  jgeskens
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  templates| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 I confirm what Carl just said. This should be an option of the engine. The
 signature of `render()` should remain a lowest common denominator.

 This is necessary for end-users to be able to override any template with
 their own version, written for their favorite engine.

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

Re: [Django] #25700: Amend comment to remove reference to the no longer used NullHandler

2015-11-07 Thread Django

#25700: Amend comment to remove reference to the no longer used NullHandler
-+-
 Reporter:  nealtodd |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => closed
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => fixed
 * stage:  Unreviewed => Ready for checkin


Comment:

 Thanks, pushed in [c3a974c81ec] (master) / [15377fceaa4aa28] (1.9.x).

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

Re: [Django] #25695: csrf_failure view should take a template parameter

2015-11-07 Thread Django

#25695: csrf_failure view should take a template parameter
-+-
 Reporter:  raphaelm |Owner:  raphaelm
 Type:  New feature  |   Status:  assigned
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * version:  1.8 => master
 * stage:  Accepted => Ready for checkin


Comment:

 Patch LGTM.

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

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

Re: [Django] #6727: django.utils.cache.patch_cache_control enhancement when response has empty cache control header

2015-11-07 Thread Django

#6727: django.utils.cache.patch_cache_control enhancement when response has 
empty
cache control header
-+-
 Reporter:  pascal@… |Owner:
 Type:   |  dwightgunning
  Cleanup/optimization   |   Status:  assigned
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 dwightgunning):

 Additional test created. Test suite passes.

 Raised pull request: https://github.com/django/django/pull/5597

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

Re: [Django] #6727: django.utils.cache.patch_cache_control enhancement when response has empty cache control header

2015-11-07 Thread Django

#6727: django.utils.cache.patch_cache_control enhancement when response has 
empty
cache control header
-+-
 Reporter:  pascal@… |Owner:
 Type:   |  dwightgunning
  Cleanup/optimization   |   Status:  assigned
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 dwightgunning):

 Created Github branch:
 https://github.com/dwightgunning/django/tree/ticket_6727

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

Re: [Django] #25624: Autoreload fails if jinja2.ModuleLoader used

2015-11-07 Thread Django

#25624: Autoreload fails if jinja2.ModuleLoader used
-+-
 Reporter:  svartalf |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  autoreload, jinja2,  | Triage Stage:  Accepted
  ModuleLoader   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by hackedd):

 This patch fixes the issue by ignoring modules without a `__file__`
 attribute altogether. There are probably cases where this is not quite
 desired behaviour, but I have no idea how to test this.

 The other two options that I can think of to fix this, checking for
 `weakref.ProxyType` or the `_jinja2_module_templates_` module name prefix,
 don't really seem like the right solution either...

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

1 2 3 >

1 - 100 of 252 matches

Mail list logo