date:20170104

Re: [Django] #27587: Document str(QuerySet.query)

2017-01-04 Thread Django

#27587: Document str(QuerySet.query)
--+
 Reporter:  Peter Inglesby|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mads Jensen):

 * has_patch:  0 => 1


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

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

[Django] #27687: Dateformat issue using django basic logging formatter

2017-01-04 Thread Django

#27687: Dateformat issue using django basic logging formatter
-+-
   Reporter:  Ahn|  Owner:  nobody
  ByungHyun  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Utilities  |Version:  1.10
   Severity:  Normal |   Keywords:  logging formatter
   Triage Stage: |  datefmt
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm using django v1.10.4 with python 3.5.2 and write Logging setting in
 setting.py.

 I faced some problem using log formatter.

 I want to present date format of log like '%Y-%m-%d %H:%M:%S.%f%z' but %f
 is not work.

 My formatters setting is like this.

 '''
 'formatters': {
 'verbose': {
 'format': '%(levelname)s %(asctime)s %(module)s %(process)d
 %(thread)d %(message)s',
 'datefmt':'%Y-%m-%d %H:%M:%S.%f%z',
 },
 'simple': {
 'format': '%(levelname)s %(message)s'
 },
 },
 '''

 The log %(asctime)s is printed "2017-01-05 13:54:24.f+0900"

 Is this bug? or intented behavior?

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

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

Re: [Django] #27686: calls to request.user.is_authenticated returns vary by cookie header for all users

2017-01-04 Thread Django

#27686: calls to request.user.is_authenticated returns vary by cookie header for
all users
---+--
 Reporter:  Jeff Willette  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.auth   |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Jeff Willette):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => contrib.auth


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

[Django] #27686: calls to request.user.is_authenticated returns vary by cookie header for all users

2017-01-04 Thread Django

#27686: calls to request.user.is_authenticated returns vary by cookie header for
all users
-+
Reporter: Jeff Willette | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized |Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+
If request.user.is_authenticated() is called in a view, a `Vary: "Cookie"`
Http header is returned, even if the user is an anonymous user. The
anonymous user has no `sessionid` and no other cookies set. This means
that any other inconsequential cookies that are in the request (such as
google analytics) will cause downstream caches to cache separate pages for
each user.

I think that is the user is not_authenticated, then there should be no
`Vary` header sent back from django.

You can recreate this problem by creating a new django project and
creating a view that returns an HttpResponse after calling to
is_authenticated with an anonymous user, and also calling another view
that does not call to is_authenticated and comparing the HttpHeaders. I
have done so here: https://github.com/deltaskelta/django-is-authenticated-
vary-headers.git

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

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

2017-01-04 Thread Django

#27680: Recommend ccbv.co.uk in class-based views docs
--+
 Reporter:  James Pic |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.10
 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:"944610a86c81f90c3c79e5440a5e2c706aa0ef62" 944610a]:
 {{{
 #!CommitTicketReference repository=""
 revision="944610a86c81f90c3c79e5440a5e2c706aa0ef62"
 Fixed #27680 -- Linked to "Classy Class-Based Views" in docs.
 }}}

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

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

2017-01-04 Thread Django

