Re: [Django] #30725: Textbox size of a DateTimeField with local timezone in settings becomes too small in admin.TabularInline when browser windows is made smaller

2019-09-10 Thread Django
#30725: Textbox size of a DateTimeField with local timezone in settings becomes 
too
small in admin.TabularInline when browser windows is made smaller
-+-
 Reporter:  Basil Eric Rabi  |Owner:  Utkarsh
 |  Rajwansh
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.2
 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 Min ho Kim):

 Hi Basil Eric Rabi,
 I don't think it's related to the settings either, changing TIME_ZONE =
 'Asia/Manila' doesn't do anything.
 It looks like a CSS issue like Carlton said (not your CSS file).

 {{{

 django>contrib>admin>static>admin>css>widgets.css>
 min-width: 0;

 }}}

 What browser are you using? and what version is it?
 If it's not the latest version, could you upgrade the browser and see if
 it still exist?

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

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


Re: [Django] #27452: Add Postgres serial field to contrib.postgres

2019-09-10 Thread Django
#27452: Add Postgres serial field to contrib.postgres
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 |  Hoppe
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  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 Johannes Hoppe):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.84714f940d52995552c111a960ca6a04%40djangoproject.com.


Re: [Django] #30725: Textbox size of a DateTimeField with local timezone in settings becomes too small in admin.TabularInline when browser windows is made smaller (was: Textbox size of a DateTimeField

2019-09-10 Thread Django
#30725: Textbox size of a DateTimeField with local timezone in settings becomes 
too
small in admin.TabularInline when browser windows is made smaller
-+-
 Reporter:  Basil Eric Rabi  |Owner:  Utkarsh
 |  Rajwansh
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.2
 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
-+-

Old description:

> I have a model with a DateTimeField and used it in admin.TabularInline
> for the Django Admin. When the browser window is wide enough there are no
> issues. But when the browser window is made smaller or when you use a
> phone to view the admin page, you can't see the text inside the text box
> for the date and time since the boxes become too small.

New description:

 I have a model with a DateTimeField and used it in admin.TabularInline for
 the Django Admin using `TIME_ZONE = 'Asia/Manila'` in `settings.py`. When
 the browser window is wide enough there are no issues. But when the
 browser window is made smaller or when you use a phone to view the admin
 page, you can't see the text inside the text box for the date and time
 since the boxes become too small.

--

Comment (by Basil Eric Rabi):

 Hi Min ho Kim,

 I'm sorry for the lacking information. I just tried to do a minimal
 reproducible example and found out what was missing was the `TIME_ZONE =
 'Asia/Manila'` in `settings.py`. It seems the bug is not triggered if
 `TIME_ZONE = 'UTC'`. I updated the bug description.

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

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


Re: [Django] #30591: MySQL: 1215 - "Cannot add foreign key constraint" when altering type of unique field referenced by ForeignKey.

2019-09-10 Thread Django
#30591: MySQL: 1215 - "Cannot add foreign key constraint" when altering type of
unique field referenced by ForeignKey.
--+--
 Reporter:  Cornelis Poppema  |Owner:  Adnan Umer
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Adnan Umer):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.44fc5c6bfd3ed41b5be6722730909682%40djangoproject.com.


Re: [Django] #30725: Textbox size of a DateTimeField becomes too small in admin.TabularInline when browser windows is made smaller

2019-09-10 Thread Django
#30725: Textbox size of a DateTimeField becomes too small in admin.TabularInline
when browser windows is made smaller
-+-
 Reporter:  Basil Eric Rabi  |Owner:  Utkarsh
 |  Rajwansh
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.2
 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 Min ho Kim):

 * cc: Min ho Kim (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f29d6c80a17da678d85b33d464fc0fe9%40djangoproject.com.


Re: [Django] #30725: Textbox size of a DateTimeField becomes too small in admin.TabularInline when browser windows is made smaller

2019-09-10 Thread Django
#30725: Textbox size of a DateTimeField becomes too small in admin.TabularInline
when browser windows is made smaller
-+-
 Reporter:  Basil Eric Rabi  |Owner:  Utkarsh
 |  Rajwansh
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.2
 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 Min ho Kim):

 Hi Basil Eric Rabi,
 I tried to reproduce the issue as well, but couldn't make it.

 I made my admin look like your screenshot with DateTimeField in
 TabularInline along with CharField and TextField.
 But none of the fields, including DateTimeField, shrunk at any screen size
 I can test.
 It just becomes scrollable all the way through, and DateTimeField input
 box size changes very slightly as you resize the screen.

 I tried Django version 2.2 and master.
 Tried on current versions of Chrome and FireFox, checking different screen
 sizes for various devices, and tried on my mobile phone.

 I think we need more information here.

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

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


