Re: [Django] #26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')

[Django]

#26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')
---+--
 Reporter:  timgraham  |Owner:  sir-sigurd
 Type:  Bug|   Status:  assigned
Component:  GIS|  Version:  1.9
 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 sir-sigurd):

 * owner:  nobody => sir-sigurd
 * status:  new => assigned


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

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

Re: [Django] #26758: Annotate appears broken with Postgres in recent releases

[Django]

#26758: Annotate appears broken with Postgres in recent releases
-+-
 Reporter:  darkpixel|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 FWIW I also tried to reproduce [https://github.com/charettes/django-
 ticketing/commit/78ed6a345e760ea46434690e9385ae4d26fc2810 against
 PostgreSQL 9.3 with no success] and managed to reproduce against 9.0.

 The simple fact that the error messages mentions `"company"."owner_id"`
 must be in the `GROUP BY` clause when `"company"."company_recid"` is
 already part of it is a strong indicator that's the underlying issue here.

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

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

[Django] #26760: django_migrations table is never cleaned.

[Django]

#26760: django_migrations table is never cleaned.
-+-
 Reporter:  jarekwg  |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |
Component:  Migrations   |Version:  master
 Severity:  Normal   |   Keywords:  django_migrations
 |  squash migrations
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Django adds a `django_migrations` table to the database which list all of
 the migrations that have been applied (and when).

 With the introduction of `squashmigrations`, it is possible for this table
 to contain a lot of old migrations that no longer exist. This can be
 problematic if naming duplication occurs:

 Example:
 I have an app with:
 {{{
 my_app/migrations/
 0001_initial.py
 0002_blah.py
 0003_blah.py
 }}}
 I squash and delete replaced migrations:
 {{{
 my_app/migrations/
 0001_initial_squashed_0003_blah.py
 }}}
 I create a new migration and use poor naming:
 {{{
 my_app/migrations/
 0001_initial_squashed_0003_blah.py
 0002_blah.py
 }}}
 My new migration never runs because the `django_migrations` table thinks
 it has already been applied.

 I propose truncation of the `django_migrations` table so that it includes
 only migrations that actually exist in the django project. This could be
 done automatically (when executor runs, or inside the `migrate` mcommand).
 Or have its own mcommand that requires it be run manually. I prefer the
 automatic approach though.

 Pros:
 - Cleans up old data that just bloats the database.
 - Protects users from the trap mentioned above where a new migration is
 created with the same name as one that was applied in the past.
 Cons:
 - A loss of historical information.


 Note:
 Need to be careful with implementation to avoid a possible new trap if a
 user squashes migrations and then proceeds to delete the replaced
 migrations before running the squashed migrations on their database ->
 django will think squashed migrations haven't been applied and will
 attempt to reapply them. This can be remedied simply by not removing
 migrations mentioned in `replaces` lists of other migrations from
 `django_migrations` (ie. we'd consider replaced migrations as still
 existing, even if their actual files have already been removed).

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

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

Re: [Django] #26759: TLSv1-only SMTP servers not supported under Django 1.9.7 / Python 3.4.4 (win32) / OpenSSL 1.0.2d

[Django]

#26759: TLSv1-only SMTP servers not supported under Django 1.9.7 / Python 3.4.4
(win32) / OpenSSL 1.0.2d
-+-
 Reporter:  RudolfCardinal   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Mail)  |Version:  1.9
 Severity:  Normal   | Resolution:
 Keywords:  email SMTP TLS SSL SSLEOFError   |   Triage Stage:
  TLSv1  |  Unreviewed
Has patch:  1|  Easy pickings:  1
UI/UX:  0|
-+-
Changes (by RudolfCardinal):

 * Attachment "smtp_email_backend_tls1.py" added.

 New e-mail backend forcing TLSv1

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

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

[Django] #26759: TLSv1-only SMTP servers not supported under Django 1.9.7 / Python 3.4.4 (win32) / OpenSSL 1.0.2d

[Django]

