date:20170103

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

2017-01-03 Thread Django

#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> There have been plenty of bug reports and discussions about the problems
> caused for users by MySQL's implementation of the REPEATABLE READ
> transaction isolation level, and the fact that it is the default. Django
> is mostly written for READ COMMITTED; of all supported backends, MySQL is
> the only one to use a different level by default. Things will probably
> run more in line with users expectations under READ COMMITTED, and
> reusable apps' behavior will be more similar across database backends.
>
> Some history: This has been raised already in the [#13906 1.2 era], and
> possibly even before that; the question was raised in different forms
> [#14026 again] and [#21670 again] until one more [#26347 instance] caused
> it to be brought up on the mailing list. To be sure, it wasn't the first
> time the issue was brought to the list either, but
> [https://groups.google.com/forum/#!msg/django-
> developers/6pWbpV1_6Us/a3CNmojACwAJ this discussion] seemed to conclude
> with a rough consensus that the default transaction isolation level for
> MySQL should change. As far as I'm aware, the issue has not been
> discussed since then.
>
> There are two kinds of backwards-compatibility problems I already see
> with this change:
>
> 1) The obvious one -- Apps that are written to be correct under MySQL's
> REPEATABLE READ isolation level may become subtly incorrect by default.
> This is a very real problem, and hard to tackle because writing tests to
> capture the problems is very hard -- one needs to make and use at least
> two separate connections to the same database, and the Django ORM (and
> testing framework) does not make that easy. The counter-argument to that
> is that we likely have plenty of apps -- reusable or otherwise -- that
> are currently subtly wrong because MySQL's REPEATABLE READ semantics is
> surprising and unintuitive.
>
> 2) The less obvious one -- the way to set transaction isolation levels is
> with SQL executed when the connection is opened, and we need to make sure
> we don't interrupt with the user's own `init_command` if there is one.
>
> Some very basic intro to transaction isolation levels in general and
> MySQL's REPEATABLE READ in particular is in my DC.EU.2016 lightning talk
> about this:
> https://opbeat.com/community/posts/lightning-talks-day-1/ (starting
> around 4:00).

New description:

 There have been plenty of bug reports and discussions about the problems
 caused for users by MySQL's implementation of the REPEATABLE READ
 transaction isolation level, and the fact that it is the default. Django
 is mostly written for READ COMMITTED; of all supported backends, MySQL is
 the only one to use a different level by default. Things will probably run
 more in line with users expectations under READ COMMITTED, and reusable
 apps' behavior will be more similar across database backends.

 Some history: This has been raised already in the [ticket:13906 1.2 era],
 and possibly even before that; the question was raised in different forms
 [ticket:14026 again] and [ticket:21670 again] until one more [ticket:26347
 instance] caused it to be brought up on the mailing list. To be sure, it
 wasn't the first time the issue was brought to the list either, but
 [https://groups.google.com/forum/#!msg/django-
 developers/6pWbpV1_6Us/a3CNmojACwAJ this discussion] seemed to conclude
 with a rough consensus that the default transaction isolation level for
 MySQL should change. As far as I'm aware, the issue has not been discussed
 since then.

 There are two kinds of backwards-compatibility problems I already see with
 this change:

 1) The obvious one -- Apps that are written to be correct under MySQL's
 REPEATABLE READ isolation level may become subtly incorrect by default.
 This is a very real problem, and hard to tackle because writing tests to
 capture the problems is very hard -- one needs to make and use at least
 two separate connections to the same database, and the Django ORM (and
 testing framework) does not make that easy. The counter-argument to that
 is that we likely have plenty of apps -- reusable or

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

2017-01-03 Thread Django

Comment (by Shai Berger):

Replying to [comment:1 Adam Chainz]:
> An alternative to changing the default would be to have a system check
highly recommending READ-COMMITTED [...] "Warning: In Django 2.1 the
default tx_isolation will change..."

That may indeed be the way to go. Two issues arise:

1) We need to make sure which deprecations can happen when (WRT our
deprecation policies around LTSs)
2) It may be seen as annoying: "if you know that it's correct to use that
other level, why don't you just go and do it? why bug me?"

