Re: [Django] #27723: `type` is not propagated correctly to widgets in MultiWidgets

2017-01-10 Thread Django
#27723: `type` is not propagated correctly to widgets in MultiWidgets
-+--
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Forms|  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 felixxm):

 * Attachment "27723.diff" added.


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

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


[Django] #27723: `type` is not propagated correctly to widgets in MultiWidgets

2017-01-10 Thread Django
#27723: `type` is not propagated correctly to widgets in MultiWidgets
--+--
   Reporter:  felixxm |  Owner:  felixxm
   Type:  Bug | Status:  assigned
  Component:  Forms   |Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
 If `type` is passed in `attrs` to `MultiWidget` then input HTML is
 incorrect e.g.:

 {{{
 
 }}}

 instead of

 {{{
 
 }}}

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


Re: [Django] #27392: Remove "Tests that", "Ensures that", etc. from test docstings

2017-01-10 Thread Django
#27392: Remove "Tests that", "Ensures that", etc. from test docstings
--+
 Reporter:  Tim Graham|Owner:  ablyx
 Type:  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:  1 |UI/UX:  0
--+
Changes (by ablyx):

 * owner:  (none) => ablyx
 * 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/067.be1a8cec5e218c6f8a272be417d2f52f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27678: Document that the template system isn't safe against untrusted template authors

2017-01-10 Thread Django
#27678: Document that the template system isn't safe against untrusted template
authors
-+-
 Reporter:  Tim Graham   |Owner:  Andrew
 Type:   |  Nester
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Andrew Nester):

 * needs_better_patch:  1 => 0


Comment:

 I updated PR according changes requested.

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


[Django] #27722: if a template context is an instance of get_template(), it will raise "TypeError: context must be a dict rather than RequestContext"

2017-01-10 Thread Django
#27722: if a template context is an instance of get_template(), it will raise
"TypeError: context must be a dict rather than RequestContext"
---+
   Reporter:  Sayid Munawar|  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 This simple view:
 {{{
 class Ngopi(TemplateView):
 template_name = 'base.html'

 def get_context_data(self, **kwargs):
 context = super(Ngopi, self).get_context_data(**kwargs)
 context.update({
 'menu': get_template('menu.html')
 })
 return context
 }}}

 with `base.html`:
 {{{
 
 
 Ngeteh
 {% include menu %}
 
 
 }}}

 and `menu.html`:
 {{{
 
 Ngeteh
 Ngopi
 
 }}}

 This situation will raise this exception:
 {{{
 Traceback (most recent call last):
   File "/Users/ayik/Repo/Django/django/django/core/handlers/exception.py",
 line 38, in inner
 response = get_response(request)
   File "/Users/ayik/Repo/Django/django/django/core/handlers/base.py", line
 217, in _get_response
 response = self.process_exception_by_middleware(e, request)
   File "/Users/ayik/Repo/Django/django/django/core/handlers/base.py", line
 215, in _get_response
 response = response.render()
   File "/Users/ayik/Repo/Django/django/django/template/response.py", line
 107, in render
 self.content = self.rendered_content
   File "/Users/ayik/Repo/Django/django/django/template/response.py", line
 84, in rendered_content
 content = template.render(context, self._request)
   File
 "/Users/ayik/Repo/Django/django/django/template/backends/django.py", line
 66, in render
 return self.template.render(context)
   File "/Users/ayik/Repo/Django/django/django/template/base.py", line 207,
 in render
 return self._render(context)
   File "/Users/ayik/Repo/Django/django/django/template/base.py", line 199,
 in _render
 return self.nodelist.render(context)
   File "/Users/ayik/Repo/Django/django/django/template/base.py", line 990,
 in render
 bit = node.render_annotated(context)
   File "/Users/ayik/Repo/Django/django/django/template/base.py", line 957,
 in render_annotated
 return self.render(context)
   File "/Users/ayik/Repo/Django/django/django/template/loader_tags.py",
 line 212, in render
 return template.render(context)
   File
 "/Users/ayik/Repo/Django/django/django/template/backends/django.py", line
 64, in render
 context = make_context(context, request,
 autoescape=self.backend.engine.autoescape)
   File "/Users/ayik/Repo/Django/django/django/template/context.py", line
 285, in make_context
 raise TypeError('context must be a dict rather than %s.' %
 context.__class__.__name__)
 TypeError: context must be a dict rather than RequestContext.
 }}}

 This is fine with django 1.10, but not master (mine is currently
 1.11.dev20170109230310)

 a quick workaround is to edit
 
[https://github.com/django/django/blob/ecb59cc6579402b68ddfd4499bf30edacf5963be/django/template/backends/django.py#L63
 django/template/backends/django.py Line 63] to be like this:
 {{{
 def render(self, context=None, request=None):
 if isinstance(context, dict):  # <-- my temporary workaround
 context = make_context(context, request,
 autoescape=self.backend.engine.autoescape)
 try:
 return self.template.render(context)
 except TemplateDoesNotExist as exc:
 reraise(exc, self.backend)
 }}}

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


Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-10 Thread Django
#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Ok, I'll write to the mailing list shortly. With the current patch, would
 the system check ever trigger in Django 2.1 when the default transaction
 level changes?

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

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


Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-10 Thread Django
#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Shai Berger):

 At a first approximation, I suspect it is better to be cautious about this
 sort of change. However, this may be a good question to ask the community.

 The deprecation period may be required because although the warnings and
 settings are at the project level, there may be code changes required at
 the app level, and it may be better to keep the new projects aware of the
 issue while 3rd parties adapt.

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


Re: [Django] #27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural into CreateModel

2017-01-10 Thread Django
#27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural
into CreateModel
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  squashmigrations | 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"7156a6c9c47fe599207673e1653b056cc46082f6" 7156a6c9]:
 {{{
 #!CommitTicketReference repository=""
 revision="7156a6c9c47fe599207673e1653b056cc46082f6"
 Fixed #27717 -- Allowed migration optimization across AlterModelOptions.
 }}}

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


Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-10 Thread Django
#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 As I thought about this again, I wanted to ask if a deprecation cycle
 brings any value compared to this alternate strategy. It doesn't seem to
 me that projects need two release cycles to choose their isolation level
 -- in the easiest case they just specify what's being used now. If we
 changed the default isolation level now, we could have a "compatibility"
 system check raise a warning if `'isolation_level'` isn't specified in the
 database settings and end up in the same place (where all MySQL projects
 have to specify an isolation level to silence a warning). We could remove
 that check in Django 2.0 and avoid another 8 months of new MySQL projects
 having a check or deprecation warning out of the box.

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


Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-10 Thread Django
#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Shai Berger):

 * needs_better_patch:  1 => 0


