Re: [Django] #27795: Audit force_text invocations

[Django]

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  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 Carlton Gibson ):

 In [changeset:"6a039800db7ce4aa4c1afecd26791c43ddde8920" 6a039800]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a039800db7ce4aa4c1afecd26791c43ddde8920"
 Refs #27795 -- Replaced force_bytes() usage in django.core.cache.
 }}}

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

Re: [Django] #29102: ImproperlyConfigured URLConf on certain requests (unknown cause)

[Django]

#29102: ImproperlyConfigured URLConf on certain requests (unknown cause)
-+-
 Reporter:  scone|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  URLResolver, | Triage Stage:
  urlconf|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by scone:

Old description:

> I haven't been able to recreate the bug, but I receive the error in my
> django.error log several times a day. The requests are usually for my
> index "/" page or my details page "'/details" (url patterns given
> below).
>
> When I revisit the URL in the log that caused the error, it works fine.
> The error shows that "patterns" is a module in these cases and it doesn't
> have "urlpatterns" as an attribute.
>

> I'm using Python 3.5.2 with Django 2.0. The codebase was original written
> with Django 1.6 I believe. I recently migrated to 2.0 and that is when I
> noticed the issue.
>
> I modified django/urls/resolvers.py to log the 'patterns' variable and
> most of the time I receive this list:
>

> {{{
> [ (admin:admin) 'admin/'>,
>  /details' [name='details']>,
>  ,
>  ,
>  ,
>  ,
>  ,
>  ,
>  ]
> }}}
>

> Here is my urls file:
> app_name/urls.py
>

> {{{
> from django.urls import path, re_path
> from django.contrib import admin
>
> from app_name import views
> from app_name.result_view import SubmissionDetailView
>

>
> handler404 = 'app_name.views.not_found_view'
>
> urlpatterns = [
> path('admin/', admin.site.urls),
> path('/details', SubmissionDetailView.as_view(),
> name='details'),
> path('check/', views.check, name='check'),
> path('logout/', views.logout_view, name='logout'),
> path('search/', views.search, name='search'),
> path('features/', views.features, name='features'),
> path('terms-of-service/', views.terms, name='terms'),
> path('privacy-policy/', views.privacy, name='privacy'),
> path('', views.index, name='index'),
> ]
> }}}
>

>
> Exception
>

> {{{
> django.core.exceptions.ImproperlyConfigured: The included URLconf
> 'app_name.urls' does not appear to have any patterns in it.
> If you see valid patterns in the file then the issue is probably caused
> by a circular import.
> Traceback
>
> /opt/web/env/lib/python3.5/site-packages/django/urls/resolvers.py in
> url_patterns
> iter(patterns)
> Local Vars
>
> VariableValue
> msg   ("The included URLconf '{name}' does not appear to have any
> patterns in it. If "
>  'you see valid patterns in the file then the issue is probably caused by
> a '
>  'circular import.')
> patterns '/opt/web/app/my_site/app_name/urls.py'>
> self
>
> During handling of the above exception ('module' object is not iterable),
> another exception occurred:
>
> /opt/web/env/lib/python3.5/site-
> packages/django/core/handlers/exception.py in inner
> response = get_response(request)
> [SNIP]
>
> /opt/web/env/lib/python3.5/site-packages/django/urls/base.py in resolve
> return get_resolver(urlconf).resolve(path)
> Local Vars
>
> VariableValue
> path  '/4567/details'
> urlconf   'app_name.urls'
>
> /opt/web/env/lib/python3.5/site-packages/django/urls/resolvers.py in
> resolve
> for pattern in self.url_patterns:
> Local Vars
>
> VariableValue
> args ()
> kwargs   {}
> match('4567/details', (), {})
> new_path '4567/details'
> path '/4567/details'
> self 
> tried[]
>
> /opt/web/env/lib/python3.5/site-packages/django/utils/functional.py in
> __get__
> res = instance.__dict__[self.name] = self.func(instance)
> Local Vars
>
> VariableValue
> cls 
> instance
> self 0x7f06c7d2c550>
>
> /opt/web/env/lib/python3.5/site-packages/django/urls/resolvers.py in
> url_patterns
> raise
> ImproperlyConfigured(msg.format(name=self.urlconf_name))
> Local Vars
>
> VariableValue
> msg("The included URLconf '{name}' does not appear to have any
> patterns in it. If "
>  'you see valid patterns in the file then the issue is probably caused by
> a '
>  'circular import.')
> patterns '/opt/web/app/my_site/app_name/urls.py'>
> self
> }}}
>
> I changed my reverse() calls to reverse_lazy(), just in case it's caused
> by a reverse call happening before urls_patterns are loaded. I don't know
> of any cases where this would happen in my app though.
>
> 99% of the time, this isn't an issue, but it does occur daily and I would
> like to patch