#27680: Recommend ccbv.co.uk in class-based views docs
--+
 Reporter:  James Pic |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.10
 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:"f582db1296cc18e2ff49846c9be4ad999759adcc" f582db12]:
 {{{
 #!CommitTicketReference repository=""
 revision="f582db1296cc18e2ff49846c9be4ad999759adcc"
 [1.10.x] Fixed #27680 -- Linked to "Classy Class-Based Views" in docs.

 Backport of 944610a86c81f90c3c79e5440a5e2c706aa0ef62 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.9c6aecf4475ae62d8241e0c171935612%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27356: admin lookup_allowed incorrectly returns False for a nested reverse OneToOneField

2017-01-04 Thread Django

#27356: admin lookup_allowed incorrectly returns False for a nested reverse
OneToOneField
---+
 Reporter:  Tobias Krönke  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Anton Samarchyan):

 * has_patch:  0 => 1


Comment:

 I added a [https://github.com/django/django/pull/7792 PR]

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

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

[Django] #27685: Allow autoreloader to use watchman

2017-01-04 Thread Django

#27685: Allow autoreloader to use watchman
+
Reporter: Aymeric Augustin | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Utilities |Version: master
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 |
+
I believe we should stop maintaining an autoreloader as soon as possible.
Django’s autoreloader is annoyingly slow, highly inefficient, moderately
well designed, and a gigantic pain to maintain. I’m more scared of
`django.utils.autoreload` than of `django.db.models.related` before it was
cleaned up.

I wish one day someone will take the time to write a good autoreloading
dev server based on watchman. This would solve the problem discussed here
because watchman watches all files in the current directory. The correct
way to do this is to throw away the current design and start from scratch.

Watchman is smart enough to wait until you’ve finished a git operation to
trigger a reload. Once such polished tech has become available, trying to
compete with a thread that checks the mtime of all known files every
second isn’t funny anymore. In fact it’s just sad.

from [https://groups.google.com/d/msg/django-
developers/HB0S4cF0DO4/YepyGyJZFAAJ django-developers thread]

The [https://groups.google.com/d/topic/django-
developers/voXNIDdDcpU/discussion Future of the development server's auto-
reloading thread] has some ideas about this.

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

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

Re: [Django] #27586: Django sometimes crashes on Windows when being launched in PyCharm

2017-01-04 Thread Django

#27586: Django sometimes crashes on Windows when being launched in PyCharm
--+--
 Reporter:  Vilius Poška  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Utilities |  Version:  1.10
 Severity:  Normal|   Resolution:  needsinfo
 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 Vašek Dohnal):

 I'm have sometimes same issue on Windows 10 Pro (1607) when I run Django
 runserver from Powershell console. Here is mine Windows Event log:

 {{{
 Faulting application name: python.exe, version: 3.5.1150.1013, time stamp:
 0x576eff6a
 Faulting module name: ucrtbase.dll, version: 10.0.14393.0, time stamp:
 0x57898db2
 Exception code: 0xc005
 Fault offset: 0x000b6d95
 Faulting process id: 0x2518
 Faulting application start time: 0x01d266e0af109346
 Faulting application path:
 C:\Users\***\.virtualenvs\***\Scripts\python.exe
 Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
 Report Id: b30fc25b-9183-4c8f-b01f-5fb5b71fddad
 Faulting package full name:
 Faulting package-relative application ID:
 }}}

 After several re-runs runserver works OK. I'm using Python 3.5.2 and
 Django 1.10.5.

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

Re: [Django] #27664: Manager.contribute_to_class() is called with abstract model rather than concrete model

2017-01-04 Thread Django

#27664: Manager.contribute_to_class() is called with abstract model rather than
concrete model
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Absent a patch or explanation of why the change is needed, I don't know
 what to do here. Feel free to investigate and offer a patch. I have a
 feeling that "fixing" this requires reintroducing the complexity that
 Loic's patch 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/067.a87f583e497a24f92a78cf6e248ba3b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27677: Disable savepoint support for MySQL NDB engine tables, and option to overwrite the default.

2017-01-04 Thread Django

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

Comment:

As Adam suggested, you can disable savepoints without patching Django by
writing a [https://www.youtube.com/watch?v=OCq2eUmrCfI custom database
backend]. This has the benefit that you won't need to wait several months
until the next version of Django is released. If you find you need other
database backend hooks that Django doesn't provide, feel free to let us
know.

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

Re: [Django] #27054: makemigrations tries to create django_migrations in external database

2017-01-04 Thread Django

#27054: makemigrations tries to create django_migrations in external database
-+
 Reporter:  Jim Nicholls |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham):

 I haven't used routers much myself, but I think the current structure
 provides enough flexibility that adding on "shortcuts" like that would
 only further complicate things.

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

Re: [Django] #27677: Disable savepoint support for MySQL NDB engine tables, and option to overwrite the default.

2017-01-04 Thread Django

Comment (by Alan Justino da Silva):

Replying to [comment:2 Adam Chainz]:
> I'm unsure to what lengths Django should go to support alternate
storage engines

I guess it is ok to just not disallow their use

> I'd suggest for the time making and testing a third party database
backend that overrides `uses_savepoints` (etc.), rather than changing
Django core directly right now, since we can't test it, and it doesn't
seem that popular.

Will it be better if the patch just allows the feature to be disabled,
with no explicit effort to detect the engine used? It would be enough for
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/065.b70a56109d5064557e930e117ce52ec7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27677: Disable savepoint support for MySQL NDB engine tables, and option to overwrite the default.

2017-01-04 Thread Django

Comment (by Adam Chainz):

I'm unsure to what lengths Django should go to support alternate storage
engines

NDB isn't just a storage engine - you need to use a different version of
MySQL (from Oracle) to use it. Also NDB cluster is just one of many
clustering database options for MySQL, some others being:

* [https://www.percona.com/software/mysql-database/percona-xtradb-cluster
Percona XtraDB Cluster] (XtraDB = InnoDB, should be less different)
* [https://mariadb.com/kb/en/mariadb/what-is-mariadb-galera-cluster/
MariaDB Galera Cluster] (Also uses XtraDB / InnoDB)

I'm afraid I don't have any experience with NDB, or any of the above. I
suspect there will be more issues rather than just the lack of savepoints;
e.g. the docs include a [https://dev.mysql.com/doc/refman/5.7/en/mysql-
cluster-ndb-innodb-engines.html table of differences between the NDB and
InnoDB storage engines] with many entries, and this isn't even where the
lack of savepoints is documented. Some suspicious entries I saw at a
glance: only READ-COMMITTED transaction isolation (pertinent to #27683)
and the difference in data types with 'large row support'.

I'd suggest for the time making and testing a third party database backend
that overrides `uses_savepoints` (etc.), rather than changing Django core
directly right now, since we can't test it, and it doesn't seem that
popular.

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

Re: [Django] #27054: makemigrations tries to create django_migrations in external database

2017-01-04 Thread Django

#27054: makemigrations tries to create django_migrations in external database
-+
 Reporter:  Jim Nicholls |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by MiddleFork):

 Replying to [comment:16 Tim Graham]:
 > You need to add an `allow_migrate()` method to your router.

 OK, I can see that now.

 Still, it's unfortunate that we need to identify
 read-only databases in this manner, which if I understand correctly is
 like this:

 {{{

 class MyRouter():
   def allow_migrate(self, db):
 if db in ['read_only0', 'read_only1',
 'another_read_only_database_with_a_very_long_name']:
   return False
 }}}


 Something like this might be fun:

 {{{
 DATABASES = {
 'default' : {
'HOST': 'localhost',
'NAME': 'database0' },
 'read_only': {
   'NAME': 'database1',
   'HOST': 'localhost',
   'OPTIONS':
 {'read_only': True,}

 }
 }
 }}}

 Then,
 {{{
 not DATABASES['default'].get('OPTIONS').get('read_only')
 }}}
 will return True,
 and
 {{{
 not DATABASES['read_only'].get('OPTIONS').get('read_only')
 }}}
 will return False,

 so back in makemigrations we can check:

 {{{
 # Non-default databases are only checked if database routers used.
 aliases_to_check = connections if settings.DATABASE_ROUTERS else
 [DEFAULT_DB_ALIAS]
 for alias in sorted(aliases_to_check):
 connection = connections[alias]
 if (connection.settings_dict['ENGINE'] !=
 'django.db.backends.dummy' and any(
 # At least one model must be migrated to the database.
 router.allow_migrate(connection.alias, app_label,
 model_name=model._meta.object_name)
 for app_label in consistency_check_labels
 for model in
 apps.get_app_config(app_label).get_models()
 # The database must not be read-only
 and not
 connections.settings_dict.get('OPTIONS').get('read_only')
 )):
 loader.check_consistent_history(connection)
 }}}

 
https://github.com/MiddleFork/django/commit/36641fca286a9687f6b1b4ff5605f2c0bc5565a2
 #diff-8eb3b5673aa9386f8fcb2cd99a8ebce3


 On further thought, the use of the term read_only is loaded and maybe
 OPTIONS['migratable'] would be preferable


 Anyway, it might be 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/078.c906ed19db85baa1b99f1c5a4e0d437a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27677: Disable savepoint support for MySQL NDB engine tables, and option to overwrite the default.

2017-01-04 Thread Django

#27677: Disable savepoint support for MySQL NDB engine tables, and option to
overwrite the default.
-+-
 Reporter:  Alan Justino da  |Owner:  nobody
  Silva  |
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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 Tim Graham):

 * cc: Adam Chainz (added)