The big advantage is that it completely solves my 2nd backward-
compatibility issue.

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

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

Re: [Django] #24423: Combine i18n template tag tests

2017-01-03 Thread Django

#24423: Combine i18n template tag tests
-+-
 Reporter:  Preston Timmons  |Owner:  Andy
 Type:   |  Craze
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Martin):

 * needs_better_patch:  0 => 1


Comment:

 The patch looks good to me, but IIUC you need to squash it into a single
 commit with a message following the correct commit message format.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.d2efb7f4edf996fc9eaa6f58d04be598%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-03 Thread Django

Comment (by Adam Chainz):

An alternative to changing the default would be to have a system check
highly recommending READ-COMMITTED, similar to what we do for MySQL's
`sql_mode` (see

https://github.com/django/django/blob/master/django/db/backends/mysql/validation.py#L6
). This would also help educate users a bit more about the change.
Possibly this could be part of a path to changing the default... "Warning:
In Django 2.1 the default tx_isolation will 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.a66bcfbb7a45400eb242e71f0b073c0d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

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

2017-01-03 Thread Django

#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
Reporter: Shai | Owner: nobody
Berger |
Type: New| Status: new
feature|
Component: Database |Version: master
layer (models, ORM)|
Severity: Release| Keywords:
blocker|
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 1 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+-
There have been plenty of bug reports and discussions about the problems
caused for users by MySQL's implementation of the REPEATABLE READ
transaction isolation level, and the fact that it is the default. Django
is mostly written for READ COMMITTED; of all supported backends, MySQL is
the only one to use a different level by default. Things will probably run
more in line with users expectations under READ COMMITTED, and reusable
apps' behavior will be more similar across database backends.

Some history: This has been raised already in the [#13906 1.2 era], and
possibly even before that; the question was raised in different forms
[#14026 again] and [#21670 again] until one more [#26347 instance] caused
it to be brought up on the mailing list. To be sure, it wasn't the first
time the issue was brought to the list either, but
[https://groups.google.com/forum/#!msg/django-
developers/6pWbpV1_6Us/a3CNmojACwAJ this discussion] seemed to conclude
with a rough consensus that the default transaction isolation level for
MySQL should change. As far as I'm aware, the issue has not been discussed
since then.

There are two kinds of backwards-compatibility problems I already see with
this change:

1) The obvious one -- Apps that are written to be correct under MySQL's
REPEATABLE READ isolation level may become subtly incorrect by default.
This is a very real problem, and hard to tackle because writing tests to
capture the problems is very hard -- one needs to make and use at least
two separate connections to the same database, and the Django ORM (and
testing framework) does not make that easy. The counter-argument to that
is that we likely have plenty of apps -- reusable or otherwise -- that are
currently subtly wrong because MySQL's REPEATABLE READ semantics is
surprising and unintuitive.

2) The less obvious one -- the way to set transaction isolation levels is
with SQL executed when the connection is opened, and we need to make sure
we don't interrupt with the user's own `init_command` if there is one.

Some very basic intro to transaction isolation levels in general and
MySQL's REPEATABLE READ in particular is in my DC.EU.2016 lightning talk
about this:
https://opbeat.com/community/posts/lightning-talks-day-1/ (starting around
4:00).

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

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

Re: [Django] #26099: Add a warning about import conflicts when auto-generating migrations

2017-01-03 Thread Django

#26099: Add a warning about import conflicts when auto-generating migrations
--+
 Reporter:  LucidComplex  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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 Alexey Kotlyarov):

 This doesn't change anything _by itself_, as an app can still be named
 `django_settings`.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.d99177c5484d765742b894da9b18a30e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26099: Add a warning about import conflicts when auto-generating migrations

2017-01-03 Thread Django