[Django] #29102: ImproperlyConfigured URLConf on certain requests (unknown cause)

[Django]

#29102: ImproperlyConfigured URLConf on certain requests (unknown cause)
-+-
   Reporter:  scone  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core   |Version:  2.0
  (URLs) |   Keywords:  URLResolver,
   Severity:  Normal |  urlconf
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I haven't been able to recreate the bug, but I receive the error in my
 django.error log several times a day. The requests are usually for my
 index "/" page or my details page "'/details" (url patterns given
 below).

 When I revisit the URL in the log that caused the error, it works fine.
 The error shows that "patterns" is a module in these cases and it doesn't
 have "urlpatterns" as an attribute.


 I'm using Python 3.5.2 with Django 2.0. The codebase was original written
 with Django 1.6 I believe. I recently migrated to 2.0 and that is when I
 noticed the issue.

 I modified django/urls/resolvers.py to log the 'patterns' variable and
 most of the time I receive this list:


 {{{
 [ (admin:admin) 'admin/'>,
  /details' [name='details']>,
  ,
  ,
  ,
  ,
  ,
  ,
  ]
 }}}


 Here is my urls file:
 app_name/urls.py


 {{{
 from django.urls import path, re_path
 from django.contrib import admin

 from app_name import views
 from app_name.result_view import SubmissionDetailView



 handler404 = 'app_name.views.not_found_view'

 urlpatterns = [
 path('admin/', admin.site.urls),
 path('/details', SubmissionDetailView.as_view(),
 name='details'),
 path('check/', views.check, name='check'),
 path('logout/', views.logout_view, name='logout'),
 path('search/', views.search, name='search'),
 path('features/', views.features, name='features'),
 path('terms-of-service/', views.terms, name='terms'),
 path('privacy-policy/', views.privacy, name='privacy'),
 path('', views.index, name='index'),
 ]
 }}}



 Exception


 {{{
 django.core.exceptions.ImproperlyConfigured: The included URLconf
 'app_name.urls' does not appear to have any patterns in it.
 If you see valid patterns in the file then the issue is probably caused by
 a circular import.
 Traceback

 /opt/web/env/lib/python3.5/site-packages/django/urls/resolvers.py in
 url_patterns
 iter(patterns)
 Local Vars

 VariableValue
 msg   ("The included URLconf '{name}' does not appear to have any
 patterns in it. If "
  'you see valid patterns in the file then the issue is probably caused by
 a '
  'circular import.')
 patterns
 self

 During handling of the above exception ('module' object is not iterable),
 another exception occurred:

 /opt/web/env/lib/python3.5/site-packages/django/core/handlers/exception.py
 in inner
 response = get_response(request)
 [SNIP]

 /opt/web/env/lib/python3.5/site-packages/django/urls/base.py in resolve
 return get_resolver(urlconf).resolve(path)
 Local Vars

 VariableValue
 path  '/4567/details'
 urlconf   'app_name.urls'

 /opt/web/env/lib/python3.5/site-packages/django/urls/resolvers.py in
 resolve
 for pattern in self.url_patterns:
 Local Vars

 VariableValue
 args ()
 kwargs   {}
 match('4567/details', (), {})
 new_path '4567/details'
 path '/4567/details'
 self 
 tried[]

 /opt/web/env/lib/python3.5/site-packages/django/utils/functional.py in
 __get__
 res = instance.__dict__[self.name] = self.func(instance)
 Local Vars

 VariableValue
 cls 
 instance
 self

 /opt/web/env/lib/python3.5/site-packages/django/urls/resolvers.py in
 url_patterns
 raise ImproperlyConfigured(msg.format(name=self.urlconf_name))
 Local Vars

 VariableValue
 msg("The included URLconf '{name}' does not appear to have any
 patterns in it. If "
  'you see valid patterns in the file then the issue is probably caused by
 a '
  'circular import.')
 patterns
 self
 }}}

 I changed my reverse() calls to reverse_lazy(), just in case it's caused
 by a reverse call happening before urls_patterns are loaded. I don't know
 of any cases where this would happen in my app though.

 99% of the time, this isn't an issue, but it does occur daily and I would
 like to patch things up!

