Re: [Django] #25217: cleanup - M2M shouldn't take a 'default' kwarg

[Django]

#25217: cleanup - M2M shouldn't take a 'default' kwarg
-+-
 Reporter:  mjlock   |Owner:  mjlock
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mjlock):

 submitted pull request for this ticket:
 https://github.com/django/django/pull/5098

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

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

Re: [Django] #25218: python_2_unicode_compatible causes infinite recursion when super().__str__() is called

[Django]

#25218: python_2_unicode_compatible causes infinite recursion when
super().__str__() is called
---+
 Reporter:  jscn   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Utilities  |Version:  1.8
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by jscn):

 * Attachment "recursion.py" added.


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

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

[Django] #25218: python_2_unicode_compatible causes infinite recursion when super().__str__() is called

[Django]

#25218: python_2_unicode_compatible causes infinite recursion when
super().__str__() is called
---+
 Reporter:  jscn   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Utilities  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have a class `A` which implements `__str__()` and is decorated with
 `@python_2_unicode_compatible`.

 I have sub-class of `A`, `B`, and `B` 's implementation of `__str__()`
 calls `super().__str__()`.

 When I call `b.__str__()`, I get the following error: `RuntimeError:
 maximum recursion depth exceeded while calling a Python object`.

 Partial traceback:

 {{{#!python
   File "/home/josh/Desktop/temp/djtest/local/lib/python2.7/site-
 packages/django/utils/encoding.py", line 42, in 
 klass.__str__ = lambda self: self.__unicode__().encode('utf-8')
   File "recursion.py", line 27, in __str__
 super().__str__(),
   File "/home/josh/Desktop/temp/djtest/local/lib/python2.7/site-
 packages/django/utils/encoding.py", line 42, in 
 klass.__str__ = lambda self: self.__unicode__().encode('utf-8')
   File "recursion.py", line 27, in __str__
 super().__str__(),
 }}}

 The docs
 
(https://docs.djangoproject.com/en/dev/ref/utils/#django.utils.encoding.python_2_unicode_compatible)
 imply that the decorator should be applied to *any* class implementing
 `__str__()`

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

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

Re: [Django] #25201: Allow use_for_related_fields via as_manager()

[Django]

#25201: Allow use_for_related_fields via as_manager()
-+-
 Reporter:  litchfield   |Owner:
 |  andersonresende
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by andersonresende):

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


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

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

Re: [Django] #25215: Attribute error in HStore form field

[Django]

#25215: Attribute error in HStore form field
--+
 Reporter:  MarkusH   |Owner:  FunkyBob
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by funkybob):

 PR with fix is here : https://github.com/django/django/pull/5097

 This should certainly be back ported to 1.8 {PR is against master}

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

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

Re: [Django] #25217: cleanup - M2M shouldn't take a 'default' kwarg

[Django]

#25217: cleanup - M2M shouldn't take a 'default' kwarg
-+-
 Reporter:  mjlock   |Owner:  mjlock
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mjlock):

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


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

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

[Django] #25217: cleanup - M2M shouldn't take a 'default' kwarg

[Django]

#25217: cleanup - M2M shouldn't take a 'default' kwarg
--+
 Reporter:  mjlock|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Core (Other)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Many to Many field shouldn't take a 'default' kwarg as it doesn't use it.
 Should raise a warning if one is given.

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

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

Re: [Django] #24988: Document raising a dictionary of ValidationErrors

[Django]

#24988: Document raising a dictionary of ValidationErrors
-+-
 Reporter:  michaeljohnbarr  |Owner:
 Type:   |  adambrenecki
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  ValidationError  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by adambrenecki):

 * needs_better_patch:  1 => 0


Comment:

 I've removed the 'for instance' bit, is that all that needs fixing?

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

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

Re: [Django] #25216: DB migration bug in 1.8.3 when creating ManyToMany relation.

[Django]

#25216: DB migration bug in 1.8.3 when creating ManyToMany relation.
+--
 Reporter:  cx44yale|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  migrate | 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 cx44yale:

Old description:

> Hi,
> I am using python version 3.4 and django 1.8.3, I have the following very
> simple code:
> {{{
> from django.contrib.auth.models import User
>
> class Agent(models.Model):
>
> name = models.CharField(max_length=100)
> users = models.ManyToManyField(User,
> related_name='accessible_agents', default=[])
> }}}
> and when I have an empty database, and do python manage.py migrate.
>
> It gives me error, and I tested on 1.7.8, it works fine.
> {{{
> Operations to perform:
>   Synchronize unmigrated apps: staticfiles, download, messages
>   Apply all migrations: admin, auth, contenttypes, sessions
> Synchronizing apps without migrations:
>   Creating tables...
> Creating table download_agent
> Running deferred SQL...
> Traceback (most recent call last):
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 62, in execute
> return self.cursor.execute(sql)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/mysql/base.py", line 124, in execute
> return self.cursor.execute(query, args)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 220, in execute
> self.errorhandler(self, exc, value)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
> raise errorvalue
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 209, in execute
> r = self._query(query)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 371, in _query
> rowcount = self._do_query(q)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 335, in _do_query
> db.query(q)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/connections.py", line 280, in query
> _mysql.connection.query(self, query)
> _mysql_exceptions.OperationalError: (1005, "Can't create table
> 'portal_aperture.#sql-403_b3' (errno: 150)")
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 338, in
> execute_from_command_line
> utility.execute()
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/base.py", line 393, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/base.py", line 444, in execute
> output = self.handle(*args, **options)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/commands/migrate.py", line 179, in handle
> created_models = self.sync_apps(connection,
> executor.loader.unmigrated_apps)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/commands/migrate.py", line 317, in
> sync_apps
> cursor.execute(statement)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 79, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/utils.py", line 97, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/utils/six.py", line 658, in reraise
> raise 

Re: [Django] #25216: DB migration bug in 1.8.3 when creating ManyToMany relation.

[Django]

#25216: DB migration bug in 1.8.3 when creating ManyToMany relation.
+--
 Reporter:  cx44yale|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  migrate | 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 timgraham:

Old description:

> Hi,
> I am using python version 3.4 and django 1.8.3, I have the following very
> simple code:
>
> from django.contrib.auth.models import User
>
> class Agent(models.Model):
>
> name = models.CharField(max_length=100)
> users = models.ManyToManyField(User,
> related_name='accessible_agents', default=[])
>
> and when I have an empty database, and do python manage.py migrate.
>
> It gives me error, and I tested on 1.7.8, it works fine.
>
> Operations to perform:
>   Synchronize unmigrated apps: staticfiles, download, messages
>   Apply all migrations: admin, auth, contenttypes, sessions
> Synchronizing apps without migrations:
>   Creating tables...
> Creating table download_agent
> Running deferred SQL...
> Traceback (most recent call last):
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 62, in execute
> return self.cursor.execute(sql)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/mysql/base.py", line 124, in execute
> return self.cursor.execute(query, args)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 220, in execute
> self.errorhandler(self, exc, value)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
> raise errorvalue
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 209, in execute
> r = self._query(query)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 371, in _query
> rowcount = self._do_query(q)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 335, in _do_query
> db.query(q)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/connections.py", line 280, in query
> _mysql.connection.query(self, query)
> _mysql_exceptions.OperationalError: (1005, "Can't create table
> 'portal_aperture.#sql-403_b3' (errno: 150)")
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 338, in
> execute_from_command_line
> utility.execute()
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/base.py", line 393, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/base.py", line 444, in execute
> output = self.handle(*args, **options)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/commands/migrate.py", line 179, in handle
> created_models = self.sync_apps(connection,
> executor.loader.unmigrated_apps)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/commands/migrate.py", line 317, in
> sync_apps
> cursor.execute(statement)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 79, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/utils.py", line 97, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/utils/six.py", line 658, in reraise
> raise 

Re: [Django] #25209: coverage html doesn't work as documented

[Django]

#25209: coverage html doesn't work as documented
-+-
 Reporter:  pzrq |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by MarkusH):

 I admit I might was a bit too eager to get parallel coverage support on
 Jenkins running but staled due to a missing feature in coverage:
 https://bitbucket.org/ned/coveragepy/issues/277/combined-parallel-report-
 should-use

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

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

Re: [Django] #25216: DB migration bug in 1.8.3 when creating ManyToMany relation.

[Django]

#25216: DB migration bug in 1.8.3 when creating ManyToMany relation.
+--
 Reporter:  cx44yale|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  migrate | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by cx44yale):

 I suspect it is a problem with the order executed, the M2M expects my User
 model.

 I removed all of my models definition in that app, and run python
 manage.py migrate to generate all those auth, sessions builtin tables, and
 then paste my models back run migrate again, this time everything works,
 and all the tables are generated correctly.

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

Re: [Django] #25216: DB migration bug in 1.8.3 when creating ManyToMany relation.

[Django]

#25216: DB migration bug in 1.8.3 when creating ManyToMany relation.
+--
 Reporter:  cx44yale|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  migrate | 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 cx44yale:

Old description:

> Hi,
> I have the following very simple code:
>
> from django.contrib.auth.models import User
>
> class Agent(models.Model):
>
> name = models.CharField(max_length=100)
> users = models.ManyToManyField(User,
> related_name='accessible_agents', default=[])
>
> and when I have an empty database, and do python manage.py migrate.
>
> It gives me error, and I tested on 1.7.8, it works fine.
>
> Operations to perform:
>   Synchronize unmigrated apps: staticfiles, download, messages
>   Apply all migrations: admin, auth, contenttypes, sessions
> Synchronizing apps without migrations:
>   Creating tables...
> Creating table download_agent
> Running deferred SQL...
> Traceback (most recent call last):
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 62, in execute
> return self.cursor.execute(sql)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/mysql/base.py", line 124, in execute
> return self.cursor.execute(query, args)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 220, in execute
> self.errorhandler(self, exc, value)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
> raise errorvalue
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 209, in execute
> r = self._query(query)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 371, in _query
> rowcount = self._do_query(q)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/cursors.py", line 335, in _do_query
> db.query(q)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/MySQLdb/connections.py", line 280, in query
> _mysql.connection.query(self, query)
> _mysql_exceptions.OperationalError: (1005, "Can't create table
> 'portal_aperture.#sql-403_b3' (errno: 150)")
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 338, in
> execute_from_command_line
> utility.execute()
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/base.py", line 393, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/base.py", line 444, in execute
> output = self.handle(*args, **options)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/commands/migrate.py", line 179, in handle
> created_models = self.sync_apps(connection,
> executor.loader.unmigrated_apps)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/core/management/commands/migrate.py", line 317, in
> sync_apps
> cursor.execute(statement)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 79, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 64, in execute
> return self.cursor.execute(sql, params)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/db/utils.py", line 97, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
> packages/django/utils/six.py", line 658, in reraise
> raise value.with_traceback(tb)
>   File 

Re: [Django] #25216: DB migration bug in 1.8.3 when creating ManyToMany relation.

[Django]

#25216: DB migration bug in 1.8.3 when creating ManyToMany relation.
+--
 Reporter:  cx44yale|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  migrate | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by cx44yale):

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


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

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

[Django] #25216: DB migration bug in 1.8.3 when creating ManyToMany relation.

[Django]

#25216: DB migration bug in 1.8.3 when creating ManyToMany relation.
+-
 Reporter:  cx44yale|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.8
 Severity:  Normal  |   Keywords:  migrate
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+-
 Hi,
 I have the following very simple code:

 from django.contrib.auth.models import User

 class Agent(models.Model):

 name = models.CharField(max_length=100)
 users = models.ManyToManyField(User, related_name='accessible_agents',
 default=[])

 and when I have an empty database, and do python manage.py migrate.

 It gives me error, and I tested on 1.7.8, it works fine.

 Operations to perform:
   Synchronize unmigrated apps: staticfiles, download, messages
   Apply all migrations: admin, auth, contenttypes, sessions
 Synchronizing apps without migrations:
   Creating tables...
 Creating table download_agent
 Running deferred SQL...
 Traceback (most recent call last):
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/db/backends/utils.py", line 62, in execute
 return self.cursor.execute(sql)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/db/backends/mysql/base.py", line 124, in execute
 return self.cursor.execute(query, args)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/MySQLdb/cursors.py", line 220, in execute
 self.errorhandler(self, exc, value)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
 raise errorvalue
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/MySQLdb/cursors.py", line 209, in execute
 r = self._query(query)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/MySQLdb/cursors.py", line 371, in _query
 rowcount = self._do_query(q)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/MySQLdb/cursors.py", line 335, in _do_query
 db.query(q)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/MySQLdb/connections.py", line 280, in query
 _mysql.connection.query(self, query)
 _mysql_exceptions.OperationalError: (1005, "Can't create table
 'portal_aperture.#sql-403_b3' (errno: 150)")

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

 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 338, in
 execute_from_command_line
 utility.execute()
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 330, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/core/management/base.py", line 393, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/core/management/base.py", line 444, in execute
 output = self.handle(*args, **options)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/core/management/commands/migrate.py", line 179, in handle
 created_models = self.sync_apps(connection,
 executor.loader.unmigrated_apps)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/core/management/commands/migrate.py", line 317, in
 sync_apps
 cursor.execute(statement)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/db/utils.py", line 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/utils/six.py", line 658, in reraise
 raise value.with_traceback(tb)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/db/backends/utils.py", line 62, in execute
 return self.cursor.execute(sql)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 packages/django/db/backends/mysql/base.py", line 124, in execute
 return self.cursor.execute(query, args)
   File "/srv/company/virtualenvs/portal_aperture/lib/python3.4/site-
 

[Django] #25215: Attribute error in HStore form field

[Django]

#25215: Attribute error in HStore form field
+--
   Reporter:  MarkusH   |  Owner:  FunkyBob
   Type:  Bug   | Status:  new
  Component:  contrib.postgres  |Version:  1.8
   Severity:  Release blocker   |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
 The HStore form field uses `form.HStoreField` in `has_changed()` instead
 of `HStoreField`.

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

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

[Django] #25214: Behavior of _meta.auto_created = True in m2m through model is not expected.

[Django]

#25214: Behavior of  _meta.auto_created = True in m2m through model is not
expected.
+
 Reporter:  Cinkz   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.8
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I have models like:

 {{{

 class A(models.Model):
 ...
 b = models.ManyToManyField(
 'B',
 through='Through',
 )
...

 class B(models.Model):
...

 class Through(models.Model):
 a = models.ForeignKey('A')
 b = models.ForeignKey('B')
 ...
 # other fields have default value

 class Meta:
 auto_created = False
 }}}

 If I make migrations at this point, joint table 'Through' will be created.

 Then if I set "Through._meta.auto_created = True" somewhere, and never
 update migrations. Everything works well. If I add a new relationship
 between A instance and B instance, a through object will be created with
 default value, which looks great.

 However if I update migrations, the "Through" model will be removed in
 migrations and everything break.

 I think a through model with auto_created=True should be kept in
 migrations and when new relationships created, through objects shall be
 created with claimed default value.

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

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

Re: [Django] #25212: Document RawSQL expression

[Django]

#25212: Document RawSQL expression
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #25213: Discourage use of QuerySet.extra()

[Django]

#25213: Discourage use of QuerySet.extra()
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #25172: System checks don't respect database routers

[Django]

#25172: System checks don't respect database routers
-+-
 Reporter:  delinhabit   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.7
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  system-checks| Triage Stage:  Accepted
  multi-database |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Some test failures need to be addressed.

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

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

[Django] #25213: Discourage use of QuerySet.extra()

[Django]

#25213: Discourage use of QuerySet.extra()
-+-
   Reporter:  timgraham  |  Owner:  timgraham
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  1.8
  Documentation  |
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 from Anssi [https://groups.google.com/d/topic/django-
 developers/FojuU0syO8Y/discussion on django-developers]:

 You can annotate raw SQL with expressions. I think the only case that
 can't be done with expressions is addition of extra tables to the query. I
 am certain we will get a solution to this too in future releases.

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

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

[Django] #25212: Document RawSQL expression

[Django]

#25212: Document RawSQL expression
-+-
   Reporter:  timgraham  |  Owner:  timgraham
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  1.8
  Documentation  |
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 from Anssi [https://groups.google.com/d/msg/django-
 developers/FojuU0syO8Y/YjUFY1jqCAAJ on django-developers]:

  There doesn't seem to be direct documentation about RawSQL expression.
 The RawSQL is once mentioned in the documentation, but it definitely needs
 a bit more in the database functions documentation.
  [[BR]]
  The usage of RawSQL is really simple: `qs.annotate(val=RawSQL("(select
 col from sometable where othercol= %s)", (someparam,)))`
  [[BR]]
  This is equivalent to `qs.extra(select={'val': "select col from sometable
 where othercol = %s"}, select_params=(someparam,))`
  [[BR]]
  The main benefit of using RawSQL is that you can set output_field if
 needed. The main downside is that if you refer to some table alias of the
 qs in the raw sql, then it is possible that Django changes that alias (for
 example, when the qs is used as a subquery in yet another query).
  [[BR]]
  Combining raw SQL with alias relabeling support is possible, too with the
 following library: https://github.com/akaariai/django-refsql

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

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

Re: [Django] #25209: coverage html doesn't work as documented

[Django]

#25209: coverage html doesn't work as documented
-+-
 Reporter:  pzrq |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by shaib):

 * cc: shaib (added)


Comment:

 FWIW, I promised to get Oracle support for the parallel test runner, and
 then couldn't really complete the work because of RL etc. I'll have more
 time for this after this weekend (when a conference I'm organizing is
 over).

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

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

Re: [Django] #15760: Feature: JS Hooks for Dynamic Inlines

[Django]

#15760: Feature: JS Hooks for Dynamic Inlines
-+-
 Reporter:  mlavin   |Owner:
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  inlines jquery   | Triage Stage:  Accepted
  callback   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by timgraham):

 Maybe a new page at `docs/ref/contrib/admin/javascript.txt` would make
 sense. Anyway, the content is more important than the location at this
 point.

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

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

Re: [Django] #25209: coverage html doesn't work as documented

[Django]

#25209: coverage html doesn't work as documented
-+-
 Reporter:  pzrq |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


Comment:

 I think it's fine to commit this for now. Markus's project to improve
 coverage on Jenkins hasn't been completed and it's not clear to me that
 `parallel=True` should be the default..

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

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

Re: [Django] #25211: Add USE_X_FORWARDED_PORT setting and HttpRequest.get_port()

[Django]

#25211: Add USE_X_FORWARDED_PORT setting and HttpRequest.get_port()
-+-
 Reporter:  mattrobenolt |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  port, server_port,   | Triage Stage:  Ready for
  proxy  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #25211: Add USE_X_FORWARDED_PORT setting and HttpRequest.get_port()

[Django]

#25211: Add USE_X_FORWARDED_PORT setting and HttpRequest.get_port()
-+-
 Reporter:  mattrobenolt |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  port, server_port,   | Triage Stage:  Accepted
  proxy  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mattrobenolt):

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


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

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

[Django] #25211: Add USE_X_FORWARDED_PORT setting and HttpRequest.get_port()

[Django]

#25211: Add USE_X_FORWARDED_PORT setting and HttpRequest.get_port()
---+--
 Reporter:  mattrobenolt   |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  HTTP handling  |Version:  master
 Severity:  Normal |   Keywords:  port, server_port, proxy
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+--
 It's be nice to internally have a way to reference the "real" port number
 when behind a proxy.

 Today, as an example:

 If you were running a load balancer on port 80, which proxied back to an
 nginx which was running on 8080, it's possible that `get_host()` would
 resolve your request back to `example.com:8080` instead of the proper
 `example.com` since `SERVER_PORT` is coming from what nginx was listening
 on.

 This just adds a proper method to `get_port()` and respect an optional `X
 -Forwarded-Port` header.

 The benefits of this being internal to Django, is because anywhere that
 Django tries to resolve the port internally, we should be utilizing this
 method. This issue is easy to correct in user-land, but a bit harder when
 an internal Django method utilizes `SERVER_PORT` directly. The only option
 is to have a middleware which sets `request.META['SERVER_PORT'] =
 request.META['HTTP_X_FORWARDED_PORT']` which is less than ideal IMO since
 it's overloading the meaning of the variable.

 This is also relevant for https://github.com/django/django/pull/4337 since
 in the wild, we hit an issue with `SERVER_PORT` not reflecting what the
 upstream actually was, which caused issues. So this would unify and make
 https://github.com/django/django/pull/4337 leverage the new `get_port()`.

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

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

Re: [Django] #25197: Add a more friendly widget for HStoreField

[Django]

#25197: Add a more friendly widget for HStoreField
--+
 Reporter:  gam_phon  |Owner:  funkybob
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  widget| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+
Changes (by funkybob):

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


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

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

Re: [Django] #25197: Add a more friendly widget for HStoreField

[Django]

#25197: Add a more friendly widget for HStoreField
--+
 Reporter:  gam_phon  |Owner:
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  widget| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+

Comment (by funkybob):

 I ran into this recently, and found django-hstore's widget a trivial drop
 in that did the job.

 I'm happy to work on re-engineering it to remove the other dependencies,
 if nobody objects.

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

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

Re: [Django] #25209: coverage html doesn't work as documented

[Django]

#25209: coverage html doesn't work as documented
---+
 Reporter:  pzrq   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by pzrq):

 @aaugustin

 TLDR My PR is currently removing one line. I'll happily put the `coverage
 combine` documentation and a revert of that one line removal (i.e.
 basically option 2) together tomorrow at PyConAU sprints if you think it
 will be useful for your parallel test runner.

 But unless that's coming really soon it would be nice to restore the
 documentation to a more consistent state as Django does pride itself on
 documentation being a first class citizen.

 

 https://github.com/django/django/compare/master...aaugustin:parallelize-
 tests-attempt-1
 That looks really really cool!

 I just wonder if how likely it is to make the Django 1.9 alpha around mid
 September 2015?
 (Using as the guide Django 1.8 which took 2.5 months from alpha to
 release, and I fully appreciate that question may be impossible to answer
 until 1.9 alpha comes with or without it).

 In any case it's a lot grander in scope than my attempt so far (`discover-
 road-runner`) - I usually use it dozens of times a day and it works
 wonders for my TDD productivity and testing other developers work more
 quickly (without needing `--nomigrations` in `django-test-without-
 migrations`); but it doesn't handle not-in-memory DBs, live application
 servers, file upload, etc. And I'd be the first to admit it's a kludge to
 generate test output cleanly and quickly (but has the benefit of not
 needing to pickle things like tracebacks if you print them straight away),
 and handle the really expensive migrations step better. With any luck OSX
 10.11 El Capitan will mean you won't have to worry about all the headaches
 of the builtin `multiprocessing` module under OSX Python 2.7.6 at least (a
 colleague suggested I use the `billiard` fork entirely due to the time I
 have spent wrangling `multiprocessing` and `sqlite3` crashes which AFAIK
 are fixed upstream and certainly in Python 3.4). I guess this is just a
 longer way of saying good luck - parallelism can be very challenging and
 fun!

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

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

[Django] #25210: Function of Stair lifts that work for handicapped

[Django]

#25210: Function of Stair lifts that work for handicapped
---+
 Reporter:  rajanandan88   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The width of each stair treads needs to be at least a single meter.
 Narrower stairs tend not to deliver sufficient place to put in a stair
 elevate and then to move somebody. The height with the adjacent wall shall
 be no less than one meter. The space of your stairs on the following door
 have to be not less than just one meter. When you can solution each one of
 these points is favourable, it really is likely that a staircase is
 usually put in to suit your needs. But clarify accurately this may only
 become a specialist to get a web-site check out. Legal framework for set
 up of stair lifts inside of a rented home. Should you exist within an
 condominium setting up and also have to rely on a stair elevate, it's
 essential to request the landlord or operator for permission in advance of
 installation. It's a permissible obligation that the tenant may perhaps
 ask for acceptance for disabled use and barrier-free access while using
 the landlord. But beware: The cost of a later on, achievable restoration
 from the preceding point out need to be borne with the tenant. Observe for
 that reason the subsequent for those who want to set up a stair elevate
 inside of a block of flats. Or the owner the operator will have to approve
 the strategy unanimously. The owner or perhaps the landlord need to also
 agree. The planning of accessibility is barely permitted for private
 dwellings. As stated higher than, needs to be no less than 150 cm, the
 width on the stairs. The handrail should not be covered from the elevate
 or the use ought to not be restricted. A fold-up seat on the stairlift is
 usually a prerequisite and with folded up seat should be at least 60cm
 place continue to continue being. Buying Stair Lifts at a discount price
 from http://www.sosyalforum.org/die-miete-eines-treppenliftes. It must it
 not be feasible to put in a stair carry within a block of flats, one
 example is due to the fact vetoed the proprietor, there are alternate
 options to stair elevate, stair so-called aids. So there is wheelchair
 stair crawler example through which the wheelchair is drag by chains for
 the up coming ground.


 Just like the caterpillar lifts perform also known as stair climber or
 perhaps Stair walker. Not like these stairlifts are options ordinarily
 only for a confined time. The rail technique, you cannot independently
 establish in accordance with taste and choice, because the built-in stairs
 affected the rail method regretably. These lifts can be adapted to equally
 curvy, straight and of slim stairs. As by now indicated quite a few
 instances briefly, you'll find also particular stair lifts for
 wheelchairs. These are typically advisable as a consequence of the higher
 charge for wheelchair buyers, as other movement restrictions can be
 prevail over having a convenient stand or sit lift. So are about system
 and System lifts for the stair lifts which can be particularly created for
 wheelchairs. While in the following segment, you can locate all crucial
 specifics of stair lifts for wheelchair buyers at a look. Characteristics
 of a stair elevate for wheelchair buyers. They may be installed indoors or
 outdoor. The particular system of the raise might be folded to ensure it
 whether it is unused, isn't going to take up space as well as other
 individuals can easily pass within the raise. Since wheelchairs can be
 quite tricky sometimes, the utmost ability of such a lift is
 correspondingly significant. This can be as much as about a few hundred to
 four hundred kg. The platform has to be attached into a rail process or a
 guidebook rail. This rail method is mounted instantly on the stairs and
 adapted into the staircase condition. Typically features a elevate on any
 system ramps and strap to hold while driving. These functions be certain
 that a wheelchair stairlift can also use by itself and is not depending on
 outside the house enable. If wheelchair lifts are positioned outdoors the
 house, they can be ordinarily and made so that you will never slip from
 the rain. The dealing with on the stairlift is via a small joystick
 directly to the platform. This can make the operation quite quick. Simply
 click in this article to understand additional data for Buying Stair Lifts
 at a discount price.
 Most lifts their energy nowadays have a very battery and never through the
 power grid. This tends to make them safe and sound versus electric power
 failures. The battery is definitely rechargeable and retains fairly a
 while without having charging. Other 

Re: [Django] #22837: Migrations detect unnessecary(?) changes

[Django]

#22837: Migrations detect unnessecary(?) changes
---+--
 Reporter:  valberg|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  1.7-beta-2
 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 guettli):

 Unfortunately Django 1.7 does not allow choices to be a callable. This was
 introduced in Django 1.8.

 That's sad.

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

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

Re: [Django] #25206: Incorrect error message when checking modeladmin fieldsets

[Django]

#25206: Incorrect error message when checking modeladmin fieldsets
---+
 Reporter:  alasdairnicol  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"7a8460191eabcbe3b63deeebcde7c7097f62bb08" 7a846019]:
 {{{
 #!CommitTicketReference repository=""
 revision="7a8460191eabcbe3b63deeebcde7c7097f62bb08"
 [1.8.x] Fixed #25206 -- Fixed error message when checking a ModelAdmin
 fieldset's fields.

 Backport of 8972818289452d611d97fac0f4a6d24625987b31 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/071.3fd0692d3e02e1d4b91421a8c15a862a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25206: Incorrect error message when checking modeladmin fieldsets

[Django]

#25206: Incorrect error message when checking modeladmin fieldsets
---+
 Reporter:  alasdairnicol  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"8972818289452d611d97fac0f4a6d24625987b31" 89728182]:
 {{{
 #!CommitTicketReference repository=""
 revision="8972818289452d611d97fac0f4a6d24625987b31"
 Fixed #25206 -- Fixed error message when checking a ModelAdmin fieldset's
 fields.
 }}}

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

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

Re: [Django] #17914: Add support for namespaced view references when passing a callable to reverse() (was: reverse() does not support namespaced view references when passed a callable)

[Django]

#17914: Add support for namespaced view references when passing a callable to
reverse()
-+-
 Reporter:  Bradley Ayers|Owner:  nobody
    |
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

Re: [Django] #17914: reverse() does not support namespaced view references when passed a callable

[Django]

#17914: reverse() does not support namespaced view references when passed a
callable
-+-
 Reporter:  Bradley Ayers|Owner:  nobody
    |
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"a6acfc31837fd7a9e0e387320d995b2c85cfcfce" a6acfc31]:
 {{{
 #!CommitTicketReference repository=""
 revision="a6acfc31837fd7a9e0e387320d995b2c85cfcfce"
 Refs #17914 -- Discouraged using reverese() with callables.
 }}}

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

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

Re: [Django] #17914: reverse() does not support namespaced view references when passed a callable

[Django]

#17914: reverse() does not support namespaced view references when passed a
callable
-+-
 Reporter:  Bradley Ayers|Owner:  nobody
    |
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"f32bb3adf039b72cea34347022626231d187e303" f32bb3a]:
 {{{
 #!CommitTicketReference repository=""
 revision="f32bb3adf039b72cea34347022626231d187e303"
 [1.8.x] Refs #17914 -- Discouraged using reverese() with callables.

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

Re: [Django] #15760: Feature: JS Hooks for Dynamic Inlines

[Django]

#15760: Feature: JS Hooks for Dynamic Inlines
-+-
 Reporter:  mlavin   |Owner:
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  inlines jquery   | Triage Stage:  Accepted
  callback   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by RamezIssac):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #24988: Document raising a dictionary of ValidationErrors

[Django]

#24988: Document raising a dictionary of ValidationErrors
-+-
 Reporter:  michaeljohnbarr  |Owner:
 Type:   |  adambrenecki
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  ValidationError  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #25205: Removed deprecated GeoManager from doc examples

[Django]

#25205: Removed deprecated GeoManager from doc examples
-+-
 Reporter:  timgraham|Owner:
 Type:   |  BMJHayward
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by BMJHayward):

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


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

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

Re: [Django] #25172: System checks don't respect database routers

[Django]

#25172: System checks don't respect database routers
-+-
 Reporter:  delinhabit   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.7
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  system-checks| Triage Stage:  Accepted
  multi-database |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 Great. By the way, don't forget to check "Has patch" so the ticket appears
 in the review queue.

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

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

Re: [Django] #25191: Better error output for assertXMLEqual

[Django]

#25191: Better error output for assertXMLEqual
-+-
 Reporter:  shelldweller |Owner:
 Type:   |  caioariede
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 Don't forget to check "Has patch" so the ticket appears in the review
 queue. Please uncheck "Needs tests" when updated, 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/070.63ad4d9a1b2e68bd8cad5a59fae8f7aa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25209: coverage html doesn't work as documented

[Django]

#25209: coverage html doesn't work as documented
---+
 Reporter:  pzrq   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

 * cc: MarkusH (added)
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #25208: Admin site NoReverseMatch

[Django]

#25208: Admin site NoReverseMatch
-+-
 Reporter:  albus12138   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  admin| Triage Stage:
  NoReverseMatch |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 We'll need a sample project to reproduce this.

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

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

Re: [Django] #25194: Improper MONTH_DAY_FORMAT for Korean(ko) language

[Django]

#25194: Improper MONTH_DAY_FORMAT for Korean(ko) language
-+-
 Reporter:  seungjin |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Ko, Korean, i10n,| Triage Stage:  Ready for
  Locale |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"14c1fd0730e2fd5ae5eb1c61dbea2e08582fab65" 14c1fd07]:
 {{{
 #!CommitTicketReference repository=""
 revision="14c1fd0730e2fd5ae5eb1c61dbea2e08582fab65"
 Fixed #25194 -- Fixed Korean YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT.

 'F' translates a month to a Korean name with a month number so,
 for example, 'F 월' becomes '10 월월' for October. This should
 be either 'F' or 'n월', and I followed conventions in other
 languages like Japanese and Chinese.
 }}}

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

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

Re: [Django] #25209: coverage html doesn't work as documented

[Django]

#25209: coverage html doesn't work as documented
---+--
 Reporter:  pzrq   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 I'm working on a branch that allows parallel execution of Django tests
 with `multiprocessing`. It would be nice if it remained compatible with
 coverage measurement. Perhaps we can have different instructions for users
 of the `--parallel` option once it exists.

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

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

[Django] #25209: coverage html doesn't work as documented

[Django]

#25209: coverage html doesn't work as documented
---+
 Reporter:  pzrq   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 After running the command, under OSX 10.10.4 / Python 3.4.2 (via homebrew)
 and coverage==3.7.1:
 {{{
 coverage run ./runtests.py
 }}}

 I get no `.coverage` file, after:
 
https://github.com/django/django/commit/4202959b6febd02cdaa712c666fa0d79569038ca

 This appears to be caused by the `parallel = True` option, details:
 http://nedbatchelder.com/code/coverage/config.html#h_run

 For instance, I currently have:
 {{{
 (django_py3)pzrq@icebox:~/Projects/django/tests$ ls -a | grep .coverage
 .coverage.icebox.local.42652.649933
 .coverage.icebox.local.42665.263961
 .coverage.icebox.local.42673.382480
 ...
 # Importantly no .coverage file
 }}}
 This means when you run downstream tools, such as `coverage report -m` or
 `coverage html` as recommended in the Django docs, i.e.
 https://docs.djangoproject.com/en/1.8/internals/contributing/writing-code
 /unit-tests/#code-coverage, you get the not very interesting output like
 the following:
 {{{
 (django_py3)pzrq@icebox:~/Projects/django/tests$ coverage report -m
 NameStmts   Miss  Cover   Missing
 -
 (django_py3)pzrq@icebox:~/Projects/django/tests$
 }}}

 I can see two possible fixes to discuss:

 1. Remove `parallel = True` from `.coveragerc`
 2. Update the documentation such as
 https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /unit-tests/#code-coverage with the intermediate `coverage combine` step,
 to merge the different coverage report(s) together to generate a more
 typical `.coverage` file.

 AFAIK multiprocessing isn't supported by the Django test runner, so +1 for
 option 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/047.8937725bec933d48631b36023846cb01%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17914: reverse() does not support namespaced view references when passed a callable

[Django]

#17914: reverse() does not support namespaced view references when passed a
callable
-+-
 Reporter:  Bradley Ayers|Owner:  nobody
    |
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by apollo13):

 LGTM

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

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

Re: [Django] #24533: Changing an AutoField into an IntegerField leaks the sequence on PostgreSQL

[Django]

#24533: Changing an AutoField into an IntegerField leaks the sequence on 
PostgreSQL
+
 Reporter:  aaugustin   |Owner:  adambrenecki
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.7
 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 adambrenecki):

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