#26759: TLSv1-only SMTP servers not supported under Django 1.9.7 / Python 3.4.4
(win32) / OpenSSL 1.0.2d
-+-
 Reporter:   |  Owner:  nobody
  RudolfCardinal |
 Type:  Bug  | Status:  new
Component:  Core |Version:  1.9
  (Mail) |   Keywords:  email SMTP TLS SSL SSLEOFError
 Severity:  Normal   |  TLSv1
 Triage Stage:   |  Has patch:  1
  Unreviewed |
Easy pickings:  1|  UI/UX:  0
-+-
 Connecting to a Microsoft (E)SMTP mail server with the Django default
 e-mail backend (django.core.mail.backends.smtp.EmailBackend) and TLS can
 fail with the following error:

 ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:600)

 This appears to occur with some (more recent) versions of Python's
 smtplib, ssl (and underlying OpenSSL) with servers that only support
 TLSv1. There is no option in Django to force the TLS protocol version that
 I can see.

 The simplest illustration of failure is with:

 import smtplib
 s = smtplib.SMTP(host, port)  # port typically 587
 s.ehlo()
 s.starttls()  # fails with ssl.SSLEOFError as above

 which succeeds (with such servers) with a small modification to force
 TLSv1:

 import smtplib
 import ssl
 s = smtplib.SMTP(host, port)
 c = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
 s.ehlo()
 s.starttls(context=c)  # works

 There is a suggestion of a dependence on exact OpenSSL version in the docs
 at https://docs.python.org/3.4/library/ssl.html ("Which connections
 succeed will vary depending on the version of OpenSSL...").

 Therefore, a proposed framework alternative backend is one that enforces
 TLSv1 when required, e.g. as attached. This can be selected with Django's
 EMAIL_BACKEND setting, so can be added by users, but I'd have thought that
 continuing to support such servers is important for the Django core
 project as well.

 Test software: Django 1.9.7; Python 3.4.4 (win32) using OpenSSL 1.0.2d
 (from ssl.OPENSSL_VERSION). Test server: Microsoft SMTP Server id 8.3.83.0
 (from resulting e-mail headers).

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

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

Re: [Django] #26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')

[Django]

#26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')
---+
 Reporter:  timgraham  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.9
 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 timgraham):

 Not sure I understand. For the union test,
 `City.objects.get(name='Dallas').point.srid` gives 4326 which is the same
 as the `Point` in the test. If you are able, feel free to send a patch,
 Sergey.

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

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

[Django]

#26401: Allow auth machinery to be used without installing auth app
--+
 Reporter:  satchamo  |Owner:  andkon
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by satchamo):

 Another patch attempt: https://github.com/django/django/pull/6779

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

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

Re: [Django] #26758: Annotate appears broken with Postgres in recent releases

[Django]

#26758: Annotate appears broken with Postgres in recent releases
-+-
 Reporter:  darkpixel|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


Comment:

 It looks like you are using a version of PostgreSQL that is not supported
 by the version of Django you are using.

 Django 1.9 dropped support for PostgreSQL 9.0 and takes advantage of a
 feature in PostgreSQL 9.1 that allows grouping by only the selected tables
 primary keys.

 Please re-open if you're experiencing the same issue on PostgreSQL 9.1

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

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

[Django] #26758: Annotate appears broken with Postgres in recent releases

[Django]