-- 
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 i

Re: [Django] #28794: tx_isolation deprecation warning with MySQL 5.7.20+

[Django]

#28794: tx_isolation deprecation warning with MySQL 5.7.20+
-+-
 Reporter:  JC   |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql| 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):

 I think the warning comes from MySQL itself and it's passed on through
 MySQLdb/mysqlclient. This may do the trick to suppress it:
 {{{
 from warnings import filterwarnings
 import MySQLdb as Database
 filterwarnings('ignore', category=Database.Warning)
 }}}

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

Re: [Django] #28794: tx_isolation deprecation warning with MySQL 5.7.20+

[Django]

#28794: tx_isolation deprecation warning with MySQL 5.7.20+
-+-
 Reporter:  JC   |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql| 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 David Wasylciw):

 Replying to [comment:8 Tim Graham]:
 > It doesn't qualify for a backport per our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy]. 1.11 only receives
 security and data loss fixes.

 Fair enough! Was just hoping that a patch would be a better way of
 supressing the constant depreciation warnings, wish the MySQL backend had
 the same silent depreciation warnings as everything else now has.

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

Re: [Django] #29101: Beautify Django Test Output

[Django]

#29101: Beautify Django Test Output
---+--
 Reporter:  Rich Jones |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  2.0
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  testing, ux| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by Tim Graham):

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


Comment:

 Colorized test results is tracked in #22449.

 As for the other suggestions, it would be better to have smaller, more
 focused tickets that are easily actionable. I'm going to close this one
 but feel free to open some others with that in mind.

 It looks like you may not have tried using the
 [https://docs.djangoproject.com/en/dev/ref/django-admin/#cmdoption-
 verbosity --verbosity] option with the `test` command.

 Also, I know some Django developers use `pytest` rather than the default
 Django test runner. I haven't used it myself but that may provide some of
 what you seek. It would be nice not to duplicate work.

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

Re: [Django] #29100: Give useful feedback to developer if a bad url is used for a static file

[Django]

#29100: Give useful feedback to developer if a bad url is used for a static file
-+-
 Reporter:  Håkan Lövdahl|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  2.0
  uploads/storage|
 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):

 What are the steps to reproduce the error?

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

Re: [Django] #29101: Beautify Django Test Output

[Django]

#29101: Beautify Django Test Output
---+--
 Reporter:  Rich Jones |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  2.0
 Severity:  Normal |   Resolution:
 Keywords:  testing, ux| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by Rich Jones):

 * component:  Uncategorized => Testing framework


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

[Django] #29101: Beautify Django Test Output

[Django]