Comment:

 Review comments addressed.

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


Re: [Django] #27720: Confusing error message when creating a model with unspecified attributes that have no defaults

2017-01-10 Thread Django
#27720: Confusing error message when creating a model with unspecified 
attributes
that have no defaults
-+-
 Reporter:  sanaani  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  model| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => needsinfo
 * type:  Uncategorized => Cleanup/optimization
 * easy:  1 => 0


Old description:

> Using the example project at
> https://docs.djangoproject.com/en/1.10/intro/tutorial02/.
>
> The example project says to instantiate a model in this way:
> q = Question(**question_text**="What's new?",**
> pub_date**=timezone.now())
>
> However, if you do something silly like not assigning attributes:
> q = Question("What's new?", timezone.now())
>
> The model will still instantiate. What's super confusing is that if you
> forget to type in the attributes, then apply
> q.save()
>
> You get the bizarre error ValueError: invalid literal for int() with base
> 10: 'Question'
>
> If a model object is created without an assigned attribute and the
> missing attribute has no default specified, then some type of warning
> should appear. I wasted about 3 hours today figuring out this dumb
> mistake; the error message isn''t related to the initial error.

New description:

 Using the example project at
 https://docs.djangoproject.com/en/1.10/intro/tutorial02/.

 The example project says to instantiate a model in this way:
 `q = Question(question_text="What's new?", pub_date=timezone.now())`

 However, if you do something silly like not assigning attributes:
 `q = Question("What's new?", timezone.now())`

 The model will still instantiate. What's super confusing is that if you
 forget to type in the attributes, then apply
 `q.save()`

 You get the bizarre error `ValueError: invalid literal for int() with base
 10: 'Question'`

 If a model object is created without an assigned attribute and the missing
 attribute has no default specified, then some type of warning should
 appear. I wasted about 3 hours today figuring out this dumb mistake; the
 error message isn't related to the initial error.

--

Comment:

 I'm not sure if a backwards-compatible solution is feasible. Objects
 created with the ORM assume the developer is doing things properly. If
 user input is incoming, then you can call `Model.clean()` to get a better
 error message. If someone has an idea of an improvement, feel free to
 reopen.

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


Re: [Django] #27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural into CreateModel

2017-01-10 Thread Django
#27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural
into CreateModel
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  squashmigrations | 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 Markus Holtermann):

 * stage:  Accepted => Ready for checkin


Comment:

 Patch and tests look sensible to me.

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


[Django] #27721: Unhelpful error message when trying to run shell that can't be imported

2017-01-10 Thread Django
#27721: Unhelpful error message when trying to run shell that can't be imported
--+
   Reporter:  Peter Inglesby  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  1.10
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When you try to run a specific shell, and that shell can't be imported,
 you get a traceback with an unhelpful error message:

 {{{
 $ ./manage.py shell -i bpython
 Traceback (most recent call last):
   File "./manage.py", line 22, in 
 execute_from_command_line(sys.argv)
   File "/Users/inglesp/.pyenv/versions/inglesham-gallery/lib/python3.6
 /site-packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/Users/inglesp/.pyenv/versions/inglesham-gallery/lib/python3.6
 /site-packages/django/core/management/__init__.py", line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/inglesp/.pyenv/versions/inglesham-gallery/lib/python3.6
 /site-packages/django/core/management/base.py", line 294, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/Users/inglesp/.pyenv/versions/inglesham-gallery/lib/python3.6
 /site-packages/django/core/management/base.py", line 345, in execute
 output = self.handle(*args, **options)
   File "/Users/inglesp/.pyenv/versions/inglesham-gallery/lib/python3.6
 /site-packages/django/core/management/commands/shell.py", line 124, in
 handle
 raise ImportError("Couldn't load any of the specified interfaces.")
 ImportError: Couldn't load any of the specified interfaces.
 }}}

 Instead you should get `CommandError` explaining what's gone wrong.

 I have a PR which comes from my first attempt at fixing #27670.

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


Re: [Django] #27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural into CreateModel

2017-01-10 Thread Django
#27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural
into CreateModel
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  squashmigrations | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Markus Holtermann):

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


Re: [Django] #27719: Add queryset.alias() to mimic .annotate() for aggregations without loading data

2017-01-10 Thread Django
#27719: Add queryset.alias() to mimic .annotate() for aggregations without 
loading
data
-+-
 Reporter:  Marc Tamlyn  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Christophe Pettus):

 Doing a quick example query: In a table with a relatively large text
 field, but just 2,400 rows, the difference between returning all rows and
 all fields without the ts_vector() call and returning all with it was
 12.7ms vs 24,000ms.

 Doing a full sequential scan (no index) with both calculating the
 to_tsvector() for return ''and'' in query predicate is 27,000ms without
 recalculating the to_tsvector for return, 46,700ms with recalculating it.

 After having created a functional index on the to_tsvector() call, and
 using a relatively common search term, the time to return without
 recalculating the to_tsvector was 1.7ms, vs 21,200ms with recalculating
 the ts_vector.

 So, in any scenario, not having to recalcuate the to_tsvector() is a win.

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


Re: [Django] #11803: Admin does not update every ForeignKey select of the same model

2017-01-10 Thread Django
#11803: Admin does not update every ForeignKey select of the same model
-+-
 Reporter:  danilo   |Owner:  nobody
   |
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.1
 Severity:  Normal   |   Resolution:
 Keywords:  admin select | Triage Stage:  Accepted
  foreignkey |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adonys Alea Boffill):

 * cc: aaboffill@… (added)