#26758: Annotate appears broken with Postgres in recent releases
--+
 Reporter:  darkpixel |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Brief Summary

 The brief overview is:
 * I have a second postgres database that I am reading data from.
 * It's data from a closed-source ticket system we are migrating away from.
 * I ran a manage.py inspectdb on it about 2 years ago and have been
 pulling stats from the data since then without trouble
 * The database structure looks *ugly* thanks to the closed-source
 designers, don't blame me... ;)
 * Upgrading from 1.8.4 to 1.9.2 broke one of the queries I was running

 Query:
 {{{
 
Company.objects.all().annotate(ticketcount=Count('srservice')).exclude(ticketcount=0).order_by('-ticketcount')
 }}}

 Error:
 {{{
 >>>
 
Company.objects.all().annotate(ticketcount=Count('srservice')).exclude(ticketcount=0).order_by('-ticketcount')
 Traceback (most recent call last):
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
 psycopg2.ProgrammingError: column "company.owner_id" must appear in the
 GROUP BY clause or be used in an aggregate function
 LINE 1: SELECT "company"."owner_id", "company"."company_recid", "com...
^


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/home/aaron/.pyenv/versions/3.5.1/lib/python3.5/code.py", line 91,
 in runcode
 exec(code, self.locals)
   File "", line 1, in 
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/models/query.py", line 234, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/models/query.py", line 258, in __iter__
 self._fetch_all()
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/models/query.py", line 1074, in _fetch_all
 self._result_cache = list(self.iterator())
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/models/query.py", line 52, in __iter__
 results = compiler.execute_sql()
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/models/sql/compiler.py", line 848, in execute_sql
 cursor.execute(sql, params)
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/utils.py", line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/utils/six.py", line 685, in reraise
 raise value.with_traceback(tb)
   File "/home/aaron/.virtualenvs/-redacted-/lib/python3.5/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: column "company.owner_id" must appear in
 the GROUP BY clause or be used in an aggregate function
 LINE 1: SELECT "company"."owner_id", "company"."company_recid", "com...
^

 >>>
 }}}

 Generated SQL from the queryset:
 {{{
 SELECT "company"."owner_id", "company"."company_recid",
 "company"."company_id", "company"."company_name", "company"."phonenbr",
 "company"."phonenbr_fax", "company"."website_url", "company"."keywords",
 "company"."account_nbr", "company"."currency_id",
 "company"."time_zone_recid", "company"."sic_code_id",
 "company"."remit_to_recid", "company"."exchange_flag",
 "company"."last_update", "company"."updated_by",
 "company"."company_type_recid", "company"."company_status_recid",
 "company"."tax_code_recid", "company"."currency_recid",
 "company"."owner_level_recid", "company"."billable_flag",
 "company"."userfield_1", "company"."userfield_2", "company"."userfield_3",
 "company"."userfield_4", "company"."userfield_5", "company"."userfield_6",
 "company"."userfield_7", "company"."userfield_8", "company"."userfield_9",
 "company"."userfield_10", "company"."delete_flag",
 "company"."date_deleted", "company"."deleted_by",
 "company"."market_recid", "company"."br_option", "company"."lead_flag",
 "company"."lead_source", 

Re: [Django] #26756: Changing of model's verbose_name does not change the names of the model's permissions

[Django]

#26756: Changing of model's verbose_name does not change the names of the 
model's
permissions
-+-
 Reporter:  dburakov |Owner:  black3r
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
  verbose_name migrate   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by black3r):

 * has_patch:  0 => 1


Comment:

 I've tried to implement this in the management command, that handles
 creating non-existing permissions after migrating an app.

 Here's a PR https://github.com/django/django/pull/6778

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

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

Re: [Django] #26756: Changing of model's verbose_name does not change the names of the model's permissions

[Django]

#26756: Changing of model's verbose_name does not change the names of the 
model's
permissions
-+-
 Reporter:  dburakov |Owner:  black3r
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
  verbose_name migrate   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by black3r):

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


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

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

Re: [Django] #26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')

[Django]

#26657: MySQL 5.7 GIS test failures: InterfaceError: (-1, 'error totally whack')
---+
 Reporter:  timgraham  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.9
 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 sir-sigurd):

 SRID of geometry from the table is 0, SRID of the given point is 4326,
 [https://dev.mysql.com/doc/refman/5.7/en/spatial-function-argument-
 handling.html MySQL requires arguments to have the same SRID].

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

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

Re: [Django] #26748: Ease customizing the JSONField widget

[Django]

#26748: Ease customizing the JSONField widget
-+-
 Reporter:  meshy|Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by meshy):

 Great! Thanks for the link `:)`

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

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