#29101: Beautify Django Test Output
-+-
   Reporter:  Rich Jones |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Uncategorized  |Version:  2.0
   Severity:  Normal |   Keywords:  testing, ux
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+-
 ''This is a feature request!''

 There has been a lot of fantastic work in Django 2.0 towards making the
 default interfaces web and command line interfaces more beautiful.
 Excellent!

 Unfortunately, it seems like this work has not been extended to the
 "manage.py test" command, which still has very confusing and overwhelming
 output!

 I'm sure many of you have, like me, stared at the standard output (err?)
 of a `test` command running through a complicated and conditional CI
 system and wondered.. okay, but which test is this currently running? In
 which module? Is that supposed to be included? Which tests got skipped?
 Perhaps most annoyingly, especially for new developers, normal print()
 statements don't appear in test output.

 I also now make extensive use of the `tag` feature introduced in 1.10, but
 there is no feedback in the CLI about which tags are being actively
 included or excluded,  how many total were skipped, etc.

 Finally - there is no color in the output! Color has been added to great
 effect to express success and error states for other manage.py commands -
 why not for tests too? It'd be great to use green to indicate a passing
 test, red to indicate a failed test, and yellow to indicate a skipped
 test.

 Currently, the experience is something like:

 {{{
 $ docker run \
--add-host=database:$DB_HOST_IP \
--add-host=nomad:$NOMAD_HOST_IP \
--env-file workers/environments/test \
--volume $volume_directory:/home/user/data_store \
--link drdb:postgres \
--link nomad:nomad \
-i dr_worker_tests python3 manage.py test "$@" -- exclude-tag=slow
 --exclude-tag=star --no-input

 Successfully tagged dr_worker_tests:latest
 Creating test database for alias 'default'...
 System check identified no issues (0 silenced).
 2018-02-01 21:15:48,342 local/MainProcess
 data_refinery_workers.downloaders.array_express ERROR [downloader_job: 1]:
 A Batch's file doesn't have the same download URL as the other batches'
 files.
 [ .. literally thousands of log statements .. ]
 [ .. literally thousands of log statements .. ]
 [ .. literally thousands of log statements .. ]
 [ .. literally thousands of log statements .. ]
 [ .. literally thousands of log statements .. ]
 --
 Ran 39 tests in 474.636s

 OK
 Destroying test database for alias 'default'...
 }}}

 It would be so, so much nicer if the experience was something like:
 {{{
 $ docker run \
--add-host=database:$DB_HOST_IP \
--add-host=nomad:$NOMAD_HOST_IP \
--env-file workers/environments/test \
--volume $volume_directory:/home/user/data_store \
--link drdb:postgres \
--link nomad:nomad \
-i dr_worker_tests python3 manage.py test "$@" -- exclude-tag=slow
 --exclude-tag=slower --no-input

 Starting tests, excluding [slow, slower].
 Running: test_download_file
 (data_refinery_workers.downloaders.test_sra.DownloadSraTestCase)
 --
 [ .. Related log and print statements .. ]
 **OK!**

 Running: test_download_other_file
 (data_refinery_workers.downloaders.test_sra.DownloadSraTestCase)
 --
 [ .. Related log and print statements .. ]
 **OK!**

 Skipping: super_long_test
 (data_refinery_workers.downloaders.test_sra.DownloadSraTestCase)
 Skipping: super_duper_long_test
 (data_refinery_workers.downloaders.test_sra.DownloadSraTestCase)
 Running: final_test
 (data_refinery_workers.downloaders.test_sra.DownloadSraTestCase)
 --
 [ .. Related log and print statements .. ]
 **OK!**

 --
 Ran **39** tests in **7 minutes, 54 seconds**. Skipped **2** tests.
 **100%** success rate, great job!
 }}}

 Basically, turn what is currently just a massive, unintelligible wall of
 unformatted text into something that can be easily parsed and understood
 at a glance by a human.

 A bonus would be to suppress unnecessary output (ex, "Destroying test
 database for alias 'default'..." when it's default), include more
 statistical and informative output, and use colorization and gen

Re: [Django] #29100: Give useful feedback to developer if a bad url is used for a static file

[Django]

#29100: Give useful feedback to developer if a bad url is used for a static file
-+-
 Reporter:  Håkan Lövdahl|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  2.0
  uploads/storage|
 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 Håkan Lövdahl):

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

[Django] #29100: Give useful feedback to developer if a bad url is used for a static file

[Django]

#29100: Give useful feedback to developer if a bad url is used for a static file
+
   Reporter:  Håkan Lövdahl |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  File uploads/storage  |Version:  2.0
   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 |
+
 in django/core/handlers/base.py there is a problem.
 Sometimes when using the statichandler it throws an exception without any
 useful information.
 I would like to propose an update the BaseHandler class

 {{{#!python
 def get_response(self, request):
 """Return an HttpResponse object for the given HttpRequest."""
 # Setup default url resolver for this thread
 set_urlconf(settings.ROOT_URLCONF)

 if self._middleware_chain is None:
 if self.__class__.__name__ == 'StaticFilesHandler':
 uri = '%s' % (request.get_full_path() )
 raise ValueError('Bad path for static file: %s' % uri)
 }}}

 This would help for keeping the test-outputs nice and clean.

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

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

Re: [Django] #25582: Add a way to build URLs with query strings

[Django]

#25582: Add a way to build URLs with query strings
+
 Reporter:  Thomas Güttler  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  Core (URLs) |  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 Ning):

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