Comment:

 I think that is a little difficult to find a simple and elegant way to fix
 this ticket.
 The `Select` fields are updated in `RelatedObjectLookups.js` when the
 popup is closed after to add the new record. In order to update all fields
 related with the same `model`, is necessary to have at least something to
 identify all `HTML` elements with the same `model`, something like `data-
 model-ref=""`. Now this is a little more easy with the new `template-based
 widget rendering`, because is easy to add the attribute to the `template`.
 But to make this simple change in the template, is necessary to update all
 tests related with the  html content of widgets. And I don't know if to
 add a new attribute to the field widget template it's finally convenient
 or worthwhile.

 If finally to add something like `data-model-ref=""` in the field widget
 template is not a bad idea, I can work on a 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/091.654936aa678fc8c23ac6726af332d91c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #27720: Confusing error message when creating a model with unspecified attributes that have no defaults

2017-01-10 Thread Django
#27720: Confusing error message when creating a model with unspecified 
attributes
that have no defaults
-+-
   Reporter:  sanaani|  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  model
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Using the example project at
 https://docs.djangoproject.com/en/1.10/intro/tutorial02/.

 The example project says to instantiate a model in this way:
 q = Question(**question_text**="What's new?",** pub_date**=timezone.now())

 However, if you do something silly like not assigning attributes:
 q = Question("What's new?", timezone.now())

 The model will still instantiate. What's super confusing is that if you
 forget to type in the attributes, then apply
 q.save()

 You get the bizarre error ValueError: invalid literal for int() with base
 10: 'Question'

 If a model object is created without an assigned attribute and the missing
 attribute has no default specified, then some type of warning should
 appear. I wasted about 3 hours today figuring out this dumb mistake; the
 error message isn''t related to the initial error.

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


Re: [Django] #27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural into CreateModel

2017-01-10 Thread Django
#27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural
into CreateModel
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  squashmigrations | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ed Morley):

 * status:  new => assigned
 * owner:  nobody => Ed Morley


Comment:

 Thank you for the testcase - PR with that and fix opened :-)

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


Re: [Django] #24580: Add test for untested condition in admin_list template tag.

2017-01-10 Thread Django
#24580: Add test for untested condition in admin_list template tag.
--+
 Reporter:  None  |Owner:  None
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  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 Adonys Alea Boffill):

 Umm!! now I understand your point. Well, I think that there are not a way
 to prove that this code introduce any difference to final result, because
 both case end up making a `force_text` to a `model` instance.

 * Situation 1:
 The condition `if isinstance(f.remote_field, models.ManyToOneRel)` returns
 true and `field_val` is not None, then `result_repr` would be a `model`
 instance, see
 
https://github.com/django/django/blob/master/django/contrib/admin/templatetags/admin_list.py#L245.
 In any other place where `result_repr` is used, is used as format string
 parameter or to receive a new value.

 -- Here:
 
https://github.com/django/django/blob/master/django/contrib/admin/templatetags/admin_list.py#L251
 {{{
 result_repr = mark_safe(' ')
 }}}

 -- Here:
 
https://github.com/django/django/blob/master/django/contrib/admin/templatetags/admin_list.py#L260-L285
 {{{
 link_or_text = result_repr
 #
 yield format_html('<{}{}>{}',
   table_tag,
   row_class,
   link_or_text,
   table_tag)
 }}}

 -- Here:
 
https://github.com/django/django/blob/master/django/contrib/admin/templatetags/admin_list.py#L279
 {{{
  link_or_text = format_html(
 '{}',
 url,
 format_html(
 ' data-popup-opener="{}"', value
 ) if cl.is_popup else '',
 result_repr)
 }}}

 -- Here:
 
https://github.com/django/django/blob/master/django/contrib/admin/templatetags/admin_list.py#L294
 {{{
 result_repr = mark_safe(force_text(bf.errors) + force_text(bf))
 }}}

 -- Here:
 
https://github.com/django/django/blob/master/django/contrib/admin/templatetags/admin_list.py#L295
 {{{
 yield format_html('{}', row_class, result_repr)
 }}}

 * Situation 2:
 Use only `result_repr = display_for_field(value, f, empty_value_display)`.
 The final result is the same, because `value` is a `model` instance
 returned by `lookup_field` method in
 
https://github.com/django/django/blob/master/django/contrib/admin/utils.py#L278-L304,
 when `isinstance(f.remote_field, models.ManyToOneRel)` is true. Then, the
 `display_for_field` method will call `display_for_value` in
 https://github.com/django/django/blob/master/django/contrib/admin/utils.py#L421
 and `display_for_value` finally will return `return force_text(value)` in
 
https://github.com/django/django/blob/master/django/contrib/admin/utils.py#L440.

 In both cases if is None the `empty_value_display` will be shown.

 My conclusions is that we can use result_repr = display_for_field(value,
 f, empty_value_display) directly, If you are agree Tim, I can make the
 change and ensure that every tests runs fine again.

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


[Django] #27719: Add queryset.alias() to mimic .annotate() for aggregations without loading data

2017-01-10 Thread Django
#27719: Add queryset.alias() to mimic .annotate() for aggregations without 
loading
data
-+-
   Reporter:  Marc   |  Owner:  nobody
  Tamlyn |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 At the moment the Expressions API currently does not allow creating a
 value for later use in the query without returning that data from the
 database. In some cases this can be quite expensive over the pipe, and can
 also influence query execution where functional indexes are involved. I
 would like to introduce an API like `alias()`, which does the same thing
 as `annotate()` to allow reuse in later querysets but doesn't return the
 value.

 To be explicit, we are changing a query from one of the form:

 `SELECT to_tsvector('english', "some_field"), "some", "other", "fields"
 FROM "table" WHERE to_tsvector('english', "some_field") @@
 plainto_tsquery("search term") ... LIMIT 10;`

 to one of the form:

 `SELECT "some", "other", "fields" FROM "table" WHERE
 to_tsvector('english', "some_field") @@ plainto_tsquery("search term") ...
 LIMIT 10;`

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


Re: [Django] #27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural into CreateModel

2017-01-10 Thread Django
#27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural
into CreateModel
--+
 Reporter:  Ed Morley |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  squashmigrations  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Simon Charette):

 * Attachment "0001-Refs-27717-Added-a-regression-test.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/066.b704c36feb8160dc18a9eb24b2acd9cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural into CreateModel

2017-01-10 Thread Django
#27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural
into CreateModel
--+
 Reporter:  Ed Morley |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  squashmigrations  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Simon Charette):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Managed to reproduce with the provided 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.d59bbce0a9e407cce42c17c0cd6bc0fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #20238: Support multiple open connections in LiveServerTestCase