Re: [Django] #26753: Make GDAL a hard dependency

[Django]

#26753: Make GDAL a hard dependency
--+
 Reporter:  claudep   |Owner:  claudep
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  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 claudep):

 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #26757: sqlsequencereset Doesn't do auth_* django_* tables

[Django]

#26757: sqlsequencereset Doesn't do auth_* django_* tables
-+-
 Reporter:  VackarAfzal  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Sequences, Oracle,   | Triage Stage:
  IDs|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by VackarAfzal):

 Thanks :-)

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

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

Re: [Django] #26757: sqlsequencereset Doesn't do auth_* django_* tables

[Django]

#26757: sqlsequencereset Doesn't do auth_* django_* tables
-+-
 Reporter:  VackarAfzal  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Sequences, Oracle,   | Triage Stage:
  IDs|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by bmispelon):

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


Comment:

 Thanks for checking.

 I've closed the bug but for reference, you don't need any special
 permissions to close a ticket here.

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

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

Re: [Django] #26757: sqlsequencereset Doesn't do auth_* django_* tables

[Django]

#26757: sqlsequencereset Doesn't do auth_* django_* tables
-+-
 Reporter:  VackarAfzal  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  Sequences, Oracle,   | Triage Stage:
  IDs|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by VackarAfzal):

 Apologies, just check with the devs and you are right, forgot to include
 'auth' as one of the apps.
 Please feel free to close this off now.

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

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

Re: [Django] #26757: sqlsequencereset Doesn't do auth_* django_* tables

[Django]

#26757: sqlsequencereset Doesn't do auth_* django_* tables
-+-
 Reporter:  VackarAfzal  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  Sequences, Oracle,   | Triage Stage:
  IDs|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by bmispelon):

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


Comment:

 Hi,

 The documentation for `sqlsequencereset` [1] indicates that you have to
 give it at least one app name (like `auth` or `contenttypes`, ...).

 When I try `python manage.py sqlsequencereset auth` on my local version, I
 get the expected output (using postgresql).

 Could you show us the exact command you're running and its output? Also,
 which database are you using?


 Thanks.

 [1] https://docs.djangoproject.com/en/1.9/ref/django-
 admin/#sqlsequencereset

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

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

Re: [Django] #26753: Make GDAL a hard dependency

[Django]

#26753: Make GDAL a hard dependency
--+
 Reporter:  claudep   |Owner:  claudep
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  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 claudep):

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


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

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

[Django] #26757: sqlsequencereset Doesn't do auth_* django_* tables

[Django]

#26757: sqlsequencereset Doesn't do auth_* django_* tables
---+
 Reporter:  VackarAfzal|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.auth   |Version:  1.9
 Severity:  Normal |   Keywords:  Sequences, Oracle, IDs
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 I've ran manage.py sqlsequencereset and noticed it doesn't print the SQL
 for tables starting in auth_* or django_*

 Is this expected behaviour, or is there a bug somewhere that isn't
 bringing these models forward?

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

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

Re: [Django] #26745: Add the ability to customize user creation in the createsuperuser command

[Django]

#26745: Add the ability to customize user creation in the createsuperuser 
command
--+--
 Reporter:  Lyra2108  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by timgraham):

 Oh, I guess you're using permissions in a somewhat unusual way since
 `ModelBackend` defines superusers as having all permissions.

 Is the likelihood of the `post_save` signal failing really so large that
 you must perform actions in the same transaction? See also #24228 which
 questions whether or not `​pre_save` and `​post_save` should be in the
 transaction.

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

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

Re: [Django] #26644: SuspiciousFileOperation when creating a File from a NamedTemporaryFile

[Django]