Comment:

 I'm unsure to what lengths Django should go to support alternate storage
 engines. I'm not sure if it's possible to test NDB on our continuous
 integration infrastructure, for example.

 Adam, do you have any input?

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

Re: [Django] #27679: Document that empty formsets display min_num+extra forms (was: Empty formsets should display max(min_num, extra) rather than min_num+extra)

2017-01-04 Thread Django

#27679: Document that empty formsets display min_num+extra forms
--+
 Reporter:  Lorenzo Peña  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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 Tim Graham):

 * component:  Forms => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 Looks like this was [https://github.com/django/django/pull/2655#r12731342
 considered previously] and rejected due to backwards compatibility.
 Tentatively accepting as a documentation enhancement pending no further
 arguments to change the behavior.

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

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

Re: [Django] #27675: Django postgres JSONField encoding

2017-01-04 Thread Django

#27675: Django postgres JSONField encoding
-+-
 Reporter:  Hisham Waleed Karam  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.10
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  models JSONField | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 I can't reproduce the issue given the information provided.

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

Re: [Django] #27356: admin lookup_allowed incorrectly returns False for a nested reverse OneToOneField

2017-01-04 Thread Django

#27356: admin lookup_allowed incorrectly returns False for a nested reverse
OneToOneField
---+
 Reporter:  Tobias Krönke  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Anton Samarchyan):

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