#26099: Add a warning about import conflicts when auto-generating migrations
--+
 Reporter:  LucidComplex  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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 Anton Samarchyan):

 So we want to have something like this if the app name is settings?

 {{{
 from __future__ import unicode_literals

 from django.conf import settings as django_settings
 from django.db import migrations, models
 import django.db.models.deletion


 class Migration(migrations.Migration):

 initial = True

 dependencies = [
 migrations.swappable_dependency(django_settings.AUTH_USER_MODEL),
 ]

 operations = [
 migrations.CreateModel(
 name='Test',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ('user', models.ForeignKey(blank=True, null=True,
 on_delete=django.db.models.deletion.SET_NULL,
 to=django_settings.AUTH_USER_MODEL)),
 ],
 ),
 ]

 }}}

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

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

Re: [Django] #27682: Add more dependencies to extras_require (eg sqlparse, PyYAML)

2017-01-03 Thread Django

#27682: Add more dependencies to extras_require (eg sqlparse, PyYAML)
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Packaging|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton):

 I think I like this idea, but it's probably a change sufficient enough to
 bring up on the mailing list https://groups.google.com/forum/#!forum
 /django-developers

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.612ec14d7c853a42a4e3ea128b41c113%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25912: Add binary left/right shift operators to F expressions

2017-01-03 Thread Django

#25912: Add binary left/right shift operators to F expressions
-+-
 Reporter:  anabelensc   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"1c12df4aa6c599959d9eb6de2076bf8aa6e301d6" 1c12df4a]:
 {{{
 #!CommitTicketReference repository=""
 revision="1c12df4aa6c599959d9eb6de2076bf8aa6e301d6"
 Fixed #25912 -- Added binary left/right shift operators to F expressions.

 Thanks Mariusz Felisiak for review and MySQL advice.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.962ae3053575c000c897ea826507f569%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27682: Add more dependencies to extras_require (eg sqlparse, PyYAML)

2017-01-03 Thread Django

#27682: Add more dependencies to extras_require (eg sqlparse, PyYAML)
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Packaging|  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 Ed Morley):

 * owner:  nobody => Ed Morley


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.d0ffe7afd2359abe15b81667b8c43a08%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27682: Add more dependencies to extras_require (eg sqlparse, PyYAML)

2017-01-03 Thread Django

#27682: Add more dependencies to extras_require (eg sqlparse, PyYAML)
+--
   Reporter:  Ed Morley |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  assigned
  Component:  Packaging |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 |
+--
 There are several optional Django features that require third-party Python
 packages that (intentionally) aren't specified as `install_requires`
 dependencies in setup.py, since not everyone would want them installed.

 For example:
 * PyYAML for the yaml serializer
 * sqlparse for multi-line SQL statements for migrations `RunSQL`
 * Database drivers

 Adding these as `extras_require` [*] entries has the following advantages:

 1) The reason for the packages is now self-documenting. eg:
 {{{
 Django[sqlparse,yaml]
 }}}
 ...instead of:
 {{{
 Django

 # Required by Django's migration system for RunSQL commands.
 sqlparse

 # Required by Django's YAML serializer.
 PyYAML
 }}}

 2) Django could in the future manage the preferred package for a
 particular feature in cases where there is a choice (eg mysqlclient vs
 MySQL-python). Users can still override by not using the `extras_require`
 alias (or there could even be multiple aliases).

 3) If a new major version of Django stops requiring a particular
 `extras_require` dependency, users will know to remove it from their
 requirements files, since pip will warn there is no such extra listed.


 [*] http://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-
 extras-optional-features-with-their-own-dependencies

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.53e3b043a8652227baedce6c579abd2d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27575: potential commonmiddleware optimization

2017-01-03 Thread Django

#27575: potential commonmiddleware optimization
--+
 Reporter:  JorisBenschop |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Anton Samarchyan):

 A function get_host could be renamed to get_host_and_validate

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.61338021e1591c59acd79e4dcda4958a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27575: potential commonmiddleware optimization

2017-01-03 Thread Django

#27575: potential commonmiddleware optimization
--+
 Reporter:  JorisBenschop |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by JorisBenschop):

 Wouldnt refactoring this function (validate_host?) make sense if it does a
 lot more than retrieving a hostname?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.03f8519459daf74aa36ed2dcb59858b5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27575: potential commonmiddleware optimization

2017-01-03 Thread Django