#26644: SuspiciousFileOperation when creating a File from a NamedTemporaryFile
-+-
 Reporter:  hobarrera|Owner:  hobarrera
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.10
  uploads/storage|
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  File,| Triage Stage:  Accepted
  SuspiciousFileOperation,   |
  NamedTemporaryFile, regression |
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:"c37f9253a6cb3b6e7d58607c058de1f3bc9f8d2b" c37f9253]:
 {{{
 #!CommitTicketReference repository=""
 revision="c37f9253a6cb3b6e7d58607c058de1f3bc9f8d2b"
 [1.10.x] Fixed #26644 -- Allowed wrapping NamedTemporaryFile with File.

 914c72be2abb1c6dd860cb9279beaa66409ae1b2 introduced a regression that
 causes saving a NamedTemporaryFile in a FileField to raise a
 SuspiciousFileOperation. To remedy this, if a File has an absolute
 path as a filename, use only the basename as the filename.

 Backport of 1b407050dd53e56686fdd3e168f8cac4f9be8306 from master
 }}}

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

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

Re: [Django] #26755: test_middleware_classes_headers fails when django files aren't writable (was: test_middleware_classes_headers is failing when django files are not writable)

[Django]

#26755: test_middleware_classes_headers fails when django files aren't writable
--+
 Reporter:  rhertzog  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (Other)
 * needs_tests:   => 0
 * easy:  1 => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #26644: SuspiciousFileOperation when creating a File from a NamedTemporaryFile

[Django]

#26644: SuspiciousFileOperation when creating a File from a NamedTemporaryFile
-+-
 Reporter:  hobarrera|Owner:  hobarrera
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.10
  uploads/storage|
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  File,| Triage Stage:  Accepted
  SuspiciousFileOperation,   |
  NamedTemporaryFile, regression |
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:"1b407050dd53e56686fdd3e168f8cac4f9be8306" 1b40705]:
 {{{
 #!CommitTicketReference repository=""
 revision="1b407050dd53e56686fdd3e168f8cac4f9be8306"
 Fixed #26644 -- Allowed wrapping NamedTemporaryFile with File.

 914c72be2abb1c6dd860cb9279beaa66409ae1b2 introduced a regression that
 causes saving a NamedTemporaryFile in a FileField to raise a
 SuspiciousFileOperation. To remedy this, if a File has an absolute
 path as a filename, use only the basename as the filename.
 }}}

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

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

Re: [Django] #26171: ForeignKey with db_constraint=False doesn't generate an index on MySQL

[Django]

#26171: ForeignKey with db_constraint=False doesn't generate an index on MySQL
+---
 Reporter:  jeroenp |Owner:  aaronelliotross
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.9
 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 aaronelliotross):

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


Comment:

 This code sets db_index = False:

 
https://github.com/django/django/blob/master/django/db/backends/mysql/schema.py#L61-L63

 I don't think the db/backends/mysql/schema.py code should be modifying the
 attributes of a Field. I agree that the check needs to take db_constraint
 into consideration too.

 Here's a pull request:

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

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

Re: [Django] #26756: Changing of model's verbose_name does not change the names of the model's permissions

[Django]

#26756: Changing of model's verbose_name does not change the names of the 
model's
permissions
-+-
 Reporter:  dburakov |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
  verbose_name migrate   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * version:  1.9 => master
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #26754: Document django.template.context_processors.tz

[Django]

#26754: Document django.template.context_processors.tz
-+-
 Reporter:  scop |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  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 Baptiste Mispelon ):

 In [changeset:"61bcf0413244375a74d9c2aae9190d9b057f9635" 61bcf04]:
 {{{
 #!CommitTicketReference repository=""
 revision="61bcf0413244375a74d9c2aae9190d9b057f9635"
 [1.10.x] Fixed #26754 -- Documented django.template.context_processors.tz

 Backport of 7003174fec188bd5a21e3d62bd5e13e80f6f329c from master
 }}}

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

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

Re: [Django] #26754: Document django.template.context_processors.tz

[Django]

#26754: Document django.template.context_processors.tz
-+-
 Reporter:  scop |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  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 Baptiste Mispelon ):

 In [changeset:"b789d81c957b437f43a3329bfef45312232bf80c" b789d81c]:
 {{{
 #!CommitTicketReference repository=""
 revision="b789d81c957b437f43a3329bfef45312232bf80c"
 [1.9.x] Fixed #26754 -- Documented django.template.context_processors.tz

 Backport of 7003174fec188bd5a21e3d62bd5e13e80f6f329c from master
 }}}

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

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