Re: [Django] #27356: admin lookup_allowed incorrectly returns False for a nested reverse OneToOneField

2017-01-04 Thread Django

#27356: admin lookup_allowed incorrectly returns False for a nested reverse
OneToOneField
---+
 Reporter:  Tobias Krönke  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Anton Samarchyan):

 * cc: desecho@… (added)
 * version:  1.10 => master


Comment:

 I added a project to easily reproduce a problem. Admin credentials -
 admin/iaN4viph8653 .

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

Re: [Django] #27356: admin lookup_allowed incorrectly returns False for a nested reverse OneToOneField

2017-01-04 Thread Django

#27356: admin lookup_allowed incorrectly returns False for a nested reverse
OneToOneField
---+
 Reporter:  Tobias Krönke  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Anton Samarchyan):

 * Attachment "djtest.zip" 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.921b808af8bc40956454b395fc83759f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27054: makemigrations tries to create django_migrations in external database

2017-01-04 Thread Django

#27054: makemigrations tries to create django_migrations in external database
-+
 Reporter:  Jim Nicholls |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham):

 You need to add an `allow_migrate()` method to your router.

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

Re: [Django] #25417: Add a system check for an invalid default on a model field

2017-01-04 Thread Django

#25417: Add a system check for an invalid default on a model field
-+-
 Reporter:  André Avorio |Owner:  Simon
 |  Charette
 Type:  New feature  |   Status:  closed
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  decimal, | Triage Stage:  Ready for
  InvalidOperation, migrations   |  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I closed #27684 as a duplicate. It's a similar problem where a string
 (rather than `date`) was incorrectly assigned as the default for
 `DateField`.

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

Re: [Django] #27684: Migrations accept default value for DateField that are not portable to all backends

2017-01-04 Thread Django

* status: new => closed
* resolution: => duplicate
* component: Migrations => Database layer (models, ORM)

Comment:

As Avraham mentioned on the django-users thread, `DateField` is a
representation of `datetime.date`, so the `default` should be a `date`
object and not a string. I'm going to close this as a duplicate of #25417
since this is the essentially the same problem as reported there, just
applied to a different field.

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

Re: [Django] #27054: makemigrations tries to create django_migrations in external database

2017-01-04 Thread Django