Re: [Django] #30446: Automatically resolve Value's output_field for stdlib types.

2019-09-10 Thread Django
#30446: Automatically resolve Value's output_field for stdlib types.
-+-
 Reporter:  Ozan Gerdaneri   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  SearchVector,| Triage Stage:  Accepted
  SearchVectorField , Value  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Matt Westcott):

 * cc: Matt Westcott (added)


Comment:

 In case it hasn't already been noted - the example above did previously
 work in 2.2, and the error is a regression in 2.2.1, specifically this
 commit:
 
https://github.com/django/django/commit/88bf635c356b4d3a47e88dc4142b90060ce3c2ef
 . As such, I think this might justify being upgraded to a bug.

 (FWIW, we encountered this independently here:
 https://github.com/wagtail/wagtail/issues/5547)

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

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


Re: [Django] #30769: Access Json Key over annotated field in subquery

2019-09-10 Thread Django
#30769: Access Json Key over annotated field in subquery
--+--
 Reporter:  Tim Kleinschmidt  |Owner:  nobody
 Type:  Uncategorized |   Status:  new
Component:  Uncategorized |  Version:  1.11
 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 Tim Kleinschmidt:

Old description:

> {{{
> TypeError: can only concatenate tuple (not "list") to tuple
>   File "django/core/handlers/exception.py", line 41, in inner
> response = get_response(request)
>   File "django/core/handlers/base.py", line 187, in _get_response
> response = self.process_exception_by_middleware(e, request)
>   File "django/core/handlers/base.py", line 185, in _get_response
> response = wrapped_callback(request, *callback_args,
> **callback_kwargs)
>   File "django/contrib/auth/decorators.py", line 23, in _wrapped_view
> return view_func(request, *args, **kwargs)
>   File "apps/dashboard/companies/employee_list.py", line 395, in
> company_employee_view
> RequestConfig(request, paginate={'per_page': 25}).configure(table)
>   File "django_tables2/config.py", line 59, in configure
> table.paginate(**kwargs)
>   File "django_tables2/tables.py", line 526, in paginate
> self.page = self.paginator.page(page)
>   File "django/core/paginator.py", line 57, in page
> number = self.validate_number(number)
>   File "django/core/paginator.py", line 46, in validate_number
> if number > self.num_pages:
>   File "django/utils/functional.py", line 35, in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "django/core/paginator.py", line 91, in num_pages
> if self.count == 0 and not self.allow_empty_first_page:
>   File "django/utils/functional.py", line 35, in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "django/core/paginator.py", line 84, in count
> return len(self.object_list)
>   File "django_tables2/rows.py", line 341, in __len__
> length = len(self.data)
>   File "django_tables2/data.py", line 140, in __len__
> self._length = self.data.count()
>   File "django/db/models/query.py", line 364, in count
> return self.query.get_count(using=self.db)
>   File "django/db/models/sql/query.py", line 499, in get_count
> number = obj.get_aggregation(using, ['__count'])['__count']
>   File "django/db/models/sql/query.py", line 463, in get_aggregation
> outer_query.add_subquery(inner_query, using)
>   File "django/db/models/sql/subqueries.py", line 209, in add_subquery
> self.subquery, self.sub_params =
> query.get_compiler(using).as_sql(with_col_aliases=True)
>   File "django/db/models/sql/compiler.py", line 441, in as_sql
> where, w_params = self.compile(self.where) if self.where is not None
> else ("", [])
>   File "django/db/models/sql/compiler.py", line 373, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "django/db/models/sql/where.py", line 79, in as_sql
> sql, params = compiler.compile(child)
>   File "django/db/models/sql/compiler.py", line 373, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "django/db/models/sql/where.py", line 79, in as_sql
> sql, params = compiler.compile(child)
>   File "django/db/models/sql/compiler.py", line 373, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "django/db/models/lookups.py", line 169, in as_sql
> lhs_sql, params = self.process_lhs(compiler, connection)
>   File "django/db/models/lookups.py", line 160, in process_lhs
> compiler, connection, lhs)
>   File "django/db/models/lookups.py", line 82, in process_lhs
> return compiler.compile(lhs)
>   File "django/db/models/sql/compiler.py", line 373, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "django/contrib/postgres/fields/jsonb.py", line 110, in as_sql
> return '(%s %s %%s)' % (lhs, self.operator), params + [lookup]
> AttributeError: 'BoundRows' object has no attribute 'count'
>   File "django/core/paginator.py", line 79, in count
> return self.object_list.count()
> }}}
>
> Code which leads to the error
> {{{
> # Base Query Construct
> auth_query =
> UserAuth.objects.filter(user_id=OuterRef('user_id')).order_by(
> '-received_at')[:1]
> base_employees = (
> base_employees.annotate(auth_received_at=Subquery(auth_query.values('received_at')),
> auth_response=Subquery(auth_query.values('response'
>
>  # Q object building
>  q  = Q()
>  if 

[Django] #30769: Access Json Key over annotated field in subquery

2019-09-10 Thread Django
#30769: Access Json Key over annotated field in subquery
+
   Reporter:  Tim Kleinschmidt  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Uncategorized |Version:  1.11
   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 |
+
 {{{
 TypeError: can only concatenate tuple (not "list") to tuple
   File "django/core/handlers/exception.py", line 41, in inner
 response = get_response(request)
   File "django/core/handlers/base.py", line 187, in _get_response
 response = self.process_exception_by_middleware(e, request)
   File "django/core/handlers/base.py", line 185, in _get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "django/contrib/auth/decorators.py", line 23, in _wrapped_view
 return view_func(request, *args, **kwargs)
   File "apps/dashboard/companies/employee_list.py", line 395, in
 company_employee_view
 RequestConfig(request, paginate={'per_page': 25}).configure(table)
   File "django_tables2/config.py", line 59, in configure
 table.paginate(**kwargs)
   File "django_tables2/tables.py", line 526, in paginate
 self.page = self.paginator.page(page)
   File "django/core/paginator.py", line 57, in page
 number = self.validate_number(number)
   File "django/core/paginator.py", line 46, in validate_number
 if number > self.num_pages:
   File "django/utils/functional.py", line 35, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "django/core/paginator.py", line 91, in num_pages
 if self.count == 0 and not self.allow_empty_first_page:
   File "django/utils/functional.py", line 35, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "django/core/paginator.py", line 84, in count
 return len(self.object_list)
   File "django_tables2/rows.py", line 341, in __len__
 length = len(self.data)
   File "django_tables2/data.py", line 140, in __len__
 self._length = self.data.count()
   File "django/db/models/query.py", line 364, in count
 return self.query.get_count(using=self.db)
   File "django/db/models/sql/query.py", line 499, in get_count
 number = obj.get_aggregation(using, ['__count'])['__count']
   File "django/db/models/sql/query.py", line 463, in get_aggregation
 outer_query.add_subquery(inner_query, using)
   File "django/db/models/sql/subqueries.py", line 209, in add_subquery
 self.subquery, self.sub_params =
 query.get_compiler(using).as_sql(with_col_aliases=True)
   File "django/db/models/sql/compiler.py", line 441, in as_sql
 where, w_params = self.compile(self.where) if self.where is not None
 else ("", [])
   File "django/db/models/sql/compiler.py", line 373, in compile
 sql, params = node.as_sql(self, self.connection)
   File "django/db/models/sql/where.py", line 79, in as_sql
 sql, params = compiler.compile(child)
   File "django/db/models/sql/compiler.py", line 373, in compile
 sql, params = node.as_sql(self, self.connection)
   File "django/db/models/sql/where.py", line 79, in as_sql
 sql, params = compiler.compile(child)
   File "django/db/models/sql/compiler.py", line 373, in compile
 sql, params = node.as_sql(self, self.connection)
   File "django/db/models/lookups.py", line 169, in as_sql
 lhs_sql, params = self.process_lhs(compiler, connection)
   File "django/db/models/lookups.py", line 160, in process_lhs
 compiler, connection, lhs)
   File "django/db/models/lookups.py", line 82, in process_lhs
 return compiler.compile(lhs)
   File "django/db/models/sql/compiler.py", line 373, in compile
 sql, params = node.as_sql(self, self.connection)
   File "django/contrib/postgres/fields/jsonb.py", line 110, in as_sql
 return '(%s %s %%s)' % (lhs, self.operator), params + [lookup]
 AttributeError: 'BoundRows' object has no attribute 'count'
   File "django/core/paginator.py", line 79, in count
 return self.object_list.count()
 }}}

 Code which leads to the error
 {{{
 # Base Query Construct
 auth_query =
 UserAuth.objects.filter(user_id=OuterRef('user_id')).order_by(
 '-received_at')[:1]
 base_employees = (
 
base_employees.annotate(auth_received_at=Subquery(auth_query.values('received_at')),
 auth_response=Subquery(auth_query.values('response'

  # Q object building
  q  = Q()
  if IS_AUTH_REJECTED in auth_status:
 q |= Q(auth_response__REJECTED='N')

 base_employees.filter(q)
 }}}

 Workaround
 {{{
# base query construct
 auth_query = 

Re: [Django] #30746: Add Feature-Policy header support

2019-09-10 Thread Django
#30746: Add Feature-Policy header support
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Someday/Maybe
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

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


Comment:

 Replying to [comment:2 Adam (Chainz) Johnson]:
 > I'm -1 on adding Feature-Policy to Django... right now. It's far too
 experimental and evolving much faster than Django's release cycle.
 >
 > ...
 >
 > I think it'll be settled in a year or so and then it'll be worth adding
 to Django core.

 Replying to [comment:3 felixxm]:
 > I agree with Adam, it's too early. This header is still under
 development and it isn't wide-supported.

 I understand and agree. I was hoping to look into supporting `Content-
 Security-Policy` too for 3.1 and this is somewhat less complex, but also
 similar in syntax, so exploring this will help. Thus I will probably
 progress the [https://github.com/django/django/pull/11735 PR] as far as
 possible for now and then leave it on ice. We'll have a better idea come
 April~May 2020.

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

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


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

2019-09-10 Thread Django
#23714: `date` filter raises an exception for naive datetimes during DST change
-+
 Reporter:  Markus Bertheau  |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by felixxm):

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


Comment:

 It was fixed by 1014ba026e879e56e0f265a8d9f54e6f39843348 and
 c7a6996df7e77bc3b9c5e581e67d766627ebabec.

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

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


Re: [Django] #15063: multi_db flag on TestCase causes invalid error reporting when loading fixtures. (was: multi_db flag on TestCase causes invalid error reporting when loading fixtures)

2019-09-10 Thread Django
#15063: multi_db flag on TestCase causes invalid error reporting when loading
fixtures.
---+-
 Reporter:  David Cramer   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.2
 Severity:  Normal |   Resolution:  duplicate
 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 felixxm):

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


Comment:

 As far as I'm concerned this is a duplicate of #16713.

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

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


Re: [Django] #24680: In testing, warnings appear when loading database-specific fixtures

2019-09-10 Thread Django
#24680: In testing, warnings appear when loading database-specific fixtures
-+-
 Reporter:  Zhongyuan|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  testing, fixtures,   | Triage Stage:  Accepted
  database-specific, warning |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Duplicate of #16713.

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

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


Re: [Django] #16713: Fixture loading for tests ignore database specific names. (was: Fixture loading for tests ignore database specific names)

2019-09-10 Thread Django
#16713: Fixture loading for tests ignore database specific names.
---+
 Reporter:  brent@…|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords:  fixtures, multidb  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by felixxm):

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


Comment:

 `multi_db` will be removed in Django 3.1 (see
 b61ea56789a5825bd2961a335cb82f65e09f1614). Despite the fact that behavior
 described in this ticket is still valid when using
 
[https://docs.djangoproject.com/en/2.2/topics/testing/tools/#django.test.TestCase.databases
 TestCase.databases] it is also documented in
 
[https://docs.djangoproject.com/en/2.2/topics/testing/tools/#django.test.TransactionTestCase.databases
 TransactionTestCase.databases] and
 
[https://docs.djangoproject.com/en/2.2/topics/testing/tools/#django.test.TransactionTestCase.fixtures
 TransactionTestCase.fixtures], e.g.:

  By default, fixtures are only loaded into the default database. If you
 are using multiple databases and set TransactionTestCase.databases,
 fixtures will be loaded into **all specified databases**.

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

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


Re: [Django] #29513: Make TransactionTestCase.multi_db documentation more discoverable. (was: Make TransactionTestCase.multi_db documentation more discoverable)

2019-09-10 Thread Django
#29513: Make TransactionTestCase.multi_db documentation more discoverable.
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 felixxm):

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


Comment:

 We can treat this ticket as fixed, since `multi_db` will be removed in
 Django 3.1 (see b61ea56789a5825bd2961a335cb82f65e09f1614).

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

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


Re: [Django] #18929: CachedFilesMixin is not compatible with S3BotoStorage. (was: CachedFilesMixin is not compatible with S3BotoStorage)

2019-09-10 Thread Django
#18929: CachedFilesMixin is not compatible with S3BotoStorage.
-+
 Reporter:  idanzalz@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 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 felixxm):

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


Comment:

 This issue is not valid anymore because `CachedFilesMixin` and
 `CachedStaticFilesStorage` will be removed in Django 3.1 (see
 f1894bae3071da4ee577fc40ae61491f3e03d82c).

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

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


Re: [Django] #19528: CachedFilesMixin does not rewrite rules for css selector with path

2019-09-10 Thread Django
#19528: CachedFilesMixin does not rewrite rules for css selector with path
-+-
 Reporter:  mike@…   |Owner:  Jason
 |  Novinger
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CachedFilesMixin | Triage Stage:  Accepted
  staticfiles djbday |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 This issue is not valid anymore because `CachedFilesMixin` and
 `CachedStaticFilesStorage` will be removed in Django 3.1 (see
 f1894bae3071da4ee577fc40ae61491f3e03d82c).

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

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


Re: [Django] #29817: Deprecate FILE_CHARSET setting

2019-09-10 Thread Django
#29817: Deprecate FILE_CHARSET setting
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  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:  0 |UI/UX:  0
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"3d716467a9f046c7af4fb62c13e6b975c06c135f" 3d716467]:
 {{{
 #!CommitTicketReference repository=""
 revision="3d716467a9f046c7af4fb62c13e6b975c06c135f"
 Refs #29817 -- Removed settings.FILE_CHARSET per deprecation timeline.
 }}}

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

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


Re: [Django] #28478: Make DiscoverRunner skip creating a test database if not needed

2019-09-10 Thread Django
#28478: Make DiscoverRunner skip creating a test database if not needed
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Testing framework |  Version:  master
 Severity:  Release blocker   |   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"b61ea56789a5825bd2961a335cb82f65e09f1614" b61ea567]:
 {{{
 #!CommitTicketReference repository=""
 revision="b61ea56789a5825bd2961a335cb82f65e09f1614"
 Refs #28478 -- Removed support for TestCase's allow_database_queries and
 multi_db per deprecation timeline.
 }}}

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

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


Re: [Django] #14357: Prevent inappropriate order-based grouping on values+annotate queries

2019-09-10 Thread Django
#14357: Prevent inappropriate order-based grouping on values+annotate queries
-+-
 Reporter:  Martin Chase |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  3.1  | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"0ddb4ebf7bfcc4730c80a772dd146a49ef6895f6" 0ddb4ebf]:
 {{{
 #!CommitTicketReference repository=""
 revision="0ddb4ebf7bfcc4730c80a772dd146a49ef6895f6"
 Refs #14357 -- Made Meta.ordering not affect GROUP BY queries.

 Per deprecation timeline.
 }}}

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

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


Re: [Django] #29546: deprecate timezone.FixedOffset in favor of datetime.timezone

2019-09-10 Thread Django
#29546: deprecate timezone.FixedOffset in favor of datetime.timezone
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  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:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"cb2be9d5d57c34a70f0c549b780183f8c73aec4b" cb2be9d5]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb2be9d5d57c34a70f0c549b780183f8c73aec4b"
 Refs #29546 -- Removed django.utils.timezone.FixedOffset per deprecation
 timeline.
 }}}

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

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


Re: [Django] #28606: Deprecate CachedStaticFilesStorage

2019-09-10 Thread Django
#28606: Deprecate CachedStaticFilesStorage
-+-
 Reporter:  Ed Morley|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.staticfiles  |  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 Mariusz Felisiak ):

 In [changeset:"f1894bae3071da4ee577fc40ae61491f3e03d82c" f1894bae]:
 {{{
 #!CommitTicketReference repository=""
 revision="f1894bae3071da4ee577fc40ae61491f3e03d82c"
 Refs #28606 -- Removed CachedStaticFilesStorage per deprecation timeline.
 }}}

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

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


Re: [Django] #29703: Deprecate undocumented QuerySetPaginator

2019-09-10 Thread Django
#29703: Deprecate undocumented QuerySetPaginator
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  paginator,   | Triage Stage:  Ready for
  queryset, deprecation  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"81993b47eaac3cea1ebbc610a3a6b824f5195523" 81993b47]:
 {{{
 #!CommitTicketReference repository=""
 revision="81993b47eaac3cea1ebbc610a3a6b824f5195523"
 Refs #29703 -- Removed QuerySetPaginator alias per deprecation timeline.
 }}}

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

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


