date:20190416

Re: [Django] #30378: AttributeError: 'NoneType' object has no attribute 'split'

2019-04-16 Thread Django

#30378: AttributeError: 'NoneType' object has no attribute 'split'
---+--
 Reporter:  PM |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by PM:

Old description:

> I'm writing very simple code while learning Django. I noticed there is
> some error in the server console window sometimes when I refreshed my
> browser.
>
> The error always ends with the line in the ticket Summary. The following
> is the entire copy of the error.
> What the strange is everything works good except the error information.
> Nothing is broken. The view is always rendered properly. Any idea what it
> is mean?
>

> {{{
> [17/Apr/2019 14:52:40] "GET /favicon.ico HTTP/1.1" 404 2189
> Traceback (most recent call last):
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 138, in run
> self.finish_response()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 180, in
> finish_response
> self.write(data)
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 274, in write
> self.send_headers()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 332, in
> send_headers
> self.send_preamble()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 255, in
> send_preamble
> ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 453, in _write
> result = self.stdout.write(data)
>   File "C:\Python\Python37\lib\socketserver.py", line 799, in write
> self._sock.sendall(b)
> ConnectionAbortedError: [WinError 10053] An established connection was
> aborted by the software in your host machine
> [17/Apr/2019 14:52:40] "GET /favicon.ico HTTP/1.1" 500 59
> 
> Exception happened during processing of request from ('127.0.0.1', 55341)
> Traceback (most recent call last):
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 138, in run
> self.finish_response()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 180, in
> finish_response
> self.write(data)
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 274, in write
> self.send_headers()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 332, in
> send_headers
> self.send_preamble()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 255, in
> send_preamble
> ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 453, in _write
> result = self.stdout.write(data)
>   File "C:\Python\Python37\lib\socketserver.py", line 799, in write
> self._sock.sendall(b)
> ConnectionAbortedError: [WinError 10053] An established connection was
> aborted by the software in your host machine
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 141, in run
> self.handle_error()
>   File "C:\PythonCode\SeaMotor\venv\lib\site-
> packages\django\core\servers\basehttp.py", line 116, in handle_error
> super().handle_error()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 368, in
> handle_error
> self.finish_response()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 180, in
> finish_response
> self.write(data)
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 274, in write
> self.send_headers()
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 331, in
> send_headers
> if not self.origin_server or self.client_is_modern():
>   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 344, in
> client_is_modern
> return self.environ['SERVER_PROTOCOL'].upper() != 'HTTP/0.9'
> TypeError: 'NoneType' object is not subscriptable
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "C:\Python\Python37\lib\socketserver.py", line 650, in
> process_request_thread
> self.finish_request(request, client_address)
>   File "C:\Python\Python37\lib\socketserver.py", line 360, in
> finish_request
> self.RequestHandlerClass(request, client_address, self)
>   File "C:\Python\Python37\lib\socketserver.py", line 720, in __init__
> self.handle()
>   File "C:\PythonCode\SeaMotor\venv\lib\site-
> packages\django\core\servers\basehttp.py", line 171, in handle
> self.handle_one_request

[Django] #30378: AttributeError: 'NoneType' object has no attribute 'split'

2019-04-16 Thread Django

#30378: AttributeError: 'NoneType' object has no attribute 'split'
-+
   Reporter:  PM |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.1
   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  |
-+
 I'm writing very simple code while learning Django. I noticed there is
 some error in the server console window sometimes when I refreshed my
 browser.

 The error always ends with the line in the ticket Summary. The following
 is the entire copy of the error.
 What the strange is everything works good except the error information.
 Nothing is broken. The view is always rendered properly. Any idea what it
 is mean?


 {{{
 [17/Apr/2019 14:52:40] "GET /favicon.ico HTTP/1.1" 404 2189
 Traceback (most recent call last):
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 138, in run
 self.finish_response()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 180, in
 finish_response
 self.write(data)
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 274, in write
 self.send_headers()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 332, in
 send_headers
 self.send_preamble()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 255, in
 send_preamble
 ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 453, in _write
 result = self.stdout.write(data)
   File "C:\Python\Python37\lib\socketserver.py", line 799, in write
 self._sock.sendall(b)
 ConnectionAbortedError: [WinError 10053] An established connection was
 aborted by the software in your host machine
 [17/Apr/2019 14:52:40] "GET /favicon.ico HTTP/1.1" 500 59
 
 Exception happened during processing of request from ('127.0.0.1', 55341)
 Traceback (most recent call last):
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 138, in run
 self.finish_response()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 180, in
 finish_response
 self.write(data)
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 274, in write
 self.send_headers()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 332, in
 send_headers
 self.send_preamble()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 255, in
 send_preamble
 ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 453, in _write
 result = self.stdout.write(data)
   File "C:\Python\Python37\lib\socketserver.py", line 799, in write
 self._sock.sendall(b)
 ConnectionAbortedError: [WinError 10053] An established connection was
 aborted by the software in your host machine

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 141, in run
 self.handle_error()
   File "C:\PythonCode\SeaMotor\venv\lib\site-
 packages\django\core\servers\basehttp.py", line 116, in handle_error
 super().handle_error()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 368, in
 handle_error
 self.finish_response()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 180, in
 finish_response
 self.write(data)
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 274, in write
 self.send_headers()
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 331, in
 send_headers
 if not self.origin_server or self.client_is_modern():
   File "C:\Python\Python37\lib\wsgiref\handlers.py", line 344, in
 client_is_modern
 return self.environ['SERVER_PROTOCOL'].upper() != 'HTTP/0.9'
 TypeError: 'NoneType' object is not subscriptable

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "C:\Python\Python37\lib\socketserver.py", line 650, in
 process_request_thread
 self.finish_request(request, client_address)
   File "C:\Python\Python37\lib\socketserver.py", line 360, in
 finish_request
 self.RequestHandlerClass(request, client_address, self)
   File "C:\Python\Python37\lib\socketserver.py", line 720, in __init__
 self.handle()
   File "C:\PythonCode\SeaMotor\venv\lib\site-
 packages\django\core\servers\basehttp.py", line 171, in handle
 self.handle_one_request()
   File "C:\PythonCode\SeaMotor\venv\lib\site-
 packages\django\core\servers\basehttp.py", line 194, in handle_one_request
 handler.run(self.server.get_app())
   File "C

Re: [Django] #30342: Remove the LANGUAGES_BIDI<=LANGUAGES check

2019-04-16 Thread Django

#30342: Remove the LANGUAGES_BIDI<=LANGUAGES check
--+
 Reporter:  Matthias Kestenholz   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (System checks)  |  Version:  master
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Matthias Kestenholz):

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

 The pull request removes the system check and amends the `LANGUAGES_BIDI`
 description to make it clear that `LANGUAGES_BIDI` isn't supposed to be a
 subset of `LANGUAGES`.

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

Re: [Django] #30374: Paginator UnorderedObjectListWarning on union(all=True) of two sorted queries

2019-04-16 Thread Django

#30374: Paginator UnorderedObjectListWarning on union(all=True) of two sorted
queries
-+-
 Reporter:  Rich Rauenzahn   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * component:  Uncategorized => Database layer (models, ORM)
 * version:  1.11 => master
 * resolution:   => invalid


Comment:

 I agree that in your case all composed queries are ordered but the final
 query is not. To avoid this warning you can add `order_by()` to the final
 queryset, e.g.
 {{{#!python
 haves =
 
MyModel.objects.filter(foreign_relationship=4).order_by('foreign_relationship__value',
 'common_key')
 havenots = MyModel.objects.exclude(id__in=haves).order_by('common_key')
 query = haves.union(havenots, all=True).order_by('common_key')
 }}}

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

Re: [Django] #30371: sqlmigrate fails with string defaults on mysql

2019-04-16 Thread Django

#30371: sqlmigrate fails with string defaults on mysql
-+-
 Reporter:  Melvyn Sopacua   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  needsinfo
 Keywords:  regression   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

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


Comment:

 I was unable to reproduce until now, we need more information, please.

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

Re: [Django] #27755: add ModelAdmin.get_inlines() hook to allow set inlines based on the request or model instance.

2019-04-16 Thread Django

#27755: add ModelAdmin.get_inlines() hook to allow set inlines based on the 
request
or model instance.
-+-
 Reporter:  WeizhongTu   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  django,admin,inlines   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"917fd9d03fdd21538864af4b412ac30b36d99268" 917fd9d0]:
 {{{
 #!CommitTicketReference repository=""
 revision="917fd9d03fdd21538864af4b412ac30b36d99268"
 Fixed #27755 -- Added ModelAdmin.get_inlines() hook.
 }}}

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

Re: [Django] #30352: Error al ejecutar python manage.py sin sealizar cambios

2019-04-16 Thread Django

#30352: Error al ejecutar python manage.py sin sealizar cambios
-+-
 Reporter:  irv-ro-j |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (System |  Version:  2.2
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  Reload Django| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Everything works for me :| Can you provide test project to reproduce this
 issue?

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

Re: [Django] #30375: Use "NO KEY" when doing select_for_update for PostgreSQL

2019-04-16 Thread Django

#30375: Use "NO KEY" when doing select_for_update for PostgreSQL
-+-
 Reporter:  Manuel Weitzman  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, lock,  | Triage Stage:
  database, operation|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 The docs are correct for `save` but primary keys are still updatable
 through `queryset.filter(pk=old_value).update(pk=new_value)`.

 Feel free to submit a PR. It'd be great to investigate if other backends
 have a similar option as well.

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

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

Re: [Django] #30361: Watchman timing out when loading server

2019-04-16 Thread Django

#30361: Watchman timing out when loading server
---+
 Reporter:  Jacob Green|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by James Addison):

 I've just found that adding a `.watchmanconfig` file to add the
 `ignore_dirs` directive seemed to help (I assume this would allow watchman
 to start more quickly).  See
 https://facebook.github.io/watchman/docs/config.html#ignore_dirs

 {{{
 {
   "ignore_dirs": ["node_modules", ".envs", "bin", "lib", "include",
 ".git", ".idea", "templates", "static_assets"]
 }
 }}}

 It certainly isn't a fix - but as mentioned in the Django docs, it's worth
 investigating as a bandaid.

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

Re: [Django] #30361: Watchman timing out when loading server

2019-04-16 Thread Django

#30361: Watchman timing out when loading server
---+
 Reporter:  Jacob Green|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Jacob Green):

 I run into the issue consistently on our codebase so I can repro it.
 Tobias, how would you recommend that I test against your patch? I know how
 to install Django from pypi but I don't know how to install it from a
 fork.

 Also I may be misreading but in the commit that you linked it seems that
 you lowered the timeout to 0.2s instead of raising it above 1.0s. Perhaps
 that was unintentional?

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

[Django] #30377: Exceptions when viewing project on local machine

2019-04-16 Thread Django

#30377: Exceptions when viewing project on local machine
-+
   Reporter:  Chaos  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  HTTP handling  |Version:  2.2
   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  |
-+
 Hello,

 When running Django locally with the following command: "python -m django
 runserver" I receive 3 exceptions on every request I make to the
 webserver, on the browser nothing seems to work unusually. The page loads
 normally, but these exceptions are always printed. None of the tracebacks
 point to any of my code actually.

 My view is basic:

 {{{
 def homepage(request):
 return render(request, 'sites/home.html')
 }}}


 Exceptions:
 {{{
 Traceback (most recent call last):
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 138, in run
 self.finish_response()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 180, in finish_response
 self.write(data)
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 274, in write
 self.send_headers()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 332, in send_headers
 self.send_preamble()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 255, in send_preamble
 ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 453, in _write
 result = self.stdout.write(data)
   File "C:\Program Files (x86)\Python3.7\lib\socketserver.py", line 799,
 in write
 self._sock.sendall(b)
 ConnectionAbortedError: [WinError 10053] An established connection was
 aborted by the software in your host machine
 [16/Apr/2019 21:22:37] "GET /assets/favicon.ico HTTP/1.1" 500 59
 
 Exception happened during processing of request from ('127.0.0.1', 62675)
 Traceback (most recent call last):
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 138, in run
 self.finish_response()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 180, in finish_response
 self.write(data)
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 274, in write
 self.send_headers()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 332, in send_headers
 self.send_preamble()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 255, in send_preamble
 ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 453, in _write
 result = self.stdout.write(data)
   File "C:\Program Files (x86)\Python3.7\lib\socketserver.py", line 799,
 in write
 self._sock.sendall(b)
 ConnectionAbortedError: [WinError 10053] An established connection was
 aborted by the software in your host machine

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 141, in run
 self.handle_error()
   File "E:\Development\Python Environments\env\lib\site-
 packages\django\core\servers\basehttp.py", line 116, in handle_error
 super().handle_error()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 368, in handle_error
 self.finish_response()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 180, in finish_response
 self.write(data)
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 274, in write
 self.send_headers()
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 331, in send_headers
 if not self.origin_server or self.client_is_modern():
   File "C:\Program Files (x86)\Python3.7\lib\wsgiref\handlers.py", line
 344, in client_is_modern
 return self.environ['SERVER_PROTOCOL'].upper() != 'HTTP/0.9'
 TypeError: 'NoneType' object is not subscriptable

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "C:\Program Files (x86)\Python3.7\lib\socketserver.py", line 650,
 in process_request_thread
 self.finish_request(request, client_address)
   File "C:\Program Files (x86)\Python3.7\lib\socketserver.py", line 360,
 in finish_request
 self.RequestHandlerClass(request, client_address, self)
   File "C:\Program Files (x86)\Python3.7\lib\socketserver.py", line 720,
 in __init__
 self.handle()
   Fi

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

2019-04-16 Thread Django

#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.2
 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 Benjamin Schollnick):

 I see no difference in the cpu utilization if I install pywatchman /
 watchman in MOSX.  The only resolution that I have found is to regress to
 2.1.8, which drops the CPU usage down to ~1%.

 I'm happy to run any other additional diagnostic suggestions that you
 have...  I'm just unclear on the next steps

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

Re: [Django] #30309: Remove hasattr reference in One-to-One documentation example

2019-04-16 Thread Django

#30309: Remove hasattr reference in One-to-One documentation example
---+--
 Reporter:  David Beitey   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  2.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by David Beitey):

 Discussion around raising `self.RelatedObjectDoesNotExist` continues at
 https://groups.google.com/d/msgid/django-
 developers/cdcf9eda-c691-4354-b806-51de36ec6d24%40googlegroups.com

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

Re: [Django] #30376: Saving ModelForm with missing, non-optional fields does not trigger a validation error

2019-04-16 Thread Django

#30376: Saving ModelForm with missing, non-optional fields does not trigger a
validation error
---+--
 Reporter:  Will Gordon|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  2.1
 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 Will Gordon):

 Ok, so maybe this is more of an issue with the `save()` as opposed to
 validation. As I read that quote

   if the model does not allow the missing fields to be empty, and does not
 provide a default value for the missing fields, any attempt to save() a
 ModelForm with missing fields will fail

 If I have a field with `blank=False` in my Model, then doing a `save()` on
 the ModelForm should fail...regardless of if I have specified that field
 in the ModelForm or not. Am I just taking a narrow view on that comment,
 or is it saying something other than what I'm reading?

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

Re: [Django] #30376: Saving ModelForm with missing, non-optional fields does not trigger a validation error

2019-04-16 Thread Django

Comment (by zeynel özdemir):

As it is written in documentation
(https://docs.djangoproject.com/en/2.1/topics/forms/modelforms
/#interaction-with-model-validation):

As part of the validation process, ModelForm will call the clean() method
of each field on your model that has a corresponding field on your form.
If you have excluded any model fields, validation will not be run on those
fields.

It is not a bug, it is expected behaviour. `ModelForm` should not care
about the validation of the fields that are not defined in `fields`
attribute, since we are explicitly telling it which fields to use.
Otherwise, it would cause too much confusion.

And here, it does not say that validation will fail:
Django will prevent any attempt to save an incomplete model, so if the
model does not allow the missing fields to be empty, and does not provide
a default value for the missing fields, any attempt to save() a ModelForm
with missing fields will fail.

It says that any attempt to save() a ModelForm with missing fields will
fail.

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

Re: [Django] #30375: Use "NO KEY" when doing select_for_update for PostgreSQL

2019-04-16 Thread Django

Comment (by Manuel Weitzman):

Replying to [comment:2 Simon Charette]:
> > ... in Django, primary key fields are read-only, so locking them makes
no sense
>
> That's not true AFAIK. Even if `AutoField` are backed by sequences and
generated on the database side they can still be overridden by developers.
Same thing with non-`AutoField` primary keys (e.g.
`UUIDField(default=uuid.uuid4)`).

Then the docs are wrong or at least misleading: ''"The primary key field
is read-only. If you change the value of the primary key on an existing
object and then save it, a new object will be created alongside the old
one."" (https://docs.djangoproject.com/en/2.2/topics/db/models/)

Which means that UPDATEs over PKs are transformed into INSERTs

> On the other hand updating a primary key while holding a lock is really
uncommon so I wouldn't be against adding a `select_for_udate(primary_key)`
parameter that defaults to `False`. We just have to make sure that we
still allow these operations to be performed somehow.

That is possible, I tested today and only a few changes are required to
achieve this behavior. Maybe I could send a PR soon for review?

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

Re: [Django] #30352: Error al ejecutar python manage.py sin sealizar cambios

2019-04-16 Thread Django

#30352: Error al ejecutar python manage.py sin sealizar cambios
-+-
 Reporter:  irv-ro-j |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (System |  Version:  2.2
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  Reload Django| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Scott Talbert):

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


Comment:

 I'm seeing the same issue apparently (although I don't understand Spanish
 well):

 {{{
 Watching for file changes with StatReloader
 Performing system checks...

 Exception in thread Thread-1:
 Traceback (most recent call last):
   File "/rest_api/env/lib/python3.6/site-
 packages/django/template/utils.py", line 66, in __getitem__
 return self._engines[alias]
 KeyError: 'django'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
 self.run()
   File "/usr/lib/python3.6/threading.py", line 864, in run
 self._target(*self._args, **self._kwargs)
   File "/rest_api/env/lib/python3.6/site-
 packages/django/utils/autoreload.py", line 54, in wrapper
 fn(*args, **kwargs)
   File "/rest_api/env/lib/python3.6/site-
 packages/django/core/management/commands/runserver.py", line 117, in
 inner_run
 self.check(display_num_errors=True)
   File "/rest_api/env/lib/python3.6/site-
 packages/django/core/management/base.py", line 390, in check
 include_deployment_checks=include_deployment_checks,
   File "/rest_api/env/lib/python3.6/site-
 packages/django/core/management/base.py", line 377, in _run_checks
 return checks.run_checks(**kwargs)
   File "/rest_api/env/lib/python3.6/site-
 packages/django/core/checks/registry.py", line 72, in run_checks
 new_errors = check(app_configs=app_configs)
   File "/rest_api/env/lib/python3.6/site-
 packages/django/contrib/admin/checks.py", line 80, in check_dependencies
 for engine in engines.all():
   File "/rest_api/env/lib/python3.6/site-
 packages/django/template/utils.py", line 90, in all
 return [self[alias] for alias in self]
   File "/rest_api/env/lib/python3.6/site-
 packages/django/template/utils.py", line 90, in 
 return [self[alias] for alias in self]
   File "/rest_api/env/lib/python3.6/site-
 packages/django/template/utils.py", line 81, in __getitem__
 engine = engine_cls(params)
   File "/rest_api/env/lib/python3.6/site-
 packages/django/template/backends/django.py", line 25, in __init__
 options['libraries'] = self.get_templatetag_libraries(libraries)
   File "/rest_api/env/lib/python3.6/site-
 packages/django/template/backends/django.py", line 43, in
 get_templatetag_libraries
 libraries = get_installed_libraries()
   File "/rest_api/env/lib/python3.6/site-
 packages/django/template/backends/django.py", line 108, in
 get_installed_libraries
 for name in get_package_libraries(pkg):
   File "/rest_api/env/lib/python3.6/site-
 packages/django/template/backends/django.py", line 121, in
 get_package_libraries
 module = import_module(entry[1])
   File "/usr/lib/python3.6/importlib/__init__.py", line 126, in
 import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 994, in _gcd_import
   File "", line 971, in _find_and_load
   File "", line 955, in
 _find_and_load_unlocked
   File "", line 665, in _load_unlocked
   File "", line 678, in exec_module
   File "", line 219, in
 _call_with_frames_removed
   File "/rest_api/env/lib/python3.6/site-
 packages/rest_framework/templatetags/rest_framework.py", line 15, in
 
 from rest_framework.renderers import HTMLFormRenderer
   File "/rest_api/env/lib/python3.6/site-
 packages/rest_framework/renderers.py", line 20, in 
 from django.test.client import encode_multipart
   File "/rest_api/env/lib/python3.6/site-
 packages/django/test/client.py", line 23, in 
 from django.test import signals
   File "", line 968, in _find_and_load
   File "", line 149, in __enter__
   File "", line 94, in acquire
 _frozen_importlib._DeadlockError: deadlock detected by
 _ModuleLock('django.test.signals') at 140466248423072
 }}}

 My packages list is a bit shorter:
 {{{
 certifi==2019.3.9
 chardet==3.0.4
 colorama==0.4.1
 Django==2.2
 djangorestframework==3.9.2
 future==0.17.1
 h2o==3.22.1.5
 idna==2.8
 numpy==1.16.2
 pandas==0.24.2
 pkg-resources==0.

Re: [Django] #30375: Use "NO KEY" when doing select_for_update for PostgreSQL

2019-04-16 Thread Django

* version: 2.2 => master

Comment:

> ... in Django, primary key fields are read-only, so locking them makes
no sense

That's not true AFAIK. Even if `AutoField` are backed by sequences and
generated on the database side they can still be overridden by developers.
Same thing with non-`AutoField` primary keys (e.g.
`UUIDField(default=uuid.uuid4)`).

On the other hand updating a primary key while holding a lock is really
uncommon so I wouldn't be against adding a `select_for_udate(primary_key)`
parameter that defaults to `False`. We just have to make sure that we
still allow these operations to be performed somehow.

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

Re: [Django] #30375: Use "NO KEY" when doing select_for_update for PostgreSQL

2019-04-16 Thread Django

#30375: Use "NO KEY" when doing select_for_update for PostgreSQL
-+-
 Reporter:  mudetz   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, lock,  | Triage Stage:
  database, operation|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mudetz):

 * version:  1.11 => 2.2


Old description:

> Currently Django compiles select for update into one of
> - FOR UPDATE
> - FOR UPDATE NOWAIT
> - FOR UPDATE SKIP LOCKED
>
> All of these acquire a lock which conflicts with `KEY SHARE` locks. This
> means that updates on tables which references a row locked by `FOR
> UPDATE` will have to wait until the lock is released. This is to avoid
> any unexpected changes on `PRIMARY KEY` fields but, **in Django, primary
> key fields are read-only, so locking them makes no sense**.
>
> There is no need to acquire these kind of locks, instead, we should (at
> least be able to) use
> - FOR NO KEY UPDATE
> - FOR NO KEY UPDATE NOWAIT
> - FOR NO KEY UPDATE SKIP LOCKED
>
> which can be easily done by overriding BaseOperation.for_update_sql in
> Postgres DatabaseOperation
>

> {{{
> def for_update_sql(self, nowait=False, skip_locked=False):
> """
> Returns the FOR UPDATE SQL clause to lock rows for an update
> operation.
> """
> if nowait:
> return 'FOR NO KEY UPDATE NOWAIT'
> elif skip_locked:
> return 'FOR NO KEY UPDATE SKIP LOCKED'
> else:
> return 'FOR NO KEY UPDATE'
> }}}
>
> Not doing so causes lock contention in our use case.

New description:

 Currently Django compiles select for update into one of
 - FOR UPDATE
 - FOR UPDATE NOWAIT
 - FOR UPDATE SKIP LOCKED

 All of these acquire a lock which conflicts with `KEY SHARE` locks. This
 means that updates on tables which references a row locked by `FOR UPDATE`
 will have to wait until the lock is released. This is to avoid any
 unexpected changes on `PRIMARY KEY` fields but, **in Django, primary key
 fields are read-only, so locking them makes no sense**.

 There is no need to acquire these kind of locks, instead, we should (at
 least be able to) use
 - FOR NO KEY UPDATE
 - FOR NO KEY UPDATE NOWAIT
 - FOR NO KEY UPDATE SKIP LOCKED

 which can be easily done by overriding BaseOperation.for_update_sql in
 Postgres DatabaseOperation

 For 1.11
 {{{
 def for_update_sql(self, nowait=False, skip_locked=False):
 """
 Returns the FOR UPDATE SQL clause to lock rows for an update
 operation.
 """
 if nowait:
 return 'FOR NO KEY UPDATE NOWAIT'
 elif skip_locked:
 return 'FOR NO KEY UPDATE SKIP LOCKED'
 else:
 return 'FOR NO KEY UPDATE'
 }}}

 For 2.2

 {{{
 def for_update_sql(self, nowait=False, skip_locked=False, of=()):
 """
 Return the FOR UPDATE SQL clause to lock rows for an update operation.
 """
 return 'FOR NO KEY UPDATE%s%s%s' % (
 ' OF %s' % ', '.join(of) if of else '',
 ' NOWAIT' if nowait else '',
 ' SKIP LOCKED' if skip_locked else '',
 )
 }}}


 Not doing so causes lock contention in our use case.

--

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

Re: [Django] #13677: ModelFormSet may query wrong database backend

2019-04-16 Thread Django

#13677: ModelFormSet may query wrong database backend
--+
 Reporter:  Pierre Chifflier  |Owner:  Tobias Kunze
 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 Tobias Kunze):

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

[Django] #30376: Saving ModelForm with missing, non-optional fields does not trigger a validation error

2019-04-16 Thread Django

#30376: Saving ModelForm with missing, non-optional fields does not trigger a
validation error
-+
   Reporter:  Will Gordon|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  2.1
   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  |
-+
 I have my model

 {{{#!python
 class Meeting(models.Model):
 title = models.CharField(max_length=255, help_text='A short header for
 your meeting')
 summary = models.TextField(help_text='An overview of the meeting.
 You\'ll have the opportunity to add specific notes later on')
 outcome = models.TextField(help_text='What was the final conclusion to
 the meeting')
 attended = models.DateField(help_text='When did you attend this
 meeting')
 attendees = models.ManyToManyField(Person, related_name='meetings')
 companies = models.ManyToManyField(Company, related_name='meetings')
 industries = models.ManyToManyField(Industry, related_name='meetings')
 author = models.ForeignKey(Person, on_delete=models.SET_NULL,
 related_name='my_meetings', null=True)
 }}}

 and my form

 {{{#!python
 class MeetingForm(forms.ModelForm):
 class Meta:
 model = models.Meeting
 fields = ['author', 'attended', 'attendees', 'companies',
 'industries', 'outcome']
 }}}

 Because `title`, and `summary` are not listed in my form's `fields`, I
 would expect this form to never be savable.

 This was a result of my merging of two models, I updated the Model, but
 not the Form. I was surprised when I was then able to save the Form.

 Based on documentation from
 https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#selecting-
 the-fields-to-use

   Django will prevent any attempt to save an incomplete model, so if the
 model does not allow the missing fields to be empty, and does not provide
 a default value for the missing fields, any attempt to save() a ModelForm
 with missing fields will fail.

 I would expect the validation to fail since there is no default value
 provided.

 This is either a docs bug, with the form validation working as expected
 (not validating any fields explicitly excluded)...or a form validation
 bug, where the form should still validate all Model fields to ensure it's
 not saving blank fields.

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

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

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions fails for models recreated as a proxy.

2019-04-16 Thread Django

#30351: Migration auth.0011_update_proxy_permissions fails for models recreated 
as
a proxy.
-+--
 Reporter:  Julien Enselme   |Owner:  Arthur Rio
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Arthur Rio):

 Yes it is the same issue. My recommendation to let the users figure it out
 with a helpful message still stands even if it may sound a bit painful,
 because:
 1. It prevents data loss (we don't do an automatic delete/create of
 permissions)
 2. It prevents security oversights (we don't re-use an existing
 permission)
 3. It shouldn't happen for most use cases

 Again, I would love to hear some feedback or other alternatives.

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

Re: [Django] #21080: collectstatic post-processing fails for references inside comments

2019-04-16 Thread Django

* has_patch: 0 => 1

Comment:

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

I put something together that detects block comments in css (using
[https://github.com/django/django/pull/11241/files#diff-
c7242dedd7c93b857a668acec1e310feR154 a regexp]) and ignores those urls
that overlap with a comment.
It has the benefit of not requiring additional dependencies to parse css.

I think it's ready but I'm probably missing some test cases, feedback
welcome!

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

Re: [Django] #21080: collectstatic post-processing fails for references inside comments

2019-04-16 Thread Django

#21080: collectstatic post-processing fails for references inside comments
-+-
 Reporter:  shreyas@…|Owner:  Nathan
 |  Gaberel
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  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 Nathan Gaberel):

 * status:  new => assigned
 * owner:  nobody => Nathan Gaberel


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

[Django] #30375: Use "NO KEY" when doing select_for_update for PostgreSQL

2019-04-16 Thread Django

#30375: Use "NO KEY" when doing select_for_update for PostgreSQL
-+-
   Reporter:  mudetz |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  1.11
  layer (models, ORM)|   Keywords:  postgres, lock,
   Severity:  Normal |  database, operation
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently Django compiles select for update into one of
 - FOR UPDATE
 - FOR UPDATE NOWAIT
 - FOR UPDATE SKIP LOCKED

 All of these acquire a lock which conflicts with `KEY SHARE` locks. This
 means that updates on tables which references a row locked by `FOR UPDATE`
 will have to wait until the lock is released. This is to avoid any
 unexpected changes on `PRIMARY KEY` fields but, **in Django, primary key
 fields are read-only, so locking them makes no sense**.

 There is no need to acquire these kind of locks, instead, we should (at
 least be able to) use
 - FOR NO KEY UPDATE
 - FOR NO KEY UPDATE NOWAIT
 - FOR NO KEY UPDATE SKIP LOCKED

 which can be easily done by overriding BaseOperation.for_update_sql in
 Postgres DatabaseOperation


 {{{
 def for_update_sql(self, nowait=False, skip_locked=False):
 """
 Returns the FOR UPDATE SQL clause to lock rows for an update
 operation.
 """
 if nowait:
 return 'FOR NO KEY UPDATE NOWAIT'
 elif skip_locked:
 return 'FOR NO KEY UPDATE SKIP LOCKED'
 else:
 return 'FOR NO KEY UPDATE'
 }}}

 Not doing so causes lock contention in our use case.

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

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

Re: [Django] #30374: Paginator UnorderedObjectListWarning on union(all=True) of two sorted queries

2019-04-16 Thread Django

#30374: Paginator UnorderedObjectListWarning on union(all=True) of two sorted
queries
+--
 Reporter:  Rich Rauenzahn  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Uncategorized   |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by Rich Rauenzahn:

Old description:

> I wonder if this is a case you want to catch and *not* warn about.
>
> In my case, I'm doing this:
>
> {{{
> haves =
> MyModel.objects.filter(foreign_relationship=4).order_by('foreign_relationship__value',
> 'common_key')
> havenots = MyModel.objects.exclude(id__in=haves).order_by('common_key')
> query = haves.union(havenots, all=True)
> }}}
>
> I'm using this with a `Paginator`.  The `Paginator` complains the queries
> are not ordered, but they actually are (right?) due to the `all=True` in
> the `union`.
>
> Is this a case the warning ought to handle and ignore?
>
> The Django 1.11 source is:
>
> {{{
> def _check_object_list_is_ordered(self):
> """
> Warn if self.object_list is unordered (typically a QuerySet).
> """
> ordered = getattr(self.object_list, 'ordered', None)
> if ordered is not None and not ordered:
> obj_list_repr = (
> '{} {}'.format(self.object_list.model,
> self.object_list.__class__.__name__)
> if hasattr(self.object_list, 'model')
> else '{!r}'.format(self.object_list)
> )
> warnings.warn(
> 'Pagination may yield inconsistent results with an
> unordered '
> 'object_list: {}.'.format(obj_list_repr),
> UnorderedObjectListWarning,
> stacklevel=3
> )
> }}}
>
> Should `union(..., all=True)` set ordered in the `QuerySet`?  Or maybe
> should it look and see if all the source queries are ordered and
> propagate that to the `QuerySet` `union` returns?

New description:

 I wonder if this is a case you want to catch and *not* warn about.

 In my case, I'm doing this:

 {{{
 haves =
 
MyModel.objects.filter(foreign_relationship=4).order_by('foreign_relationship__value',
 'common_key')
 havenots = MyModel.objects.exclude(id__in=haves).order_by('common_key')
 query = haves.union(havenots, all=True)
 }}}

 I'm using this with a `Paginator`.  The `Paginator` complains the queries
 are not ordered, but they actually are (right?) due to the `all=True` in
 the `union`.

 Is this a case the warning ought to handle and ignore?

 The Django 1.11 source is:

 {{{
 def _check_object_list_is_ordered(self):
 """
 Warn if self.object_list is unordered (typically a QuerySet).
 """
 ordered = getattr(self.object_list, 'ordered', None)
 if ordered is not None and not ordered:
 obj_list_repr = (
 '{} {}'.format(self.object_list.model,
 self.object_list.__class__.__name__)
 if hasattr(self.object_list, 'model')
 else '{!r}'.format(self.object_list)
 )
 warnings.warn(
 'Pagination may yield inconsistent results with an
 unordered '
 'object_list: {}.'.format(obj_list_repr),
 UnorderedObjectListWarning,
 stacklevel=3
 )
 }}}

 Should `union(..., all=True)` set `ordered` in the `QuerySet`?  Or maybe
 should it look and see if all the source queries are ordered and propagate
 that to the `QuerySet` `union` returns?

--

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

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions fails for models recreated as a proxy.

2019-04-16 Thread Django

#30351: Migration auth.0011_update_proxy_permissions fails for models recreated
as
a proxy.
-+--
Reporter: Julien Enselme |Owner: Arthur Rio
Type: Bug | Status: assigned
Component: contrib.auth | Version: 2.2
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+--

Comment (by B Martsberger):

It's also possible to get this kind of integrity error on the auth.0011
migration if another app is migrated first causing the auth
post_migrations hook to run. The auth post migrations hook runs
`django.contrib.auth.management.create_permissions`, which writes the new
form of the auth_permission records to the table. Then when the auth.0011
migration runs it tries to update things to the values that were just
written.

To reproduce this behavior:
1. pip install Django==2.1.7
2. Create an app, let's call it `app`, with two models,
`TestModel(models.Model)` and `ProxyModel(TestModel)` the second one with
proxy=True
3. `python manage.py makemigrations`
4. `python manage.py migrate`
5. pip install Django==2.2
6. Add another model to `app`
7. `python manage.py makemigrations`
8. migrate the app only, `python manage.py migrate app`. This does not run
the auth migrations, but does run the auth post_migrations hook
9. Note that new records have been added to auth_permission
10. `python manage.py migrate`, this causes an integrity error when the
auth.0011 migration tries to update records that are the same as the ones
already added in step 8.

This has the same exception as this bug report, I don't know if it's
considered a different bug, or the same one.

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

[Django] #30374: Paginator UnorderedObjectListWarning on union(all=True) of two sorted queries

2019-04-16 Thread Django

#30374: Paginator UnorderedObjectListWarning on union(all=True) of two sorted
queries
--+
   Reporter:  Rich Rauenzahn  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Uncategorized   |Version:  1.11
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 I wonder if this is a case you want to catch and *not* warn about.

 In my case, I'm doing this:

 {{{
 haves =
 
MyModel.objects.filter(foreign_relationship=4).order_by('foreign_relationship__value',
 'common_key')
 havenots = MyModel.objects.exclude(id__in=haves).order_by('common_key')
 query = haves.union(havenots, all=True)
 }}}

 I'm using this with a `Paginator`.  The `Paginator` complains the queries
 are not ordered, but they actually are (right?) due to the `all=True` in
 the `union`.

 Is this a case the warning ought to handle and ignore?

 The Django 1.11 source is:

 {{{
 def _check_object_list_is_ordered(self):
 """
 Warn if self.object_list is unordered (typically a QuerySet).
 """
 ordered = getattr(self.object_list, 'ordered', None)
 if ordered is not None and not ordered:
 obj_list_repr = (
 '{} {}'.format(self.object_list.model,
 self.object_list.__class__.__name__)
 if hasattr(self.object_list, 'model')
 else '{!r}'.format(self.object_list)
 )
 warnings.warn(
 'Pagination may yield inconsistent results with an
 unordered '
 'object_list: {}.'.format(obj_list_repr),
 UnorderedObjectListWarning,
 stacklevel=3
 )
 }}}

 Should `union(..., all=True)` set ordered in the `QuerySet`?  Or maybe
 should it look and see if all the source queries are ordered and propagate
 that to the `QuerySet` `union` returns?

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

Re: [Django] #14688: BaseInlineFormSet does not support "auto_id"

2019-04-16 Thread Django

#14688: BaseInlineFormSet does not support "auto_id"
---+
 Reporter:  Victor Andrée  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  formsets   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Nick Pope):

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


Comment:

 Reopening due to
 [https://github.com/django/django/pull/11237#issuecomment-483382596
 comment] on discarded PR.

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

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

Re: [Django] #30138: Allow QuerySet.bulk_create() to set pk of created objects when ignore_conflicts=True

2019-04-16 Thread Django

#30138: Allow QuerySet.bulk_create() to set pk of created objects when
ignore_conflicts=True
-+-
 Reporter:  saber solooki|Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Seunghun Lee):

 * status:  assigned => new
 * owner:  Seunghun Lee => (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/071.9418755cd477800aae7dd066e43c66d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

2019-04-16 Thread Django

#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.2
 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 Tobias Kunze):

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

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

2019-04-16 Thread Django

#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.2
 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 Tobias Kunze):

 Does this happen independently of the size of your project? Does it change
 if you install `pywatchman` and `watchman` (with Django 2.2)?

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

Re: [Django] #30370: Add support for postgresql client certificates and key to dbshell.

2019-04-16 Thread Django

#30370: Add support for postgresql client certificates and key to dbshell.
-+-
 Reporter:  Oleh Mykytyuk|Owner:  Oleh
 Type:   |  Mykytyuk
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell postgresql   | Triage Stage:  Ready for
  certificate|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

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

[Django] #30373: "Save as new" with read-only fields

2019-04-16 Thread Django

#30373: "Save as new" with read-only fields
-+
   Reporter:  Nicola Zilio   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I want to implement the "Save as new" feature in Django's admin for a
 model such as this one:


 {{{
 class Plasmid (models.Model):
 name = models.CharField("Name", max_length = 255, blank=False)
 other_name = models.CharField("Other Name", max_length = 255,
 blank=True)
 selection = models.CharField("Selection", max_length = 50,
 blank=False)
 created_by = models.ForeignKey(User)
 }}}


 In the admin, if the user who requests a Plasmid object is NOT the same as
 the one who created it, some of the above-shown fields are set as read-
 only. If the user is the same, they are all editable. For example:

 {{{
 class PlasmidPage(admin.ModelAdmin):

 def get_readonly_fields(self, request, obj=None):

 if obj:
 if not request.user == obj.created_by:
 return ['name', 'created_by',]
 else:
 return ['created_by',]
 else:
 return []

 def change_view(self,request,object_id,extra_context=None):

 self.fields = ('name', 'other_name', 'selection', 'created_by',)
 return super(PlasmidPage,self).change_view(request,object_id)
 }}}

 The issue I have is that when a field is read-only and a user hits the
 "Save as new" button, the value of that field is not 'transferred' to the
 new object. On the other hand, the values of fields that are editable (not
 read-only) are transferred.

 I don't understand if this is a bug or a (security?) feature. In either
 case does anybody why, or how I could solve this problem? I want to
 transfer the values of both read-only and non-read-only fields to the new
 object.

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

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

2019-04-16 Thread Django

#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.2
 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 Benjamin Schollnick):

 The processor load on Windows 10 (64bit) Pro, is slightly lower.
 Averaging ~8-10% w/Win 10 v1809, i5-6300u @ 2.40 Ghz w/8 Gb of ram.

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

Re: [Django] #25633: GeoDjango KyngChaos installation instructions are outdated

2019-04-16 Thread Django

#25633: GeoDjango KyngChaos installation instructions are outdated
-+-
 Reporter:  Tim Graham   |Owner:  Daniel
 Type:   |  Hepper
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

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

Re: [Django] #16922: Add a template-based form rendering system

2019-04-16 Thread Django

#16922: Add a template-based form rendering system
+
 Reporter:  Carl Meyer  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tobias Kunze):

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


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

Re: [Django] #30312: Admin app has too hard a dependency on sessions app

2019-04-16 Thread Django

#30312: Admin app has too hard a dependency on sessions app
-+-
 Reporter:  Aarni Koskela|Owner:  Aarni
 Type:   |  Koskela
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  2.2
 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 Aarni Koskela):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

 Patch is ready and waiting for review.

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