#27054: makemigrations tries to create django_migrations in external database
-+
 Reporter:  Jim Nicholls |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by MiddleFork):

 #27110 breaks this fix in the case where a database is present in
 DATABASES but absent from DATABASE_ROUTERS.

 In spite of #27110 testing for DATABASE_ROUTERS, makemigrations still
 using the connections in django.db.utils.ConnectionHandler  (ie as
 populated from settings.DATABASES) rather than the routers in
 DATABASE_ROUTERS for the set of databases for which it attempts to prepare
 to migrate.

 This simplified example should result in makemigrations failing:

 {{{
 DATABASES = {
   'default': { ... }
   'read_only': { ... }
   }


 Class MyDefaultRouter():
class Meta:


 DATABASE_ROUTERS = ['MyDefaultRouter',]


 }}}

 As long as we explicitly specify our database by employing the
 .objects.using() syntax, the database need not be present in
 DATABASE_ROUTERS

 {{{
 class MyReadOnlyModel(models.Model):
   class Meta

 queryset = MyReadOnlyModel.objects.using('read_only').all()

 }}}

 so at line 109 of makemigrations the call to
 loader.check_consistent_history(connection) on our read-only database, and
 will again raise the applied_migrations / ensure_schema traceback

 {{{

 Traceback (most recent call last):
   File "manage.py", line 11, in 
 execute_from_command_line(sys.argv)
   File "/bigdata/django/bdp/bdpproj/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/bigdata/django/bdp/bdpproj/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/bigdata/django/bdp/bdpproj/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 294, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/bigdata/django/bdp/bdpproj/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 345, in execute
 output = self.handle(*args, **options)
   File "/bigdata/django/bdp/bdpproj/venv/lib/python2.7/site-
 packages/django/core/management/commands/makemigrations.py", line 109, in
 handle
 loader.check_consistent_history(connection)
   File "/bigdata/django/bdp/bdpproj/venv/lib/python2.7/site-
 packages/django/db/migrations/loader.py", line 276, in
 check_consistent_history
 applied = recorder.applied_migrations()
   File "/bigdata/django/bdp/bdpproj/venv/lib/python2.7/site-
 packages/django/db/migrations/recorder.py", line 65, in applied_migrations
 self.ensure_schema()
   File "/bigdata/django/bdp/bdpproj/venv/lib/python2.7/site-
 packages/django/db/migrations/recorder.py", line 59, in ensure_schema
 raise MigrationSchemaMissing("Unable to create the django_migrations
 table (%s)" % exc)
 django.db.migrations.exceptions.MigrationSchemaMissing: Unable to create
 the django_migrations table ((1142, "CREATE command denied to user
 'readonly_user'@'192.168.1.1' for table 'django_migrations'"))


 }}}

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

Re: [Django] #27658: collectstatic overwrites newer files in remote storage

2017-01-04 Thread Django

#27658: collectstatic overwrites newer files in remote storage
-+
 Reporter:  Paolo Dente  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  staticfiles  | 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:"da9b36c52d403a8de77682f4892d8890075f1289" da9b36c5]:
 {{{
 #!CommitTicketReference repository=""
 revision="da9b36c52d403a8de77682f4892d8890075f1289"
 [1.10.x] Fixed #27658 -- Prevented collectstatic from overwriting newer
 files in remote storages.

 Thanks revimi for the initial patch.

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

Re: [Django] #27658: collectstatic overwrites newer files in remote storage

2017-01-04 Thread Django

#27658: collectstatic overwrites newer files in remote storage
-+
 Reporter:  Paolo Dente  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  staticfiles  | 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:"c85831e4b7b5a7e4249df10327175b7251cb012d" c85831e4]:
 {{{
 #!CommitTicketReference repository=""
 revision="c85831e4b7b5a7e4249df10327175b7251cb012d"
 Fixed #27658 -- Prevented collectstatic from overwriting newer files in
 remote storages.

 Thanks revimi for the initial patch.
 }}}

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

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

Re: [Django] #27684: Migrations accept default value for DateField that are not portable to all backends

2017-01-04 Thread Django

#27684: Migrations accept default value for DateField that are not portable to 
all
backends
---+--
 Reporter:  voodoo-burger  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by voodoo-burger):

 Replying to [comment:1 Tim Graham]:
 > We tried to add a system check to validate model field defaults in
 #25417 but failed to do so due to backwards compatibility. I'm unsure if
 it's worth trying to make a similar change here given it will likely break
 backwards-compatibility for some users who may be using this technique and
 only care about supporting some databases.

 How about a warning then when someone uses a notation other than -MM-
 DD?

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

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

2017-01-04 Thread Django

#26099: Add a warning about import conflicts when auto-generating migrations
--+
 Reporter:  LucidComplex  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham):

 There could be more import conflicts than just one for the name "settings"
 so the approach should be more general. I'm not sure whether or not
 solving this is feasible and/or practical.

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

Re: [Django] #27587: Document str(QuerySet.query)

2017-01-04 Thread Django

#27587: Document str(QuerySet.query)
--+
 Reporter:  Peter Inglesby|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Mads Jensen):

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

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

2017-01-04 Thread Django

#26099: Add a warning about import conflicts when auto-generating migrations
--+
 Reporter:  LucidComplex  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Anton Samarchyan):

 * cc: desecho@… (added)