Re: [Django] #30037: RemoteUserBackend should pass request into configure_user()

2019-09-10 Thread Django
#30037: RemoteUserBackend should pass request into configure_user()
-+-
 Reporter:  Joshua Cannon|Owner:  Joshua
 |  Cannon
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  RemoteUserBackend| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d17be88afd5f5e1059491e10408ba239e2e99fe2" d17be88a]:
 {{{
 #!CommitTicketReference repository=""
 revision="d17be88afd5f5e1059491e10408ba239e2e99fe2"
 Refs #30037 -- Required the RemoteUserBackend.configure_user() to have
 request as the first positional argument.

 Per deprecation timeline.
 }}}

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

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


Re: [Django] #29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField

2019-09-10 Thread Django
#29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField
-+-
 Reporter:  Simon Charette   |Owner:  Stefano
 |  Chiodino
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  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:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"b47bb4c4a74f926111bdad4a6daae14ceed6f2dd" b47bb4c4]:
 {{{
 #!CommitTicketReference repository=""
 revision="b47bb4c4a74f926111bdad4a6daae14ceed6f2dd"
 Refs #29598 -- Removed FloatRangeField per deprecation timeline.
 }}}

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

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


Re: [Django] #30758: DateTimeRangeField with default crashes in django admin (object has no attribute 'strip').