Re: [Django] #30367: Docs: Change examples using bare `pip ...` to `python -m pip ...`

2019-04-16 Thread Django

#30367: Docs: Change examples using bare `pip ...` to `python -m pip ...`
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

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

Re: [Django] #30367: Docs: Change examples using bare `pip ...` to `python -m pip ...`

2019-04-16 Thread Django

#30367: Docs: Change examples using bare `pip ...` to `python -m pip ...`
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Ramiro Morales):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #30370: Add support for postgresql client certificates and key to dbshell.

2019-04-16 Thread Django

#30370: Add support for postgresql client certificates and key to dbshell.
-+-
 Reporter:  Oleh Mykytyuk|Owner:  Oleh
 Type:   |  Mykytyuk
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell postgresql   | Triage Stage:  Accepted
  certificate|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #6785: QuerySet.get() should only attempt to fetch a limited number of rows

2019-04-16 Thread Django

#6785: QuerySet.get() should only attempt to fetch a limited number of rows
-+-
 Reporter:  Brantley |Owner:  Amir Hadi
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 felixxm):

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


Comment:

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

Re: [Django] #23004: Cleanse entries from request.META in debug views

2019-04-16 Thread Django

Comment (by Daniel Maxson):

Thanks for the clarification. I misunderstood your previous comment. I
think what you're saying gets to the point I mention in the PR here:

{{{
I added the values as optional construction arguments with the defaults
coming from constants defined on the class. The class definition looks a
little clunkier but my thinking was this may be more pleasant to use when
actually creating subclasses than needing to update the attributes only
after construction.

Still, I'm not married to this approach and can remove the arguments (and
make any other changes) if the approach in the new commits doesn't sit
right with people.
}}}

My PR was intended primarily as an effort to bring Ryan's PR up to date
just because there hadn't been work on it in a while and I wanted to get
this feature for my own use. I happened to throw in the arguments while
working on that because it felt strange to me at the time not to, but
having done that, I can see the case against the added complexity.

Regardless, adding the arguments is outside the scope of this ticket so in
retrospect I should have limited myself only to updating Ryan's 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.90221dd1989746239328a84ab20434d5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30372: Django (moderately) High CPU usage at Idle

2019-04-16 Thread Django

#30372: Django (moderately) High CPU usage at Idle
---+
Reporter: Benjamin Schollnick | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) |Version: 2.2
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|
---+
I just noticed that Django at idle, using the Dev server, was taking up on
average 10-15% of my CPU.

That seems high, and it appears to be the reload system, using "manage.py
runserver --noreload" dropped it to 0%.

This is consistent, and has occurred over multiple runs of the django app.

I have not added any additional watched folders, and the app was at idle,
awaiting connection.