2017-01-10 Thread Django
#20238: Support multiple open connections in LiveServerTestCase
---+
 Reporter:  jwxiao@…   |Owner:  Nadege
 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:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Nadege):

 I'm good with targeting Django 2.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.c8d956166b77d524de1d5aecf8df36ad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25530: Deferred SQL operations fail when a referenced table or column is renamed during the same migration

2017-01-10 Thread Django
#25530: Deferred SQL operations fail when a referenced table or column is 
renamed
during the same migration
---+--
 Reporter:  Simon Philips  |Owner:  Simon Charette
 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 Simon Charette):

 * owner:  nobody => Simon Charette
 * 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.bf43aa15b64f1a1dc44a14cb935715e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #25941: Improve the error message for runtests.py when Django isn't on the path

2017-01-10 Thread Django
#25941: Improve the error message for runtests.py when Django isn't on the path
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Description changed by Anton Samarchyan:

Old description:

> Every time I think about contributing, literally the first thing I want
> to do is do a `git clone` and run the tests.
> This is currently annoying, because it requires (according to the
> documentation), my either adding the newly cloned directory to my path
> permanently (and knowing how to do that. I do, but it raises the barrier
> to entry for others) or having cloned it via git which intrinsically puts
> it on the path and smashes it into a `src` directory.
>
> Instead, I have to go and look in the documentation (which is squirrelled
> away via `Documentation -> How to get involved -> Write unit tests`) and
> find `PYTHONPATH=..:$PYTHONPATH ./runtests.py` because there's literally
> no chance I'm going to remember the specifics of that every time I
> sporadically want to get involved (questions in could go through my mind:
> do I need to put a semi-colon in? Do I need to export it? do I need to
> provide a specific settings file?)
>
> Executing `./runtests.py` without the incantation helpfully just errors
> with:
> {{{
> Traceback (most recent call last):
>   File "./runtests.py", line 13, in 
> import django
> ImportError: No module named django
> }}}
> or if you're in a virtualenv with an older extant copy of Django (by way
> of example) ...
> {{{
> Traceback (most recent call last):
>   File "./runtests.py", line 18, in 
> from django.test.runner import default_test_processes
> ImportError: cannot import name 'default_test_processes'
> }}}
> rather than let me know how to get back on the straight and narrow.
>
> The barrier to entry ''is too high''. If `runtests.py` cannot execute, a
> better error message would be useful. Ostensibly something like the
> following would probably work, for the fresh clone scenario (but not the
> already-installed-on-path one):
> {{{
> try:
> import django
> except ImportError:
> sys.stdout.write("Some error message explaining how to run the
> thing\n")
> sys.exit(1)
> }}}
> Really though, a single entry point `./runtests.sh` which passes through
> arguments (`$@` I think?) that might want to be changed would make life
> easier from both a user and documentation standpoint ("just run the shell
> script in the tests directory")
>
> (Additional note: there is a `README.rst` file in the `tests` directory,
> but it a) says to `cd` to a directory which does not exist if you're
> already in the directory [which you probably are to run the tests the
> documented way] and b) requires installing requirements files that the
> quickstart doesn't)

New description:

 Every time I think about contributing, literally the first thing I want to
 do is do a `git clone` and run the tests.
 This is currently annoying, because it requires (according to the
 documentation), my either adding the newly cloned directory to my path
 permanently (and knowing how to do that. I do, but it raises the barrier
 to entry for others) or having cloned it via pip which intrinsically puts
 it on the path and smashes it into a `src` directory.

 Instead, I have to go and look in the documentation (which is squirrelled
 away via `Documentation -> How to get involved -> Write unit tests`) and
 find `PYTHONPATH=..:$PYTHONPATH ./runtests.py` because there's literally
 no chance I'm going to remember the specifics of that every time I
 sporadically want to get involved (questions in could go through my mind:
 do I need to put a semi-colon in? Do I need to export it? do I need to
 provide a specific settings file?)

 Executing `./runtests.py` without the incantation helpfully just errors
 with:
 {{{
 Traceback (most recent call last):
   File "./runtests.py", line 13, in 
 import django
 ImportError: No module named django
 }}}
 or if you're in a virtualenv with an older extant copy of Django (by way
 of example) ...
 {{{
 Traceback (most recent call last):
   File "./runtests.py", line 18, in 
 from django.test.runner import default_test_processes
 ImportError: cannot import name 'default_test_processes'
 }}}
 rather than let me know how to get back on the straight and narrow.

 The barrier to entry ''is too high''. If `runtests.py` ca

Re: [Django] #26903: support date and timestamp containment within postgres range field

2017-01-10 Thread Django
#26903: support date and timestamp containment within postgres range field
--+
 Reporter:  Aron Podrigal |Owner:  felixxm
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  rangefield| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

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


Re: [Django] #20238: Support multiple open connections in LiveServerTestCase

2017-01-10 Thread Django
#20238: Support multiple open connections in LiveServerTestCase
---+
 Reporter:  jwxiao@…   |Owner:  Nadege
 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:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham):

 Unless you're motivated to solve the Python 2 failures, we can target this
 patch for Django 2.0 which drops support for Python 2. The 1.11 feature
 freeze is Friday.

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


Re: [Django] #26903: support date and timestamp containment within postgres range field

2017-01-10 Thread Django
#26903: support date and timestamp containment within postgres range field
--+
 Reporter:  Aron Podrigal |Owner:  felixxm
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  rangefield| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by felixxm):

 * owner:  (none) => felixxm
 * cc: felisiak.mariusz@… (added)
 * status:  new => assigned