2019-09-10 Thread Django
#30758: DateTimeRangeField with default crashes in django admin (object has no
attribute 'strip').
-+-
 Reporter:  yeppus   |Owner:  Nasir
 |  Hussain
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  DateTimeRangeField   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yeppus):

 Hi All, I can confirm that this patch works on our product staging
 environment where we previously encounter the issue as well.

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

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


Re: [Django] #30754: Partial indexes break future migrations in sqlite

2019-09-10 Thread Django
#30754: Partial indexes break future migrations in sqlite
-+-
 Reporter:  Pēteris Caune|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  2.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  sqlite   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"964dd4f4f208722d8993a35c1ff047d353cea1ea" 964dd4f]:
 {{{
 #!CommitTicketReference repository=""
 revision="964dd4f4f208722d8993a35c1ff047d353cea1ea"
 [2.2.x] Fixed #30754 -- Prevented inclusion of aliases in partial index
 conditions.

 SQLite doesn't repoint table aliases in partial index conditions on table
 rename which breaks the documented table alteration procedure.

 Thanks Pēteris Caune for the report.

 Backport of 34decdebf157b6f05836009cc1967f74ee541fdf 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.73194808b8c7a7519623ff964585ce54%40djangoproject.com.


Re: [Django] #30754: Partial indexes break future migrations in sqlite

2019-09-10 Thread Django
#30754: Partial indexes break future migrations in sqlite
-+-
 Reporter:  Pēteris Caune|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  2.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  sqlite   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"34decdebf157b6f05836009cc1967f74ee541fdf" 34decdeb]:
 {{{
 #!CommitTicketReference repository=""
 revision="34decdebf157b6f05836009cc1967f74ee541fdf"
 Fixed #30754 -- Prevented inclusion of aliases in partial index
 conditions.

 SQLite doesn't repoint table aliases in partial index conditions on table
 rename which breaks the documented table alteration procedure.

 Thanks Pēteris Caune for the report.
 }}}

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

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


Re: [Django] #30768: django.forms.boundfield.as_widget() causes an exception when used. (was: django.forms.boundfield.as_widget method hasn't been updated, and causes an exception when used!)

2019-09-10 Thread Django
#30768: django.forms.boundfield.as_widget() causes an exception when used.
-+-
 Reporter:  Mark |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  boundfiled renderer  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 `renderer` argument wasn't removed in Django 2.1, we only removed only
 support for `Widget.render()` methods **without** this argument. I don't
 see any issue in this code.

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

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