My research leads me to believe there were changes to formalize the Django
watched folder mechanisms into a formal API.
It's unclear if this is a bug, or just need significant further
optimization.

This is under MOSX 10.14.4, 2.9 Ghz i5, 8 Gb ram.

Python 3.7.2

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

Re: [Django] #30370: Add support for postgresql client certificates and key to dbshell.

2019-04-16 Thread Django

#30370: Add support for postgresql client certificates and key to dbshell.
-+-
 Reporter:  Oleh Mykytyuk|Owner:  Oleh
 Type:   |  Mykytyuk
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell postgresql   | Triage Stage:  Accepted
  certificate|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

Re: [Django] #30370: Add support for postgresql client certificates and key to dbshell.

2019-04-16 Thread Django

#30370: Add support for postgresql client certificates and key to dbshell.
-+-
 Reporter:  Oleh Mykytyuk|Owner:  Oleh
 Type:   |  Mykytyuk
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell postgresql   | Triage Stage:  Accepted
  certificate|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Oleh Mykytyuk):

 Added pull request: https://github.com/django/django/pull/11239/

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

Re: [Django] #27755: add ModelAdmin.get_inlines() hook to allow set inlines based on the request or model instance.

2019-04-16 Thread Django

#27755: add ModelAdmin.get_inlines() hook to allow set inlines based on the 
request
or model instance.
-+-
 Reporter:  WeizhongTu   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  django,admin,inlines   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