#27575: potential commonmiddleware optimization
--+
 Reporter:  JorisBenschop |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 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 Anton Samarchyan):

 * cc: desecho@… (added)


Comment:

 We could add a comment in process_request method
 {{{
 host = request.get_host()  # Also perform host validation
 }}}

 And probably in get_host method as well

 {{{
 """Return the HTTP host using the environment or request headers. Perform
 host validation."""
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.79b2803ed6e8e416f1b602bae4016a3a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27559: Admin changelist turns GET QueryDict into dict which may lose parameters

2017-01-03 Thread Django

#27559: Admin changelist turns GET QueryDict into dict which may lose parameters
--+
Reporter: Jonas von Poser |Owner: (none)
Type: Cleanup/optimization | 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: 0 |UI/UX: 0
--+
Changes (by Ling-Xiao Yang):

* status: assigned => new
* owner: Ling-Xiao Yang => (none)

Comment:

I didn't find a good way of ensuring the backward compatibility, as this
turned out as a conceptual problem that has existed for a long time:

1. The admin filters are single-valued by definition

([https://github.com/django/django/blob/f0ef0c49e9284f262fbc63e8a497699ca4a248fe/django/contrib/admin/filters.py#L74-L75
example]) and this is semantically shown as `self.value()` in the code
example of

[https://docs.djangoproject.com/en/1.10/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_filter
related doc].

2. The `dict`-typed GET parameters are further

[https://github.com/django/django/blob/f0ef0c49e9284f262fbc63e8a497699ca4a248fe/django/contrib/admin/views/main.py#L114
passed from `ChangeList` view to filter classes], which would require a
change in both sides.

3. There is a `ChangeList.get_query_string` method that accepts an
additional `dict`-typed parameter (`new_params`) to allow modification of
GET parameters, see

[https://github.com/django/django/blob/f0ef0c49e9284f262fbc63e8a497699ca4a248fe/django/contrib/admin/filters.py#L74-L75
code]. And this method has been used in many places like

[https://github.com/django/django/blob/f0ef0c49e9284f262fbc63e8a497699ca4a248fe/django/contrib/admin/filters.py#L106
1],

[https://github.com/django/django/blob/f0ef0c49e9284f262fbc63e8a497699ca4a248fe/django/contrib/admin/templatetags/admin_list.py#L44
2],

[https://github.com/django/django/blob/f0ef0c49e9284f262fbc63e8a497699ca4a248fe/django/contrib/admin/templatetags/admin_list.py#L175
3] and so on. If we change every `dict` to `QueryDict`, it would be more
of a systematic change.

4. I considered an implicit OR connection of SQL queries in my last
comment, in order to restrict changes in `ChangeList` only, but this may
not be a good idea. First,
[https://tools.ietf.org/html/rfc3986#section-3.4 RFC 3986] has no
definition on the meaning of multi-valued GET parameter. Also, in the
other extension package django-filters, both OR and AND logic are allowed
in its `MultipleChoiceFilter`, see [http://django-
filter.readthedocs.io/en/develop/ref/filters.html#multiplechoicefilter its
doc]. So a multi-valued GET parameter such as `state=1=2` does not
necessarily mean an OR relationship in the filtering process.

I'm deassigning myself here. More people are welcomed to look at this
issue.

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

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

Re: [Django] #27659: Arbritrary file overrides in startproject/app template extraction

2017-01-03 Thread Django

#27659: Arbritrary file overrides in startproject/app template extraction
---+
 Reporter:  Florian Apolloner  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Florian Apolloner):

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

Re: [Django] #27659: Arbritrary file overrides in startproject/app template extraction

2017-01-03 Thread Django

#27659: Arbritrary file overrides in startproject/app template extraction
---+
 Reporter:  Florian Apolloner  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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 Anton Samarchyan):

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

Re: [Django] #27680: Recommend ccbv.co.uk in class-based views docs

2017-01-03 Thread Django

#27680: Recommend ccbv.co.uk in class-based views docs
--+
 Reporter:  James Pic |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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 Emett Speer):

 I do believe that the site is well done and a really good resource. With
 that being said there is a real issue with the Django documentation for
 this if it requires a 3rd party website for people to understand them. I
 do not clam to have the answer but think its worth talking about how we
 could make the class based views documentation better.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.6dac88d55c6409900ec815d0afa06564%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26621: simplify_regex handles named capture groups incorrectly

2017-01-03 Thread Django

#26621: simplify_regex handles named capture groups incorrectly
---+---
 Reporter:  Alex Rothberg  |Owner:  Ketan Bhatt
 Type:  Bug|   Status:  closed
Component:  contrib.admindocs  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f0ef0c49e9284f262fbc63e8a497699ca4a248fe" f0ef0c4]:
 {{{
 #!CommitTicketReference repository=""
 revision="f0ef0c49e9284f262fbc63e8a497699ca4a248fe"
 Fixed #26621 -- Corrected simplify_regex()'s handling of named capture
 groups.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.24803bf5e6147f4be567078b78db5446%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27635: django.utils.crypto should use secrets on Python 3.6+

2017-01-03 Thread Django

Comment (by Emett Speer):

Replying to [comment:3 Tim Graham]:
> Python's `secrets.py` does `from random import SystemRandom` so this
doesn't change any behavior or add security for now. Adam said,
"Presumably the intention is that secrets might one day use a different
PRNG's on some OS's." Let's make the change if the benefits become more
than theoretical or when only Python 3.6+ is supported.
>
> Another possibility Aymeric mentioned, "In the long run I think we
should deprecate get_random_string in favor of similar functions provided
by the secrets module. I didn't check whether there was a sensible
transition plan to make use of secrets on Python 3.6 while still
supporting older versions."

I'm with you on this. The vast majority of people are not going to use
this for a long time and it will add an extra bit of overhead just to
support an update in a single version of Python none of the big distros
ship. Once more of the Django community has migrated to Python3.6+ it
would be worth looking into.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.55ed8bd43e516849876df5378cba223a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27680: Recommend ccbv.co.uk in class-based views docs

2017-01-03 Thread Django

#27680: Recommend ccbv.co.uk in class-based views docs
--+
 Reporter:  James Pic |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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):

 We're very conservative about endorsing third-party websites in the
 documentation, however, I don't think the interactive functionality that
 site provides can be duplicated in our documentation. If it were to stop
 being maintained, I think there's a good chance the Django Software
 Foundation would adopt 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/062.f666e03ea772a8ff1457fd2c51de3b36%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27680: Recommend ccbv.co.uk in class-based views docs

2017-01-03 Thread Django

#27680: Recommend ccbv.co.uk in class-based views docs
--+
 Reporter:  James Pic |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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 Emett Speer):

 It may just be worth updating the documentation to make it more clear
 rather then relying on a 3rd party website no matter how good that site
 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/062.1d87e8eefbeaaf40b082fc805eed5666%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27681: Binary &/| operators work incorrectly for negative values on MySQL

2017-01-03 Thread Django

#27681: Binary &/| operators work incorrectly for negative values on MySQL
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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:"fd2f7e47671239dcff98cfb91ab170aa6461" fd2f7e47]:
 {{{
 #!CommitTicketReference repository=""
 revision="fd2f7e47671239dcff98cfb91ab170aa6461"
 Fixed #27681 -- Fixed binary &/| operators for negative values on MySQL.
 }}}

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

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

Re: [Django] #2856: Admin's Recent Actions will link to a 404 when an object has been deleted.

2017-01-03 Thread Django

#2856: Admin's Recent Actions will link to a 404 when an object has been 
deleted.
-+-
 Reporter:  anonymous|Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"27267afc4137142e4f0b36c83cec861ee6924186" 27267afc]:
 {{{
 #!CommitTicketReference repository=""
 revision="27267afc4137142e4f0b36c83cec861ee6924186"
 Fixed #2856 -- Replaced some 404s with messages in admin.

 Instead of a 404, return a redirect to admin index page with a message
 indicating that the requested object does not exist. This avoids the
 admin returning 404 from "Recent Actions" links for deleted objects.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.6fc48c1f5212c82ababf8df4886b14e1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27681: Binary &/| operators work incorrectly for negative values on MySQL

2017-01-03 Thread Django

#27681: Binary &/| operators work incorrectly for negative values on MySQL
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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.6315b059f2fff21ca0104e4403fe445c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27681: Binary &/| operators work incorrectly for negative values on MySQL

2017-01-03 Thread Django

#27681: Binary &/| operators work incorrectly for negative values on MySQL
-+-
   Reporter:  felixxm|  Owner:  felixxm
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 MySQL's binary operators return an unsigned 64-bit integer which means
 they don't return the same results as other databases.

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

Re: [Django] #26802: Sending mails with attachment results in 'bytes' object has no attribute 'encode'

2017-01-03 Thread Django

#26802: Sending mails with attachment results in 'bytes' object has no attribute
'encode'
-+-
 Reporter:  Brandl   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  1.9
 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
-+-

Comment (by Claude Paroz):

 This was not backported to 1.10, so you'll have to wait for Django 1.11.

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

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

Re: [Django] #26802: Sending mails with attachment results in 'bytes' object has no attribute 'encode'

2017-01-03 Thread Django

#26802: Sending mails with attachment results in 'bytes' object has no attribute
'encode'
-+-
 Reporter:  Brandl   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  1.9
 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
-+-

Comment (by Harris Lapiroff):

 What version of Django is this set to be merged into? I ran into this bug
 on 1.10.3 and 1.10.4.

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

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

Re: [Django] #27680: Recommend ccbv.co.uk in class-based views docs (was: Advertise ccbv.co.uk in CBV/intro)

2017-01-03 Thread Django

#27680: Recommend ccbv.co.uk in class-based views docs
--+
 Reporter:  James Pic |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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
 * type:  New feature => Cleanup/optimization


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.987be80f7109e1d08c0bd620a153f93f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25004: Add an OpenLayers 3 compatible map widget

2017-01-03 Thread Django

#25004: Add an OpenLayers 3 compatible map widget
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"946dd5bde2c228d6862d6ea9d0060fc0e72d5ed6" 946dd5bd]:
 {{{
 #!CommitTicketReference repository=""
 revision="946dd5bde2c228d6862d6ea9d0060fc0e72d5ed6"
 Refs #25004 -- Fixed test failure introduced by OpenLayers 3 update.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.d0fc1f2e505c8d3501d43ec0d0fbc5f2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27680: Advertise ccbv.co.uk in CBV/intro

2017-01-03 Thread Django

#27680: Advertise ccbv.co.uk in CBV/intro
---+--
 Reporter:  James Pic  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.10
 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 James Pic):

 * has_patch:  0 => 1


Old description:

> Some users have reported difficulties using CBV, and there's a thread
> about deprecating them: https://groups.google.com/forum/#!topic/django-
> developers/u1aLYz3fAUw
>
> The root cause seems to be that users have hard time finding their way in
> the class hierarchy and a website has been made specially for that:
> ccbv.co.uk
>
> However, that website is so far only mentioned in the team page (in Marc
> Tamlyn's section). This ticket proposes to try harder to spread the word
> about it and help reducing the amount of users in difficulty when trying
> to find their way in the hierarchy.

New description:

 Some users have reported difficulties using CBV, and there's a thread
 about deprecating them: https://groups.google.com/forum/#!topic/django-
 developers/u1aLYz3fAUw

 The root cause seems to be that users have hard time finding their way in
 the class hierarchy and a website has been made specially for that:
 ccbv.co.uk

 However, that website is so far only mentioned in the team page (in Marc
 Tamlyn's section). This ticket proposes to try harder to spread the word
 about it and help reducing the amount of users in difficulty when trying
 to find their way in the hierarchy.

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

--

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.4448dabf215b6c47f3d3eced1e18c331%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27680: Advertise ccbv.co.uk in CBV/intro

2017-01-03 Thread Django

#27680: Advertise ccbv.co.uk in CBV/intro
-+
Reporter: James Pic | Owner: nobody
Type: New feature| Status: new
Component: Documentation |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 |
-+
Some users have reported difficulties using CBV, and there's a thread
about deprecating them: https://groups.google.com/forum/#!topic/django-
developers/u1aLYz3fAUw

The root cause seems to be that users have hard time finding their way in
the class hierarchy and a website has been made specially for that:
ccbv.co.uk

However, that website is so far only mentioned in the team page (in Marc
Tamlyn's section). This ticket proposes to try harder to spread the word
about it and help reducing the amount of users in difficulty when trying
to find their way in the hierarchy.

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

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.202e20c9dd5d2978d0c440c8fffb92b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27679: Empty formsets should display max(min_num, extra) rather than min_num+extra (was: Formsets: min_num and extra)

2017-01-03 Thread Django

#27679: Empty formsets should display max(min_num, extra) rather than 
min_num+extra
-+-
 Reporter:  Lorenzo Peña |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  1.9
 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 Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Forms


Comment:

 You should say a little more to strengthen your proposal. For example,
 what are the ramifications for backwards compatibility? What does the
 documentation say about this?

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

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

[Django] #27679: Formsets: min_num and extra

2017-01-03 Thread Django

#27679: Formsets: min_num and extra
-+
   Reporter:  Lorenzo Peña   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.9
   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  |
-+
 I already read #22628

 To me: min_num is an option for validation and extra is an option for
 presentation
 Currently, in an empty formset, you get min_num+extra empty forms, I think
 it should be max(min_num, extra) instead

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.79ab6138ba5c1cbb891189fa00ed671b%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-03 Thread Django

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

 * cc: raffaele.salmaso+djangoproject@… (added)
 * needs_tests:  1 => 0


Comment:

 Added a PR => https://github.com/django/django/pull/7782

 Hi, I've  usually customize the submit row of many models in my admin.
 At first I've used a similar strategy from the former patch (using
 render_to_string), but while working with my setup (only one admin.site),
 half of admin_views tests were broken. So this is why I used the
 InclusionNode for SubmitRowNode parent class.
 Additionally I've added a { block submit-row %}{% endblock %} in default
 submit_line.html.

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

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

Re: [Django] #8500: Allow overriding of default adminsite.

2017-01-03 Thread Django

#8500: Allow overriding of default adminsite.
+
 Reporter:  oyvind  |Owner:  oyvind
 Type:  New feature |   Status:  new
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  override adminsite  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Raffaele Salmaso):

 * cc: raffaele.salmaso+djangoproject@… (added)


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

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

Re: [Django] #9739: Admin does not correctly prefill DataTimeField from URL

2017-01-03 Thread Django

#9739: Admin does not correctly prefill DataTimeField from URL
---+-
 Reporter:  gilhad |Owner:  Ridley Larsen
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.0
 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 Gilhad):

 I updated to Djago 1.10 on more sites, the problem still remains (cannot
 prefill admins datetime field) and the original fix still works (just the
 lines moved after line 1404 now).

 Would be possible to somehow resolve it and incorporate it in main stream,
 so I would not be forced to manually patch it each and every version?
 Please, prettty, pretty please ...

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

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

Re: [Django] #25004: Add an OpenLayers 3 compatible map widget

2017-01-03 Thread Django

#25004: Add an OpenLayers 3 compatible map widget
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"fdb23096040edbd2ec886e4227143b19fe04247a" fdb2309]:
 {{{
 #!CommitTicketReference repository=""
 revision="fdb23096040edbd2ec886e4227143b19fe04247a"
 Refs #25004 -- Replaced PNGs with SVGs
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.4f08fbabed48f78566da85462efe20e5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25004: Add an OpenLayers 3 compatible map widget

2017-01-03 Thread Django

#25004: Add an OpenLayers 3 compatible map widget
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"2ebfda38e65177dfc7d6e90457ffa4a0fa2796f0" 2ebfda38]:
 {{{
 #!CommitTicketReference repository=""
 revision="2ebfda38e65177dfc7d6e90457ffa4a0fa2796f0"
 Fixed #25004 -- Updated OpenLayers-based widget to OpenLayers 3

 Thanks Tim Graham for the review.
 }}}

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

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

39 matches

Mail list logo