Re: [Django] #26754: Document django.template.context_processors.tz

[Django]

#26754: Document django.template.context_processors.tz
-+-
 Reporter:  scop |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  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 Baptiste Mispelon ):

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


Comment:

 In [changeset:"7003174fec188bd5a21e3d62bd5e13e80f6f329c" 7003174f]:
 {{{
 #!CommitTicketReference repository=""
 revision="7003174fec188bd5a21e3d62bd5e13e80f6f329c"
 Fixed #26754 -- Documented django.template.context_processors.tz
 }}}

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

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

Re: [Django] #26756: Changing of model's verbose_name does not change the names of the model's permissions

[Django]

#26756: Changing of model's verbose_name does not change the names of the 
model's
permissions
-+-
 Reporter:  dburakov |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  permissions  | Triage Stage:
  verbose_name migrate   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by dburakov):

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


Old description:

> I've found that changing the "verbose_name" of the Meta class of a model
> and than running migrations does not change the names of the model's
> permissions.
>
> Steps to reproduce:
>
> 1. Create a new model
>
> {{{
> class AwesomeModel(models.Model):
> class Meta:
> verbose_name = "My awesome model"
> }}}
>

> 2. Run "makemigrations" and than "migrate"
> 3. Look at the generated permissions
>

> {{{
> select * from auth_permission;
>  id  |  name  | content_type_id |
> codename
> -++-+--
>1 | Can add my awesome model   |   2 |
> add_awesomemodel
>2 | Can change my awesome model|   2 |
> change_awesomemodel
>3 | Can delete my awesome model|   2 |
> delete_awesomemodel
> }}}
>

> 4. Change the "verbose_name" of the Meta class of the model
>

> {{{
> class AwesomeModel(models.Model):
> class Meta:
> verbose_name = "My really awesome model"
> }}}
>

> 5. Run "makemigrations" and than "migrate" again
> 6. Look at the generated permissions agaun
>
> {{{
>
> select * from auth_permission;
>  id  |  name  | content_type_id |
> codename
> -++-+--
>1 | Can add my awesome model   |   2 |
> add_awesomemodel
>2 | Can change my awesome model|   2 |
> change_awesomemodel
>3 | Can delete my awesome model|   2 |
> delete_awesomemodel
> }}}
>

> As you can see the names of the model's permissions are not changed.
> But! If now you drop the database and apply all the migrations to the
> empty database - the permissions will have correct names
>

> {{{
> select * from auth_permission;
>  id  |  name  | content_type_id |
> codename
> -++-+--
>1 | Can add my really awesome model|   2 |
> add_awesomemodel
>2 | Can change really my awesome model |   2 |
> change_awesomemodel
>3 | Can delete really my awesome model |   2 |
> delete_awesomemodel
> }}}