Re: [Django] #30352: Error al ejecutar python manage.py sin sealizar cambios

2019-04-16 Thread Django

#30352: Error al ejecutar python manage.py sin sealizar cambios
-+-
 Reporter:  irv-ro-j |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  2.2
  checks)|   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  Reload Django| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks for the report, however I cannot reproduce this issue. You should
 take into account that not all 3rd party packages that you mentioned in a
 ticket description support Django 2.2, e.g. `django-environ`.

 Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].

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

Re: [Django] #14808: i18n is not safe.

2019-04-16 Thread Django

#14808: i18n is not safe.
---+
 Reporter:  Stephen Kelly  |Owner:  Tobias Kunze
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Mariusz Felisiak ):

 In [changeset:"b51842af2642df16505db57bdec8973e464f6822" b51842a]:
 {{{
 #!CommitTicketReference repository=""
 revision="b51842af2642df16505db57bdec8973e464f6822"
 [2.2.x] Fixed #14808 -- Doc'd that trans and blocktrans tags don't escape
 translations.

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

Re: [Django] #14808: i18n is not safe.

2019-04-16 Thread Django

#14808: i18n is not safe.
---+
 Reporter:  Stephen Kelly  |Owner:  Tobias Kunze
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"7d49ad76562e8c0597a0eb66046ab423b12888d8" 7d49ad7]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d49ad76562e8c0597a0eb66046ab423b12888d8"
 Fixed #14808 -- Doc'd that trans and blocktrans tags don't escape
 translations.
 }}}

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