Comment:

 [https://github.com/django/django/pull/7822 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/062.afbf62c328e7bbe754538603051b3fbf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #27718: Add QuerySet.union(), intersect(), minus()

2017-01-10 Thread Django
#27718: Add QuerySet.union(), intersect(), minus()
-+-
   Reporter:  Florian|  Owner:  nobody
  Apolloner  |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 [https://groups.google.com/d/topic/django-developers/RhD-
 nbCqIkE/discussion django-developers thread]

 [https://github.com/django/django/pull/7727 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/051.88d60a9ac84a08e9e59c9116b1b1fe88%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #20238: Support multiple open connections in LiveServerTestCase

2017-01-10 Thread Django
#20238: Support multiple open connections in LiveServerTestCase
---+
 Reporter:  jwxiao@…   |Owner:  Nadege
 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:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Nadege):

 * needs_tests:  1 => 0


Comment:

 We actually made the sames changes, I added some tests as well.
 They don't fail but hang whithout the patch.
 I tried to do a test that could show potential database issue because
 aymeric sugested that might be a problem
 but things seems good.

 Patch is here  https://github.com/django/django/pull/7832

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


Re: [Django] #23908: XHTML breaks admin site

2017-01-10 Thread Django
#23908: XHTML breaks admin site
-+-
 Reporter:  Brian May|Owner:  Anton
 |  Samarchyan
 Type:  Bug  |   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 Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 I wrote to [https://groups.google.com/d/topic/django-
 developers/EdwwxxqcKVU/discussion django-developers] to try to get a
 consensus of whether or not we should make that 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.4a3d462de596759b0f415d70340cd4a5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27663: Make Index.create_sql() and SchemaEditor._create_index_sql() return SQL parameters as well

2017-01-10 Thread Django
#27663: Make Index.create_sql() and SchemaEditor._create_index_sql() return SQL
parameters as well
-+-
 Reporter:  Markus Holtermann|Owner:  Markus
 Type:   |  Holtermann
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   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 Tim Graham):

 * stage:  Accepted => Ready for checkin


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

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


[Django] #27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural into CreateModel

2017-01-10 Thread Django
#27717: Squashmigrations doesn't optimize AlterModelOptions verbose_name_plural
into CreateModel
--+--
   Reporter:  Ed Morley   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  master
   Severity:  Normal  |   Keywords:  squashmigrations
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
 The `squashmigrations` command doesn't combine a `AlterModelOptions()`
 with `CreateModel()` in the case below.

 For example (using Django master):

 testapp/models.py

 {{{#!python
 from django.db import models


 class Credentials(models.Model):
 description = models.TextField()

 class Meta:
 db_table = 'credentials'
 # This was added after 0001_initial.py was generated:
 verbose_name_plural = 'credentials'
 }}}

 testapp/migrations/0001_initial.py

 {{{#!python
 class Migration(migrations.Migration):

 initial = True

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='Credentials',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ('description', models.TextField()),
 ],
 options={
 'db_table': 'credentials',
 },
 ),
 ]
 }}}

 testapp/migrations/0002_add_verbose_name_plural.py
 {{{#!python
 class Migration(migrations.Migration):

 dependencies = [
 ('testapp', '0001_initial'),
 ]

 operations = [
 migrations.AlterModelOptions(
 name='credentials',
 options={'verbose_name_plural': 'credentials'},
 ),
 ]
 }}}

 Expected squashed migration (via `./manage.py squashmigrations testapp
 0002`):
 {{{#!python
 class Migration(migrations.Migration):

 replaces = [('testapp', '0001_initial'), ('testapp',
 '0002_add_verbose_name_plural')]

 initial = True

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='Credentials',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ('description', models.TextField()),
 ],
 options={
 'db_table': 'credentials',
 'verbose_name_plural': 'credentials',
 },
 ),
 ]
 }}}

 Actual squashed migration:
 {{{#!python
 class Migration(migrations.Migration):

 replaces = [('testapp', '0001_initial'), ('testapp',
 '0002_add_verbose_name_plural')]

 initial = True

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='Credentials',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ('description', models.TextField()),
 ],
 options={
 'db_table': 'credentials',
 },
 ),
 migrations.AlterModelOptions(
 name='credentials',
 options={'verbose_name_plural': 'credentials'},
 ),
 ]
 }}}

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


Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-10 Thread Django
#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Tim Graham):

 * needs_better_patch:  0 => 1


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

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


Re: [Django] #27716: FieldFile incorrectly returns bytes the first time it is opened with 'r'

2017-01-10 Thread Django
#27716: FieldFile incorrectly returns bytes the first time it is opened with 'r'
-+-
 Reporter:  Tom  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.10
  uploads/storage|
 Severity:  Normal   |   Resolution:  duplicate
 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 Tom):

 Ahh yes it is fixed in master, my apologies.

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


Re: [Django] #27716: FieldFile incorrectly returns bytes the first time it is opened with 'r'

2017-01-10 Thread Django
#27716: FieldFile incorrectly returns bytes the first time it is opened with 'r'
-+-
 Reporter:  Tom  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.10
  uploads/storage|
 Severity:  Normal   |   Resolution:  duplicate
 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 Tim Graham):

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


Comment:

 Please test with Django's master branch. This looks like a duplicate of
 #13809 which is fixed there.

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


Re: [Django] #24580: Add test for untested condition in admin_list template tag.

2017-01-10 Thread Django
#24580: Add test for untested condition in admin_list template tag.
--+
 Reporter:  None  |Owner:  None
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  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 Tim Graham):

 I don't see any test failures with the attached patch applied. The idea is
 to add test assertions to show why that code is needed, if it is.

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

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


Re: [Django] #24580: Add test for untested condition in admin_list template tag.

2017-01-10 Thread Django
#24580: Add test for untested condition in admin_list template tag.
--+
 Reporter:  None  |Owner:  None
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  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 Tim Graham):

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


Re: [Django] #27709: ContentTypes.objects.get_for_models returns inconsistent results for proxy models

2017-01-10 Thread Django
#27709: ContentTypes.objects.get_for_models returns inconsistent results for 
proxy
models
--+
 Reporter:  Peter Inglesby|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  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 Peter Inglesby):

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


Re: [Django] #27709: ContentTypes.objects.get_for_models returns inconsistent results for proxy models

2017-01-10 Thread Django
#27709: ContentTypes.objects.get_for_models returns inconsistent results for 
proxy
models
--+
 Reporter:  Peter Inglesby|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  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 Peter Inglesby):

 That fix doesn't work, and breaks an existing test.

 I've submitted a pull request that changes `get_for_models()` to use
 `get_for_model()`.  This simplifies the code a lot, but means there will
 be one database query for each model that's not in the cache, rather than
 at most one database query per call to `get_for_models()`.  Given that
 calls to `get_for_model()` are cached, I believe this is acceptable.

 I have an alternative fix that preserves the existing behaviour with
 respect to the number of database queries, but makes the code slightly
 harder to follow.

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


Re: [Django] #27716: FieldFile incorrectly returns bytes the first time it is opened with 'r'