Comment:

 What if first it's going to check if there is an app called settings, then
 if there is it's going to choose the name django_settings and check if the
 app exists again (with the name django_settings), if it does, it's going
 to name it django_settings_settings for example and check again, etc. Does
 it sound good?

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

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

2017-01-04 Thread Django

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

Comment (by Tim Graham ):

 In [changeset:"8ea541e6a297d6bcdef233871a22b5cc99a0a527" 8ea541e]:
 {{{
 #!CommitTicketReference repository=""
 revision="8ea541e6a297d6bcdef233871a22b5cc99a0a527"
 Refs #2856 -- Removed redundant escaping in admin's "Perhaps it was
 deleted?" message.
 }}}

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

Re: [Django] #27684: Migrations accept default value for DateField that are not portable to all backends

2017-01-04 Thread Django

#27684: Migrations accept default value for DateField that are not portable to 
all
backends
---+--
 Reporter:  voodoo-burger  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 We tried to add a system check to validate model field defaults in #25417
 but failed to do so due to backwards compatibility. I'm unsure if it's
 worth trying to make a similar change here given it will likely break
 backwards-compatibility for some users who may be using this technique and
 only care about supporting some databases.

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

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

Re: [Django] #25417: Add a system check for an invalid default on a model field

2017-01-04 Thread Django

#25417: Add a system check for an invalid default on a model field
-+-
 Reporter:  André Avorio |Owner:  Simon
 |  Charette
 Type:  New feature  |   Status:  closed
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  decimal, | Triage Stage:  Ready for
  InvalidOperation, migrations   |  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 The decision to revert this was discussed on
 [https://groups.google.com/d/topic/django-
 developers/-E3b5DCtEp0/discussion django-developers].

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

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

[Django] #27684: Migrations accept default value for DateField that are not portable to all backends

2017-01-04 Thread Django

#27684: Migrations accept default value for DateField that are not portable to 
all
backends
-+
   Reporter:  voodoo-burger  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Migrations |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 This field:

 {{{
 activity_date = models.DateField('Datum', default='17/06/2017')
 }}}

 Results in this migration:


 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ('activities', '0006_auto_20161231_1703'),
 ]

 operations = [
 migrations.AlterField(
 model_name='activity',
 name='activity_date',
 field=models.DateField(default='17/06/2017',
 verbose_name='Datum'),
 ),
 ]
 }}}

 Which works fine on SQLite but gives this error on Postgres:


 {{{
 Operations to perform:
   Apply all migrations: activities, addressbook, admin, auth,
 contenttypes, sessions, users
 Running migrations:
   Applying activities.0007_auto_20170103_2309...Traceback (most recent
 call last):
   File "manage.py", line 22, in 
 execute_from_command_line(sys.argv)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/core/management/base.py", line 294, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/core/management/base.py", line 345, in execute
 output = self.handle(*args, **options)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/core/management/commands/migrate.py", line 204, in handle
 fake_initial=fake_initial,
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/migrations/executor.py", line 115, in migrate
 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/migrations/executor.py", line 145, in
 _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/migrations/executor.py", line 244, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/migrations/migration.py", line 129, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/migrations/operations/fields.py", line 204, in
 database_forwards
 schema_editor.alter_field(from_model, from_field, to_field)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/backends/base/schema.py", line 495, in alter_field
 old_db_params, new_db_params, strict)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/backends/postgresql/schema.py", line 117, in
 _alter_field
 new_db_params, strict,
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/backends/base/schema.py", line 578, in _alter_field
 new_default = self.effective_default(new_field)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/backends/base/schema.py", line 221, in
 effective_default
 default = field.get_db_prep_save(default, self.connection)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/models/fields/__init__.py", line 755, in
 get_db_prep_save
 prepared=False)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/models/fields/__init__.py", line 1280, in
 get_db_prep_value
 value = self.get_prep_value(value)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/models/fields/__init__.py", line 1275, in
 get_prep_value
 return self.to_python(value)
   File "/webapps/mzg/venv/lib/python3.5/site-
 packages/django/db/models/fields/__init__.py", line 1250, in to_python
 params={'value': value},
 django.core.exceptions.ValidationError: ["'17/06/2017' waarde heeft een
 ongeldige datumnotatie. Deze moet in de -MM-DD notatie opgegeven
 worden."]
 }}}

 The error says: "DATE" has an invalid date notation. It must be submitted
 as -MM-DD notation. Timezone/locale is Europe/Amsterdam in case that
 makes a difference.

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