Re: [Django] #10941: Add a templatetag to generate querystrings

[Django]

#10941: Add a templatetag to generate querystrings
-+
 Reporter:  Ben Spaulding|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  pagination   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Ning):

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

Re: [Django] #29099: Save the last selected version of the docs

[Django]

#29099: Save the last selected version of the docs
---+--
 Reporter:  Dan J Strohl   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Documentation  |  Version:  2.0
 Severity:  Normal |   Resolution:  invalid
 Keywords:  documentation  | 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:

 This suggestion would go to [https://github.com/django/djangoproject.com/
 the issue tracker for the djangoproject.com website]. This isn't the first
 time someone proposed the idea, but the implementation isn't
 straightforward. For example, pages are sometimes moved or removed from
 the documentation so there isn't a clean mapping to do redirects from one
 version to another. All in all, I feel it will be more confusing than
 helpful. If you know of any existing websites that do this well, we could
 take a look.

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

[Django] #29099: Save the last selected version of the docs

[Django]

#29099: Save the last selected version of the docs
-+---
   Reporter:  Dan J Strohl   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Documentation  |Version:  2.0
   Severity:  Normal |   Keywords:  documentation
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
 save the last selected version of the docs in a cookie so when I return,
 by default , it shows the version I am most probably using instead of the
 latest version.

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

[Django] #29098: Allow assertRedirects to handle regex matches.

[Django]

#29098: Allow assertRedirects to handle regex matches.
-+-
   Reporter:  Dan J  |  Owner:  nobody
  Strohl |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Testing|Version:  1.11
  framework  |
   Severity:  Normal |   Keywords:  unittest redirect
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 or, perhaps, allow it to use the patterns from the url's file.  Either
 way, the issue is that I have a view that gets a request, looks at it, and
 redirects it to a url such as /labs/12345/running, or /labs/4567/start.
 this is a similar pattern to what is recommended and used in the admin, so
 I don't think I am doing something weird here, but I may not know what the
 redirect url will look like before I send the request (if I am sending
 something like /labs/new, and it returns /labs/12345 for example).

 as a hack, I did this:
 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 def fix_response_for_test(response, re_pattern, replace, count=0,
 flags=0):

 if hasattr(response, 'redirect_chain'):
 url, status_code = response.redirect_chain[-1]

 tmp_replaced = re.search(re_pattern, url, flags=flags)
 new_url = re.sub(re_pattern, replace, url, count=count,
 flags=flags)

 # print('redirect - new: %s' % new_url)

 response.redirect_chain[-1] = (new_url, status_code)

 else:
 # Not a followed redirect
 url = response.url
 scheme, netloc, path, query, fragment = urlsplit(url)

 # Prepend the request path to handle relative path redirects.
 if not path.startswith('/'):
 url = urljoin(response.request['PATH_INFO'], url)

 tmp_replaced = re.search(re_pattern, url, flags=flags)
 new_url = re.sub(re_pattern, replace, url, count=count,
 flags=flags)

 # print('no redirected - new: %s' % new_url)

 response['Location'] = new_url

 return tmp_replaced.group(0)
   }}}
 }}}

 and is run like this:

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python

 session_id = fix_response_for_test(response, UUID_REGEX, '')

 redirect_url = '/lab//error/'

 with self.subTest('%s - response url' % name):
 self.assertRedirects(response, redirect_url,
 fetch_redirect_response=False, msg_prefix=tmp_msg)
 test_session = Sessions.objects.get(session_id=session_id)
 # do more testing on the session object to make sure it was
 created correctly.
   }}}
 }}}

 The returning the pulled content is nice, but probably not required as I
 COULD simply build two tests, one to check the redirect, and another to
 test the actual session object.

 If I had my druthers, I would love to see something like:

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python

 args_obj=None
 self.assertRedirects(response, r'/labs/(?P.+)/(.+)',
 get_args=args_obj)

 # assuming this passes the assertion, args_obj then would ==
 # args_obj = {
 #'args': ['list of un-named items'],
 #'kwargs': {dict of kwargs}
   }}}
 }}}

 This coudl also be approached by adding the ability to get this kind of
 thing directly from the response object, along the lines of:
 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python

 (assuming the request was '/labs/12344/test_page
 > my_response.seed_url()
 ' '//labs//(?P.+)//(.+)'  # which could then be matched in a
 redirect url match.
 > my_response.url_params(1)
 'test_page'
 > my_response.url_params('foobar')
 '12344'

   }}}
 }}}

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