New description:

 I've found that changing the "verbose_name" of the Meta class of a model
 and than running migrations does not change the names of the model's
 permissions.

 Steps to reproduce:

 1. Create a new model

 {{{
 class AwesomeModel(models.Model):
 class Meta:
 verbose_name = "My awesome model"
 }}}


 2. Run "makemigrations" and than "migrate"
 3. Look at the generated permissions


 {{{
 select * from auth_permission;
  id  |  name  | content_type_id |
 codename
 
-++-+--
1 | Can add my awesome model   |   2 |
 add_awesomemodel
2 | Can change my awesome model|   2 |
 change_awesomemodel
3 | Can delete my awesome model|   2 |
 delete_awesomemodel
 }}}


 4. Change the "verbose_name" of the Meta class of the model


 {{{
 class AwesomeModel(models.Model):
 class Meta:
 verbose_name = "My really awesome model"
 }}}


 5. Run "makemigrations" and than "migrate" again
 6. Look at the generated permissions agaun

 {{{

 select * from auth_permission;
  id  |  name  | content_type_id |
 codename
 
-++-+--
1 | Can add my awesome model   |   2 |
 add_awesomemodel
2 | Can change my awesome model|   2 |
 change_awesomemodel
3 | Can delete my awesome model|   2 |
 

[Django] #26756: Changing of model's verbose_name does not change the names of the model's permissions

[Django]

#26756: Changing of model's verbose_name does not change the names of the 
model's
permissions
+--
 Reporter:  dburakov|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.9
 Severity:  Normal  |   Keywords:  permissions verbose_name migrate
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 I've found that changing the "verbose_name" of the Meta class of a model
 and than running migrations does not change the names of the model's
 permissions.

 Steps to reproduce:

 1. Create a new model

 {{{
 class AwesomeModel(models.Model):
 class Meta:
 verbose_name = "My awesome model"
 }}}


 2. Run "makemigrations" and than "migrate"
 3. Look at the generated permissions


 {{{
 select * from auth_permission;
  id  |  name  | content_type_id |
 codename
 
-++-+--
1 | Can add my awesome model   |   2 |
 add_awesomemodel
2 | Can change my awesome model|   2 |
 change_awesomemodel
3 | Can delete my awesome model|   2 |
 delete_awesomemodel
 }}}


 4. Change the "verbose_name" of the Meta class of the model


 {{{
 class AwesomeModel(models.Model):
 class Meta:
 verbose_name = "My really awesome model"
 }}}


 5. Run "makemigrations" and than "migrate" again
 6. Look at the generated permissions agaun

 {{{

 select * from auth_permission;
  id  |  name  | content_type_id |
 codename
 
-++-+--
1 | Can add my awesome model   |   2 |
 add_awesomemodel
2 | Can change my awesome model|   2 |
 change_awesomemodel
3 | Can delete my awesome model|   2 |
 delete_awesomemodel
 }}}


 As you can see the names of the model's permissions are not changed.
 But! If now you drop the database and apply all the migrations to the
 empty database - the permissions will have correct names


 {{{
 select * from auth_permission;
  id  |  name  | content_type_id |
 codename
 
-++-+--
1 | Can add my really awesome model|   2 |
 add_awesomemodel
2 | Can change really my awesome model |   2 |
 change_awesomemodel
3 | Can delete really my awesome model |   2 |
 delete_awesomemodel
 }}}

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

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

[Django] #26755: test_middleware_classes_headers is failing when django files are not writable

[Django]

#26755: test_middleware_classes_headers is failing when django files are not
writable
---+
 Reporter:  rhertzog   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 commit abc0777b63057e2ff97eee2ff184356051e14c47 broke the test suite
 Debian runs against the installed package:
 https://ci.debian.net/data/packages/unstable/amd64/p/python-
 django/20160610_144236.autopkgtest.log.gz

 The problem is that the setUp() method tries to create a file in the
 django/conf/project_template/project_name/ directory but that directory is
 owned by root:root in the installed Debian package.
 The test suite should not assume that it can write to the tree hosting the
 django code.

 A possible fix would be to use some import magic:
 {{{
 with open(template_settings_py) as f:
 m = imp.load_module('settings', f, template_settings_py, ('', '',
 imp.PY_SOURCE))
 }}}
 (I can't figure out the equivalent with the importlib module)

 Or to copy the file to a temporary directory that you add to sys.path.

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

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

Re: [Django] #26754: Document django.template.context_processors.tz

[Django]

#26754: Document django.template.context_processors.tz
-+-
 Reporter:  scop |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks great, thanks!

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

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

Re: [Django] #26753: Make GDAL a hard dependency

[Django]

#26753: Make GDAL a hard dependency
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 > I think it's worth continuing to allow running the Django test suite
 without GDAL installed

 Absolutely. We might replace or complement the `HAS_GEOS`/`HAS_GDAL` flags
 by some `HAS_GEOLIBS` flag.

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

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