2017-01-04 Thread Django

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

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


Comment:

 Don't forget to uncheck the "needs improvement" flags on the ticket, else
 it won't appear 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/066.04873d1efeab0aa6d95b39ba451878f0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27672: Trouble saving specificly shaped GeometryCollection to spatialite backend

2017-01-04 Thread Django

#27672: Trouble saving specificly shaped GeometryCollection to spatialite 
backend
+--
 Reporter:  Tim Sheerman-Chase  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  1.10
 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 Tim Graham):

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


Comment:

 Please reopen if further investigation concludes that Django is at fault.

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

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

2017-01-04 Thread Django

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

 * needs_docs:  1 => 0
 * type:  New feature => Cleanup/optimization
 * severity:  Release blocker => Normal
 * 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/063.74602cf9c03881687b1ee82a7438b260%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

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

2017-01-04 Thread Django

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

 * stage:  Unreviewed => Someday/Maybe


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

Re: [Django] #27434: Crashes during form validation when Model validation raises ValidationErrors for fields not in the current form

2017-01-04 Thread Django

#27434: Crashes during form validation when Model validation raises
ValidationErrors for fields not in the current form
-+-
 Reporter:  Matthias Kestenholz  |Owner:  Matthias
 |  Kestenholz
 Type:  Bug  |   Status:  assigned
Component:  Forms|  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 Matthias Kestenholz):

 * needs_better_patch:  1 => 0


Comment:

 I hope the patch won't need further improvement, removing the flag for
 now. 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/067.da8a724707abf1edb1467644f023ad48%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15035: collectstatic does not support remote backends that implement modified_time

2017-01-04 Thread Django

#15035: collectstatic does not support remote backends that implement 
modified_time
+-
   Reporter:  Ben Davis |Owner:  Jannis Leidel
   Type:|   Status:  closed
  Component:  Contrib apps  |  Version:  1.3-beta
   Severity:|   Resolution:  fixed
   Keywords:| Triage Stage:  Accepted
  Has patch:  1 |  Needs documentation:  0
Needs tests:  0 |  Patch needs improvement:  0
+-

Comment (by Tim Graham ):

 In [changeset:"bff4abacad48eba715be64d7b15582d15bdc1fca" bff4abac]:
 {{{
 #!CommitTicketReference repository=""
 revision="bff4abacad48eba715be64d7b15582d15bdc1fca"
 Refs #15035 -- Corrected a bug and improved comments for a staticfiles
 test.
 }}}

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

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

Re: [Django] #25707: Use py.test for internal testing

2017-01-04 Thread Django

#25707: Use py.test for internal testing
-+-
 Reporter:  Olivier Le Thanh |Owner:  nobody
  Duong  |
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Asif Saifuddin Auvi):

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

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

2017-01-04 Thread Django

#27680: Recommend ccbv.co.uk in class-based views docs
--+
 Reporter:  James Pic |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by James Pic):

 ccbv is not "required", per say, but it's really well done and helpful
 indeed. This ticket is not about rewriting the cbv documentation, it's
 about providing users with ccbv.

 If you think its worth talking about how we could make the class based
 views documentation better then feel free to start a thread on the django-
 developer mailing list.

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

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

2017-01-04 Thread Django

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

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

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

2017-01-04 Thread Django

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

Comment (by Aymeric Augustin):

 Like I said in earlier discussions, I'm in favor of doing this change.

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

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

45 matches

Mail list logo