Re: [Django] #23577: Rename operations should rename indexes, constraints, sequences and triggers named after their former value

[Django]

#23577: Rename operations should rename indexes, constraints, sequences and
triggers named after their former value
-+
 Reporter:  Chris Woytowitz  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Migrations   |  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 Ryan Hiebert):

 * cc: Ryan Hiebert (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/068.4747f8842d21f3451745ce42860e7df6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28645: AuthenticationForm's inactive user error isn't raised when using ModelBackend

[Django]

#28645: AuthenticationForm's inactive user error isn't raised when using
ModelBackend
-+-
 Reporter:  Guilherme Junqueira  |Owner:
 |  shangdahao
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  2.1  | 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):

 * Attachment "28645-jc.diff" 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/068.6c3fd9fe474a52303ef92ed0d14338d5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28645: AuthenticationForm's inactive user error isn't raised when using ModelBackend

[Django]

#28645: AuthenticationForm's inactive user error isn't raised when using
ModelBackend
-+-
 Reporter:  Guilherme Junqueira  |Owner:
 |  shangdahao
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  2.1  | 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):

 * keywords:   => 2.1
 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>


Comment:

 Reopening since the fix had to be reverted. We'll try to develop a
 solution for Django 2.1. Probably the solution will be too invasive to
 backport to the stable branches.

 In a mail to the security mailing list, Jack Cushman suggested:

  It's desirable for auth backends to enforce rules like “no inactive
 users” when supplied with otherwise-correct credentials – that’s more of a
 backend concern than a display concern, and forms shouldn’t be required to
 enforce it. But it is desirable for auth forms to show custom error
 messages when an auth backend rejects a user, if and only if the user
 supplied correct credentials. The ideal way to solve both problems would
 be for auth backends to return a tuple of `(user or None,
 custom_error_code or None)`, but that would break backwards compatibility.
 \\ \\
  So, can we let auth backends return custom error codes with backwards
 compatibility? \\ \\
  Attached is an untested patch that hopefully does that, by adding an
 authenticate_with_error_code method that backends can optionally implement
 and forms can optionally consume. I think this is a good angle on the
 problem – it cleans up the can of worms with displaying custom errors, and
 also totally avoids dealing with attacker-submitted data after credentials
 fail to validate, which is key to avoiding any subtle security issues.

 I'll attach the patch, but I haven't evaluated it in much detail.

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

Re: [Django] #27795: Audit force_text invocations

[Django]

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  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 Tim Graham ):

 In [changeset:"16c5a334ff3ad9d8b3cd1314562c7af20a2a7c7d" 16c5a334]:
 {{{
 #!CommitTicketReference repository=""
 revision="16c5a334ff3ad9d8b3cd1314562c7af20a2a7c7d"
 Refs #27795 -- Replaced force_text/bytes() with decode()/encode() in
 password hashers.
 }}}

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

Re: [Django] #29029: Django 1.8.18 admin uses jquery version with security issues

[Django]

#29029: Django 1.8.18 admin uses jquery version with security issues
-+--
 Reporter:  Michael Clagett  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--

Comment (by Tim Graham):

 Correct, and doing a major jQuery version upgrade on the stable releases
 is too risky, I think.

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

Re: [Django] #8851: Add a default option to list_filter in the admin interface

[Django]

#8851: Add a default option to list_filter in the admin interface
-+-
 Reporter:  Riskable |Owner:  Harro
 |
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  admin, list_filter,  | Triage Stage:  Accepted
  default|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Harro):

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


Comment:

 As said, there is a way to do this with a documented feature, so nothing
 to fix.

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

Re: [Django] #28645: AuthenticationForm's inactive user error isn't raised when using ModelBackend

[Django]