2017-01-10 Thread Django
#27716: FieldFile incorrectly returns bytes the first time it is opened with 'r'
-+-
 Reporter:  Tom  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.10
  uploads/storage|
 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 Tom:

Old description:

> This is strange. On the latest 1.10 release with Python 3.5.2 if I have
> this model, created in a fresh project with no non-default settings
> (other than 'MEDIA_ROOT' set to a directory and a single app in
> INSTALLED_APPS with this model):
>

> {{{
> class SomeModel(models.Model):
> fd = models.FileField()
> }}}
>
> Then I run this in `manage.py shell`:
>
> {{{
> >>> s = SomeModel.objects.create(fd='test.txt')
> >>> s.fd.size
> 5
> >>> s.fd.closed
> True
> >>> s.fd.open('r')
> >>> s.fd.read()
> b'hello'
> >>> s.fd.close()
> >>> s.fd.open('r')
> >>> s.fd.read()
> 'hello'
> }}}
>
> The first time a `FileField` is opened it appears to disregard the
> encoding given and always returns bytes. However the second time it
> correctly returns a string. If you re-fetch the model then the behavior
> happens again.

New description:

 This is strange. On the latest 1.10 release with Python 3.5.2 if I have
 this model, created in a fresh project with no non-default settings (other
 than 'MEDIA_ROOT' set to a directory and a single app in INSTALLED_APPS
 with this model):


 {{{
 class SomeModel(models.Model):
 fd = models.FileField()
 }}}

 Then I run this in `manage.py shell`:

 {{{
 >>> s = SomeModel.objects.create(fd='test.txt')
 >>> s.fd.size
 5
 >>> s.fd.closed
 True
 >>> s.fd.open('r')
 >>> s.fd.read()
 b'hello'
 >>> s.fd.close()
 >>> s.fd.open('r')
 >>> s.fd.read()
 'hello'
 }}}

 The first time a `FileField` is opened it appears to disregard the
 encoding given and always returns bytes. However the second time it
 correctly returns a string. If you re-fetch the model then the behavior
 happens again.

 Just to mention that I'm on Linux, but my co-worker is on Windows and both
 appear to have this behavior.

--

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


[Django] #27716: FieldFile incorrectly returns bytes the first time it is opened with 'r'

2017-01-10 Thread Django
#27716: FieldFile incorrectly returns bytes the first time it is opened with 'r'
+
   Reporter:  Tom   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  File uploads/storage  |Version:  1.10
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 This is strange. On the latest 1.10 release with Python 3.5.2 if I have
 this model, created in a fresh project with no non-default settings (other
 than 'MEDIA_ROOT' set to a directory and a single app in INSTALLED_APPS
 with this model):


 {{{
 class SomeModel(models.Model):
 fd = models.FileField()
 }}}

 Then I run this in `manage.py shell`:

 {{{
 >>> s = SomeModel.objects.create(fd='test.txt')
 >>> s.fd.size
 5
 >>> s.fd.closed
 True
 >>> s.fd.open('r')
 >>> s.fd.read()
 b'hello'
 >>> s.fd.close()
 >>> s.fd.open('r')
 >>> s.fd.read()
 'hello'
 }}}

 The first time a `FileField` is opened it appears to disregard the
 encoding given and always returns bytes. However the second time it
 correctly returns a string. If you re-fetch the model then the behavior
 happens again.

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


Re: [Django] #27712: Input widget removes `type` from `attrs`.

2017-01-10 Thread Django
#27712: Input widget removes `type` from `attrs`.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"6872ce226602555d4566902a5b627ad08acdec94" 6872ce22]:
 {{{
 #!CommitTicketReference repository=""
 revision="6872ce226602555d4566902a5b627ad08acdec94"
 Fixed #27712 -- Reallowed Input widget's attrs argument to set the input
 type.

 Regression in b52c73008a9d67e9ddbb841872dc15cdd3d6ee01.
 }}}

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


Re: [Django] #24580: Add test for untested condition in admin_list template tag.

2017-01-10 Thread Django
#24580: Add test for untested condition in admin_list template tag.
--+
 Reporter:  None  |Owner:  None
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  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 Adonys Alea Boffill):

 * cc: aaboffill@… (added)


Comment:

 This ticket seems fixed. There are almost 2 years since this ticket was
 created, and Django has continually evolved. For example, the code
 fragment shown in the ticket's description has actually some little
 changes.

 {{{
# if isinstance(f.rel, models.ManyToOneRel):  <= old
 line...
if isinstance(f.remote_field, models.ManyToOneRel):
 field_val = getattr(result, f.name)
 if field_val is None:
 result_repr = empty_value_display
 else:
 result_repr = field_val
 else:
 result_repr = display_for_field(value, f,
 empty_value_display)
 if isinstance(f, (models.DateField, models.TimeField,
 models.ForeignKey)):
 row_classes.append('nowrap')
 }}}

 I analysed the tests where this fragment of code is involved and I've the
 following result:
 * Admin tests where the condition  `if isinstance(f.remote_field,
 models.ManyToOneRel)` is used:
 ||= Test Name =||= Number of Tests =||
 || admin_changelist || 10 ||
 || admin_views || 48 ||
 || admin_widgets || 1 ||
 * Admin tests where the condition  `if isinstance(f.remote_field,
 models.ManyToOneRel)` returns true:
 ||= Test Name =||= Number of Tests =||
 || admin_changelist || 7 ||
 || admin_views || 13 ||
 || admin_widgets || 1 ||
 * Admin tests where the condition  `if isinstance(f.remote_field,
 models.ManyToOneRel)` returns false:
 ||= Test Name =||= Number of Tests =||
 || admin_changelist || 10 ||
 || admin_views || 48 ||
 || admin_widgets || 1 ||

 This condition `if isinstance(f.remote_field, models.ManyToOneRel)` in
 admin_list template tag works good. I think that there are not other
 ticket related specifically with that, and the Django admin
 `items_for_result` method works fine. Is still necessary create other test
 specifically for that condition??
 I think that this ticket could be closed as fixed.

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


Re: [Django] #13240: Modify RelatedManager and ManyRelatedManager add() and remove() to accept QuerySets and iterables