Re: [Django] #30362: Partial indexes and check constraints crash when inherited from abstract models.

2019-04-16 Thread Django

#30362: Partial indexes and check constraints crash when inherited from abstract
models.
-+-
 Reporter:  Tim Dawborn  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  inheritance index| Triage Stage:  Accepted
  name   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 IMO in Django 2.2 we should document that partial indexes and check
 constraints cannot be used in abstract models with many inheriting models;
 and in Django 3.0 we can add a new feature proposed by Simon (separate
 ticket).

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

Re: [Django] #30368: Prefetch related is not working when used GFK for model that uses FK as PK.

2019-04-16 Thread Django

#30368: Prefetch related is not working when used GFK for model that uses FK as 
PK.
-+-
 Reporter:  Vinny Do |Owner:  Vinny Do
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prefetch_related | Triage Stage:  Accepted
  genericforeignkey  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"a4055adf702d086334a9ab2ca25a5e41e896a4fb" a4055adf]:
 {{{
 #!CommitTicketReference repository=""
 revision="a4055adf702d086334a9ab2ca25a5e41e896a4fb"
 Fixed #30368 -- Fixed prefetch_related() for GenericForeignKey when PK is
 also a FK.
 }}}

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

Re: [Django] #14009: custom formset validation documentation is incomplete