#28645: AuthenticationForm's inactive user error isn't raised when using
ModelBackend
-+-
 Reporter:  Guilherme Junqueira  |Owner:
 |  shangdahao
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.11
 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:"57b95fedad5e0b83fc9c81466b7d1751c6427aae" 57b95fed]:
 {{{
 #!CommitTicketReference repository=""
 revision="57b95fedad5e0b83fc9c81466b7d1751c6427aae"
 [1.11.x] Fixed CVE-2018-6188 -- Fixed information leakage in
 AuthenticationForm.

 Reverted 359370a8b8ca0efe99b1d4630b291ec060b69225 (refs #28645).

 This is a security fix.
 }}}

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

Re: [Django] #28645: AuthenticationForm's inactive user error isn't raised when using ModelBackend

[Django]

#28645: AuthenticationForm's inactive user error isn't raised when using
ModelBackend
-+-
 Reporter:  Guilherme Junqueira  |Owner:
 |  shangdahao
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.11
 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:"c37bb28677295f6edda61d8ac461014ef0d3aeb2" c37bb286]:
 {{{
 #!CommitTicketReference repository=""
 revision="c37bb28677295f6edda61d8ac461014ef0d3aeb2"
 [2.0.x] Fixed CVE-2018-6188 -- Fixed information leakage in
 AuthenticationForm.

 Reverted 359370a8b8ca0efe99b1d4630b291ec060b69225 (refs #28645).

 This is a security fix.
 }}}

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

Re: [Django] #28645: AuthenticationForm's inactive user error isn't raised when using ModelBackend

[Django]

#28645: AuthenticationForm's inactive user error isn't raised when using
ModelBackend
-+-
 Reporter:  Guilherme Junqueira  |Owner:
 |  shangdahao
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.11
 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:"af33fb250e9847f1ca8c0ba0d72671d76659704f" af33fb25]:
 {{{
 #!CommitTicketReference repository=""
 revision="af33fb250e9847f1ca8c0ba0d72671d76659704f"
 Fixed CVE-2018-6188 -- Fixed information leakage in AuthenticationForm.

 Reverted 359370a8b8ca0efe99b1d4630b291ec060b69225 (refs #28645).

 This is a security fix.
 }}}

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

Re: [Django] #29029: Django 1.8.18 admin uses jquery version with security issues

[Django]

#29029: Django 1.8.18 admin uses jquery version with security issues
-+--
 Reporter:  Michael Clagett  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--

Comment (by Louis-Dominique Dubeau):

 There is also an XSS vulnerability
 (https://nvd.nist.gov/vuln/detail/CVE-2015-9251) present in all jQuery
 versions prior to 3.x. If I'm reading Django's git logs correctly,
 `master` contains jQuery 3.x but no version of Django with jQuery 3.x has
 been released yet. So all released versions are at risk.

 Even if Django's own code does not make use of the vulnerable functions,
 it remains that:

 1. Developers basing their sites on Django and customizing their admin
 interface use the jQuery shipped with Django.

 2. 3rd party libraries that augment the admin interface also use the
 jQuery that is shipped with Django.

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

Re: [Django] #29094: ForeignKeyRawIdWidget.label_and_url_for_value does not catch UUIDField ValidationError

[Django]

#29094: ForeignKeyRawIdWidget.label_and_url_for_value does not catch UUIDField
ValidationError
---+--
 Reporter:  Carel Burger   |Owner:  Tim Graham
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"1c9233b1b9f903e4e2cb20a724e8c22aee4aacb2" 1c9233b1]:
 {{{
 #!CommitTicketReference repository=""
 revision="1c9233b1b9f903e4e2cb20a724e8c22aee4aacb2"
 [1.11.x] Fixed #29094 -- Fixed crash when entering an invalid uuid in
 ModelAdmin.raw_id_fields.

 Regression in 2f9861d823620da7ecb291a8f005f53da12b1e89.

 Thanks Carel Burger for the report and fix.

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

Re: [Django] #29097: Migrations using MySQL fail for constraints using composite indexes

[Django]

#29097: Migrations using MySQL fail for constraints using composite indexes
-+-
 Reporter:  geertjanvdk  |Owner:  Basu
 |  Dubey
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  introspection mysql  | Triage Stage:  Accepted
  migration index constraint |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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

Re: [Django] #29097: Migrations using MySQL fail for constraints using composite indexes

[Django]

#29097: Migrations using MySQL fail for constraints using composite indexes
-+-
 Reporter:  geertjanvdk  |Owner:  basu96
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  introspection mysql  | Triage Stage:
  migration index constraint |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by basu96):

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

Re: [Django] #29094: ForeignKeyRawIdWidget.label_and_url_for_value does not catch UUIDField ValidationError

[Django]

#29094: ForeignKeyRawIdWidget.label_and_url_for_value does not catch UUIDField
ValidationError
---+--
 Reporter:  Carel Burger   |Owner:  Tim Graham
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"1bd45e24584286075f4ff6cbeff2437c77e2c762" 1bd45e2]:
 {{{
 #!CommitTicketReference repository=""
 revision="1bd45e24584286075f4ff6cbeff2437c77e2c762"
 [2.0.x] Fixed #29094 -- Fixed crash when entering an invalid uuid in
 ModelAdmin.raw_id_fields.

 Regression in 2f9861d823620da7ecb291a8f005f53da12b1e89.

 Thanks Carel Burger for the report and fix.

 Backport of 552abffab16cbdff571486b683e7e7ef12e46066 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/065.5d47119a1e1c75d3202f7c7a91be111d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29094: ForeignKeyRawIdWidget.label_and_url_for_value does not catch UUIDField ValidationError

[Django]

#29094: ForeignKeyRawIdWidget.label_and_url_for_value does not catch UUIDField
ValidationError
---+--
 Reporter:  Carel Burger   |Owner:  Tim Graham
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"552abffab16cbdff571486b683e7e7ef12e46066" 552abffa]:
 {{{
 #!CommitTicketReference repository=""
 revision="552abffab16cbdff571486b683e7e7ef12e46066"
 Fixed #29094 -- Fixed crash when entering an invalid uuid in
 ModelAdmin.raw_id_fields.

 Regression in 2f9861d823620da7ecb291a8f005f53da12b1e89.

 Thanks Carel Burger for the report and fix.
 }}}

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

Re: [Django] #28794: tx_isolation deprecation warning with MySQL 5.7.20+

[Django]

#28794: tx_isolation deprecation warning with MySQL 5.7.20+
-+-
 Reporter:  JC   |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql| 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):

 It doesn't qualify for a backport per our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy]. 1.11 only receives
 security and data loss fixes.

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

Re: [Django] #29000: RenameModel does not rename M2M column when run after AlterField/RenameField

[Django]

#29000: RenameModel does not rename M2M column when run after
AlterField/RenameField
-+
 Reporter:  David Nelson Adamec  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  2.0
 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 shangdahao):

 * status:  assigned => new
 * owner:  shangdahao => (none)


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

[Django] #29097: Migrations using MySQL fail for constraints using composite indexes

[Django]

#29097: Migrations using MySQL fail for constraints using composite indexes
-+-
   Reporter: |  Owner:  nobody
  geertjanvdk|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|   Keywords:  introspection mysql
   Severity:  Normal |  migration index constraint
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 When running migrations which create (unique) composite indexes, the MySQL
 introspection fails to get the correct index:

 ValueError: Found wrong number (0) of constraints for
 product_versions(product_id, ordering)

 This was previously reported as fixed (see
 https://code.djangoproject.com/ticket/28697), but it is not. Using 1.11.5,
 and 1.11.9, it fails.

 The fix is very easy: in DatabaseIntrospection.get_constraints(), an ORDER
 BY is missing when selecting from the table
 INFOMRATION_SCHEMA.KEY_COLUMN_USAGE:

  Thus:

 {{{
 def get_constraints(self, cursor, table_name):
 """
 Retrieves any constraints or keys (unique, pk, fk, check, index)
 across one or more columns.
 """
 constraints = {}
 # Get the actual constraint names and columns
 name_query = """
 SELECT kc.`constraint_name`, kc.`column_name`,
 kc.`referenced_table_name`, kc.`referenced_column_name`
 FROM information_schema.key_column_usage AS kc
 WHERE
 kc.table_schema = DATABASE() AND
 kc.table_name = %s
 ORDER BY kc.`constraint_name`, kc.`ordinal_position`
 """

 }}}

 The ORDER BY assures the order the columns were specified. the SHOW INDEX
 statement does this by default.

 The above should work for all MySQL versions supported.

 Note that Django 2.0 has the same issue.

 Patch available
 
https://github.com/geertjanvdk/django/commit/ab0bcb327c51aab71f58789eb55a7981dcb06fdb

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