2017-01-10 Thread Django
#13240: Modify RelatedManager and ManyRelatedManager add() and remove() to 
accept
QuerySets and iterables
-+-
 Reporter:  Gabriel Hurley   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Jimmy Merrild Krag):

 What's the status on this one? I am in a situation where this could be
 handy, but since it is not there, I have to loop.

 Discussing the API seems to be what killed this. Would it be better if
 another function than add handled querysets and iterables?

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


Re: [Django] #16614: Support server-side cursors for queryset iteration in database backends

2017-01-10 Thread Django
#16614: Support server-side cursors for queryset iteration in database backends
-+-
 Reporter:  Dan McGee|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  memory cursors   | Triage Stage:  Ready for
  database   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #27714: Small visual artifact when clicking inline edit button in admin

2017-01-10 Thread Django
#27714: Small visual artifact when clicking inline edit button in admin
-+-
 Reporter:  Anton Samarchyan |Owner:  Anton
 |  Samarchyan
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"95f434e2b90b4fe4f0c933cdc987e3e165d713ff" 95f434e]:
 {{{
 #!CommitTicketReference repository=""
 revision="95f434e2b90b4fe4f0c933cdc987e3e165d713ff"
 Fixed #27714 -- Fixed small visual artifact when clicking inline edit
 button in admin.
 }}}

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


Re: [Django] #27715: [Tutorial - part 6.] Lack of saving created question into db

2017-01-10 Thread Django
#27715: [Tutorial - part 6.] Lack of saving created question into db
---+--
 Reporter:  UncleGoogle|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:  invalid
 Keywords:  tutorial   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by UncleGoogle):

 * keywords:  tutorial documentation => tutorial


Old description:

> I've been wondering for few hours why view tests fails despite the fact,
> everything is done the way tutorial shows:
> https://docs.djangoproject.com/en/1.10/intro/tutorial05/
>
> New-created Question objects had not been saved in temporary test
> database.
>
> Now, polls/tests.py is starts from:
> {{{
> def create_question(question_text, days):
> time = timezone.now() + datetime.timedelta(days=days)
> return Question.objects.create(question_text=question_text,
> pub_date=time)
> }}}
>
> For me works just:
> {{{
> def create_question(question_text, days):
> time = timezone.now() + datetime.timedelta(days=days)
> q = Question.objects.create(question_text=question_text,
> pub_date=time)
> q.save()
> }}}

New description:

 I've been wondering for few hours why view tests fails despite the fact,
 everything is done the way tutorial shows:
 https://docs.djangoproject.com/en/1.10/intro/tutorial05/

 New-created Question objects had not been saved in temporary test
 database.

 Now, polls/tests.py starts from:
 {{{
 def create_question(question_text, days):
 time = timezone.now() + datetime.timedelta(days=days)
 return Question.objects.create(question_text=question_text,
 pub_date=time)
 }}}

 For me works just:
 {{{
 def create_question(question_text, days):
 time = timezone.now() + datetime.timedelta(days=days)
 q = Question.objects.create(question_text=question_text,
 pub_date=time)
 q.save()
 }}}

--

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


Re: [Django] #27715: [Tutorial - part 6.] Lack of saving created question into db

2017-01-10 Thread Django
#27715: [Tutorial - part 6.] Lack of saving created question into db
-+-
 Reporter:  Mesco|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  tutorial | Triage Stage:
  documentation  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 `.create()` does save the object. I guess you might have a mistake
 somewhere. Please see TicketClosingReasons/UseSupportChannels for ways to
 get help.

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


[Django] #27715: [Tutorial - part 6.] Lack of saving created question into db

2017-01-10 Thread Django
#27715: [Tutorial - part 6.] Lack of saving created question into db
-+-
   Reporter:  Mesco  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  1.10
  Documentation  |   Keywords:  tutorial
   Severity:  Normal |  documentation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 I've been wondering for few hours why view tests fails despite the fact,
 everything is done the way tutorial shows:
 https://docs.djangoproject.com/en/1.10/intro/tutorial05/

 New-created Question objects had not been saved in temporary test
 database.

 Now, polls/tests.py is starts from:
 {{{
 def create_question(question_text, days):
 time = timezone.now() + datetime.timedelta(days=days)
 return Question.objects.create(question_text=question_text,
 pub_date=time)
 }}}

 For me works just:
 {{{
 def create_question(question_text, days):
 time = timezone.now() + datetime.timedelta(days=days)
 q = Question.objects.create(question_text=question_text,
 pub_date=time)
 q.save()
 }}}

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

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


Re: [Django] #27710: foreign key _id optimisation leads to incorrect descriptor value

2017-01-10 Thread Django
#27710: foreign key _id optimisation leads to incorrect descriptor value
-+-
 Reporter:  Will Hardy   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (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
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 I thought there might be another ticket where this was proposed and
 possibly rejected as "too magical", but I'm not going to do a search now.
 The idea seems reasonable at first glance.

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


Re: [Django] #27712: Input widget removes `type` from `attrs`.

2017-01-10 Thread Django
#27712: Input widget removes `type` from `attrs`.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   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 Tim Graham):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Ready for checkin


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

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


Re: [Django] #27714: Small visual artifact when clicking inline edit button in admin

2017-01-10 Thread Django
#27714: Small visual artifact when clicking inline edit button in admin
--+
 Reporter:  Anton Samarchyan  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  1
--+

Comment (by Anton Samarchyan):

 I added a [https://github.com/django/django/pull/7830 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/065.9fc039a60ef2d567da08547a5f6147f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27714: Small visual artifact when clicking inline edit button in admin

2017-01-10 Thread Django
#27714: Small visual artifact when clicking inline edit button in admin
-+-
 Reporter:  Anton Samarchyan |Owner:  Anton
 |  Samarchyan
 Type:  Bug  |   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:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Anton Samarchyan):

 * owner:  nobody => Anton Samarchyan
 * status:  new => assigned
 * 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/065.fa3603c678d2fcf6945a4a0665283457%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27714: Small visual artifact when clicking inline edit button in admin (was: Small visual bug in admin)

2017-01-10 Thread Django
#27714: Small visual artifact when clicking inline edit button in admin
--+
 Reporter:  Anton Samarchyan  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  1
--+
Changes (by Tim Graham):

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


Re: [Django] #27711: Questionable "Install Django" option ordering

2017-01-10 Thread Django
#27711: Questionable "Install Django" option ordering
-+-
 Reporter:  Razzi Abuissa|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham):

 Thanks, I reordered as suggested. About removing the distribution packages
 instructions, you could raise that idea on the DevelopersMailingList for
 discussion. I'm not sure how often that's used.

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