2019-04-16 Thread Django

#14009: custom formset validation documentation is incomplete
-+-
 Reporter:  splatEric|Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  formset validation   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c0dc49a7722484484f588b91157a670889046859" c0dc49a7]:
 {{{
 #!CommitTicketReference repository=""
 revision="c0dc49a7722484484f588b91157a670889046859"
 [2.2.x] Fixed #14009 -- Fixed custom formset validation example in docs.

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

Re: [Django] #14009: custom formset validation documentation is incomplete

2019-04-16 Thread Django

#14009: custom formset validation documentation is incomplete
-+-
 Reporter:  splatEric|Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  formset validation   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"d610521bffe9d44a070ebe3a719b474aff6d3d1e" d610521b]:
 {{{
 #!CommitTicketReference repository=""
 revision="d610521bffe9d44a070ebe3a719b474aff6d3d1e"
 Fixed #14009 -- Fixed custom formset validation example 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/088.bb98979292e36b25d3f673f1e071da69%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30370: Add support for postgresql client certificates and key to dbshell.

2019-04-16 Thread Django

#30370: Add support for postgresql client certificates and key to dbshell.
-+-
 Reporter:  Oleh Mykytyuk|Owner:  Oleh
 Type:   |  Mykytyuk
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell postgresql   | Triage Stage:  Accepted
  certificate|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Oleh Mykytyuk):

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

55 matches

Mail list logo