Re: [Django] #27711: Questionable "Install Django" option ordering

2017-01-10 Thread Django
#27711: Questionable "Install Django" option ordering
-+-
 Reporter:  Razzi Abuissa|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"5ea2228731674a913790b4a3ab4ca0669843005f" 5ea22287]:
 {{{
 #!CommitTicketReference repository=""
 revision="5ea2228731674a913790b4a3ab4ca0669843005f"
 [1.10.x] Fixed #27711 -- Demoted "Installing a distribution-specific
 package" in install intro.

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


Re: [Django] #27711: Questionable "Install Django" option ordering

2017-01-10 Thread Django
#27711: Questionable "Install Django" option ordering
-+-
 Reporter:  Razzi Abuissa|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"991cd69621f95acd2192ac62a08eb139d3e22215" 991cd696]:
 {{{
 #!CommitTicketReference repository=""
 revision="991cd69621f95acd2192ac62a08eb139d3e22215"
 Fixed #27711 -- Demoted "Installing a distribution-specific package" in
 install intro.
 }}}

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


Re: [Django] #27714: Small visual bug in admin

2017-01-10 Thread Django
#27714: Small visual bug in admin
--+--
 Reporter:  Anton Samarchyan  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  1
--+--
Changes (by Anton Samarchyan):

 * Attachment "Capture du 2017-01-09 18:17:20.png" added.


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

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


[Django] #27714: Small visual bug in admin

2017-01-10 Thread Django
#27714: Small visual bug in admin
+
   Reporter:  Anton Samarchyan  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.admin |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+
 In a situation where I have a foreign key and I am in the admin, I select
 the object and then click edit, I can see a little black underscore after
 I close the popup window which shouldn't be there to my mind. I also
 attach a screenshot.

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


Re: [Django] #27713: Clarify NoReverseMatch error message when view is not found

2017-01-10 Thread Django
#27713: Clarify NoReverseMatch error message when view is not found
-+-
 Reporter:  Marten Kenbeek   |Owner:  Marten
 Type:   |  Kenbeek
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  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 Tim Graham):

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


Re: [Django] #27713: Clarify NoReverseMatch error message when view is not found

2017-01-10 Thread Django
#27713: Clarify NoReverseMatch error message when view is not found
-+-
 Reporter:  Marten Kenbeek   |Owner:  Marten
 Type:   |  Kenbeek
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Marten Kenbeek):

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


[Django] #27713: Clarify NoReverseMatch error message when view is not found

2017-01-10 Thread Django
#27713: Clarify NoReverseMatch error message when view is not found
-+-
   Reporter:  Marten |  Owner:  Marten Kenbeek
  Kenbeek|
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Core   |Version:  master
  (URLs) |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 If no view is found for a specific view name, the error message contains
 the somewhat cryptic clue "0 pattern(s) tried: []". If you're not aware
 what this means, this can easily throw you off the right track to fixing
 this issue. Over the years I've seen a decent number of SO questions about
 NoReverseMatch errors that seem to miss this fact.

 I think we should clarify the error message when no view is found so it is
 clear the error is in the view name, not in the arguments.

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


Re: [Django] #26961: Run admin checks if DEBUG is False

2017-01-10 Thread Django
#26961: Run admin checks if DEBUG is False
-+-
 Reporter:  Adam Chainz  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  checks   | 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:"9daf8c43bdfa9f6418f6f47d202055b97244debe" 9daf8c43]:
 {{{
 #!CommitTicketReference repository=""
 revision="9daf8c43bdfa9f6418f6f47d202055b97244debe"
 Fixed #26961 -- Made admin checks run when DEBUG=False.
 }}}

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


Re: [Django] #27673: System checks for contrib.admin are executed during registration

2017-01-10 Thread Django
#27673: System checks for contrib.admin are executed during registration
-+-
 Reporter:  Johannes Hoppe   |Owner:  Morgan
 |  Aubert
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.10
 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"d57ecf40ebad564fafa36825b17b6c15f13cfc01" d57ecf4]:
 {{{
 #!CommitTicketReference repository=""
 revision="d57ecf40ebad564fafa36825b17b6c15f13cfc01"
 Fixed #27673 -- Made admin's checks run at check time instead of during
 registration.

 Thanks Morgan Aubert for the test.
 }}}

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


Re: [Django] #27712: Input widget removes `type` from `attrs`.

2017-01-10 Thread Django
#27712: Input widget removes `type` from `attrs`.
-+--
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by felixxm):

 * has_patch:  0 => 1
 * version:  1.10 => master


Comment:

 [https://github.com/django/django/pull/7827 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/065.3fa68f49e904df4848b8c25c549fe59c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27712: Input widget removes `type` from `attrs`.

2017-01-10 Thread Django
#27712: Input widget removes `type` from `attrs`.
-+--
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 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 felixxm):

 It's a regression in #15667 that only affects 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.f8bc99ada334bf4e0c5ebfc25ad95878%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27712: Input widget removes `type` from `attrs`.

2017-01-10 Thread Django
#27712: Input widget removes `type` from `attrs`.
-+--
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 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 felixxm):

 * Attachment "27712.diff" added.


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

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


[Django] #27712: Input widget removes `type` from `attrs`.

2017-01-10 Thread Django
#27712: Input widget removes `type` from `attrs`.
--+--
   Reporter:  felixxm |  Owner:  felixxm
   Type:  Bug | Status:  assigned
  Component:  Forms   |Version:  1.10
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
 If you pass the same `attrs` dictionary with `type` key to few `Input`
 widgets then it removes `type` from it.

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

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


Re: [Django] #11974: Submit_row in admin doesn't follow the pattern of using admin/app_label/model/submit_line.html

2017-01-10 Thread Django
#11974: Submit_row in admin doesn't follow the pattern of using
admin/app_label/model/submit_line.html
-+-
 Reporter:  vbmendes |Owner:  Raffaele
 |  Salmaso
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  django admin | Triage Stage:  Accepted
  templates  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Raffaele Salmaso):

 * status:  new => assigned
 * owner:  nobody => Raffaele Salmaso


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