date:20170811

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

2017-08-11 Thread Django

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  Ruben Alves  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ruben Alves):

 * Attachment "error.png" added.

 Error message on production with settings.DEBUG=False

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

[Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

2017-08-11 Thread Django

I'm using Django1.11 (and made tests also with Django1.11.4) and having
problems when submitting a form with POST method.

I'm calling the `{% csrf_token %}` inside of the form, so, this is not the
problem.
The problem when submitting the form is:

Forbidden (403)
CSRF verification failed. Request aborted.
More information is available with DEBUG=True.

Then, in order to see "more information", I've enabled `settings.DEBUG` to
`True` and submitted the form again. At this moment, the problem didn't
happens anymore.

So I've disabled `settings.DEBUG`, submitted again, and the problem was
there. Enabled `DEBUG=True` again, problem has gone.

Initially I thought that could be some error in my code, but the same
happens when I try to reset my password wit the
`django.contrib.auth.views.password_reset` view.

In my `settings.py`, I have the following changes that were made recently:

`SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')`
`SESSION_COOKIE_SECURE = True`
`CSRF_COOKIE_SECURE = True`

I use AWS (Amazon Web Service) Elastic Beanstalk with https enabled.

The worst part is that I've discovered this only on production because I
make all tests in my local machine with `DEBUG=True`, and on production,
we set `DEBUG=False`.

It's something related to the same error mentioned on Google Groups
[https://groups.google.com/forum/#!searchin/django-

users/CSRF$20verification$20failed.$20Request$20aborted.$20More$20information$20is$20available$20with$20DEBUG$3DTrue.%7Csort:relevance
/django-users/ISoJ6CwHOXQ/pirLih0jBgAJ]

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

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

2017-08-11 Thread Django

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  Ruben Alves  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Ruben Alves:

Old description:

> Hi all,
>
> I'm using Django1.11 (and made tests also with Django1.11.4) and having
> problems when submitting a form with POST method.
>
> I'm calling the `{% csrf_token %}` inside of the form, so, this is not
> the problem.
> The problem when submitting the form is:
>
> Forbidden (403)
> CSRF verification failed. Request aborted.
> More information is available with DEBUG=True.
>
> Then, in order to see "more information", I've enabled `settings.DEBUG`
> to `True` and submitted the form again. At this moment, the problem
> didn't happens anymore.
>
> So I've disabled `settings.DEBUG`, submitted again, and the problem was
> there. Enabled `DEBUG=True` again, problem has gone.
>
> Initially I thought that could be some error in my code,  but the same
> happens when I try to reset my password wit the
> `django.contrib.auth.views.password_reset` view.
>
> In my `settings.py`, I have the following changes that were made
> recently:
>
> `SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')`
> `SESSION_COOKIE_SECURE = True`
> `CSRF_COOKIE_SECURE = True`
>

> I use AWS (Amazon Web Service) Elastic Beanstalk with https enabled.
>
> The worst part is that I've discovered this only on production because I
> make all tests in my local machine with `DEBUG=True`, and on production,
> we set `DEBUG=False`.
>
> It's something related to the same error mentioned on Google Groups
> [https://groups.google.com/forum/#!searchin/django-
> users/CSRF$20verification$20failed.$20Request$20aborted.$20More$20information$20is$20available$20with$20DEBUG$3DTrue.%7Csort:relevance
> /django-users/ISoJ6CwHOXQ/pirLih0jBgAJ]

New description:

 Hi all,

 I'm using Django1.11 (and made tests also with Django1.11.4) and having
 problems when submitting a form with POST method.

 I'm calling the `{% csrf_token %}` inside of the form, so, this is not the
 problem.
 The problem when submitting the form is:

 Forbidden (403)
 CSRF verification failed. Request aborted.
 More information is available with DEBUG=True.

 Then, in order to see "more information", I've enabled `settings.DEBUG` to
 `True` and submitted the form again. At this moment, the problem didn't
 happens anymore.

 So I've disabled `settings.DEBUG`, submitted again, and the problem was
 there. Enabled `DEBUG=True` again, problem has gone.

 Initially I thought that could be some error in my code,  but the same
 happens when I try to reset my password wit the
 `django.contrib.auth.views.password_reset` view.

 In my `settings.py`, I have the following changes that were made recently:

 `SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')`
 `SESSION_COOKIE_SECURE = True`
 `CSRF_COOKIE_SECURE = True`


 I use AWS (Amazon Web Service) Elastic Beanstalk with https enabled.

 The worst part is that I've discovered this only on production because I
 make all tests in my local machine with `DEBUG=True`, and on production,
 we set `DEBUG=False`. Also, the error message should be shown only if
 `DEBUG=True`.

 It's something related to the same error mentioned on Google Groups
 [https://groups.google.com/forum/#!searchin/django-
 
users/CSRF$20verification$20failed.$20Request$20aborted.$20More$20information$20is$20available$20with$20DEBUG$3DTrue.%7Csort:relevance
 /django-users/ISoJ6CwHOXQ/pirLih0jBgAJ]

--

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

Re: [Django] #21021: Default geom_type attribute for GeometryWidget should be "Geometry", not "Unknown"

2017-08-11 Thread Django

#21021: Default geom_type attribute for GeometryWidget should be "Geometry", not
"Unknown"
-+-
 Reporter:  Mathieu Leplatre |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  GIS  |  1.6-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:  minor| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Olivier Tabone):

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

Re: [Django] #28487: runserver crashes with UncodeDecodeError as of Django 1.11.4 (was: Django1.11.4 Cannot run `manage.py runserver` on Windows (UnicodeDecodeError:))

2017-08-11 Thread Django

#28487: runserver crashes with UncodeDecodeError as of Django 1.11.4
-+-
 Reporter:  newerBkl |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.11
  commands)  |
 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 Tim Graham):

 * cc: Mark Rogaski (added)


Comment:

 What's the key/value of the environment variable that's causing the crash?

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

Re: [Django] #28451: Change in Oracle sequence name truncation causes regression when updating existing database

2017-08-11 Thread Django

#28451: Change in Oracle sequence name truncation causes regression when
updating
existing database
-+-
Reporter: Kevin Grinberg |Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: oracle | Triage Stage: Accepted
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+-
Changes (by Shai Berger):

* cc: Shai Berger (added)

Comment:

I concur. Note that the change makes the names shorter than necessary --
the idea behind using `self.max_name_length() - 3` is to save space for
the `_SQ` suffix, but the change now includes that suffix in the truncated
text.

I also think we should similarly revert the analogous change in trigger
name truncation. I'm not sure we ever use calculated trigger names after
the trigger is created, however,
* if we do, then the same considerations as with sequences apply
* if we don't, then it's better to have consistent code and use the full
available name length

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

Re: [Django] #28459: Improve performance of QuerySet

2017-08-11 Thread Django

#28459: Improve performance of QuerySet
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"5cc746206726c538c36a2830e7c068f1c8a0e7c8" 5cc74620]:
 {{{
 #!CommitTicketReference repository=""
 revision="5cc746206726c538c36a2830e7c068f1c8a0e7c8"
 Refs #28459 -- Optimized ModelState instantiation.
 }}}

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

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

2017-08-11 Thread Django

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  Ruben Alves  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ruben Alves):

 Ok, I've added some logs on `django.middleware.csrf`, and this is what I
 have:

 Between lines 208 and 209
 
(https://github.com/django/django/blob/stable/1.11.x/django/middleware/csrf.py#L208)
 I've added a log and the value of `csrf_token` is
 `vcdodHkRb8jlxQP5fnTjuQp5i3PMWYYEBOYfpOFkCEjWWwHMpJ9uqaPGI6vGi6hS`

 The `if request.is_secure():` is `True` on line 228
 
(https://github.com/django/django/blob/stable/1.11.x/django/middleware/csrf.py#L228)


 The value of  `request_csrf_token` on line 311
 
(https://github.com/django/django/blob/stable/1.11.x/django/middleware/csrf.py#L311)
 before we call `request_csrf_token = _sanitize_token(request_csrf_token)`
 is `tMgl4aTrdjOEShUax3Gz1CJLbvnhBWiEVzmzgTxSclDuP01lBfwoE2R6dDyljaCQ`

 After `_sanitize_token` be called, the value of `request_csrf_token` is
 the same, and the value of `csrf_token` is
 `vcdodHkRb8jlxQP5fnTjuQp5i3PMWYYEBOYfpOFkCEjWWwHMpJ9uqaPGI6vGi6hS`.

 Finally `_compare_salted_tokens(request_csrf_token, csrf_token)` on line
 313 returns `False`
 
(https://github.com/django/django/blob/stable/1.11.x/django/middleware/csrf.py#L313).

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

Re: [Django] #28456: Defining getstate in class derived from Model doesn't affect model pickling

2017-08-11 Thread Django

#28456: Defining __getstate__ in class derived from Model doesn't affect model
pickling
-+-
 Reporter:  Nerl~|Owner:  Nerl~
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Pickle, Models   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"97cb3bd16d8e50d96eb184f8d67dd1723f776d2a" 97cb3bd1]:
 {{{
 #!CommitTicketReference repository=""
 revision="97cb3bd16d8e50d96eb184f8d67dd1723f776d2a"
 Fixed #28456 -- Allowed customizing Model pickling by overriding
 __getstate__().
 }}}

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

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

2017-08-11 Thread Django

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  Ruben Alves  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 The traceback doesn't give me any ideas about the cause. I think you'll
 need to add further logging in `django/middleware/csrf.py` to find the
 root cause.

 A large CSRF change between Django 1.8 and 1.11 is
 5112e65ef2df1dbb95ff83026b6a962fb2688661. Perhaps you can test with Django
 1.9 and 1.10 to help narrow the problem.

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

Re: [Django] #28252: Translation documentation on default file extensions differ from makemessages --help output

2017-08-11 Thread Django

#28252: Translation documentation on default file extensions differ from
makemessages --help output
-+-
 Reporter:  Markus Amalthea  |Owner:  Jonatas
  Magnuson   |  CD
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"31f133ea08d41907a67f9e3d667f2a09c167a97c" 31f133e]:
 {{{
 #!CommitTicketReference repository=""
 revision="31f133ea08d41907a67f9e3d667f2a09c167a97c"
 Fixed #28252 -- Corrected docs for default file extensions of
 makemessages.
 }}}

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

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

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

2017-08-11 Thread Django

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  Ruben Alves  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ruben Alves):

 Before Django1.11, I was using Django 1.8 and everything was working
 perfectly.

 In order to use Django1.11, I did all the changes mentioned on
 https://docs.djangoproject.com/en/1.11/releases/1.11/

 What I've done now was add `settings.CSRF_FAILURE_VIEW =
 'courses.views.csrf_failure'` with `DEBUG=False`

 I made my `courses.views.csrf_failure` raise an exception, so we could see
 the traceback.

 The traceback is the following:



 File "/opt/python/run/venv/lib64/python2.7/site-
 packages/django/core/handlers/exception.py" in inner
   41. response = get_response(request)

 File "/opt/python/run/venv/lib64/python2.7/site-
 packages/django/core/handlers/base.py" in _legacy_get_response
   249. response = self._get_response(request)

 File "/opt/python/run/venv/lib64/python2.7/site-
 packages/django/core/handlers/base.py" in _get_response
   178. response = middleware_method(request, callback,
 callback_args, callback_kwargs)

 File "/opt/python/run/venv/lib64/python2.7/site-
 packages/django/middleware/csrf.py" in process_view
   314. return self._reject(request, REASON_BAD_TOKEN)

 File "/opt/python/run/venv/lib64/python2.7/site-
 packages/django/middleware/csrf.py" in _reject
   163. return _get_failure_view()(request, reason=reason)

 File "/opt/python/current/app/courses/views/__init__.py" in csrf_failure
   49. raise Exception('Lets see where this shit works:' +
 str(locals()))

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

Re: [Django] #28451: Change in Oracle sequence name truncation causes regression when updating existing database

2017-08-11 Thread Django

#28451: Change in Oracle sequence name truncation causes regression when 
updating
existing database
-+-
 Reporter:  Kevin Grinberg   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Kevin Grinberg):

 Shai/Felix: do you think it's critical to provide a migration script as
 part of the fix?

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

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

Re: [Django] #28470: Document additional system requirements for unit tests

2017-08-11 Thread Django

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

Comment:

I think the paragraph the follows your proposed addition is good enough
advice:

Installing the requirements will likely require some operating system
packages that your computer doesn't have installed. You can usually figure
out which package to install by doing a Web search for the last line or so
of the error message. Try adding your operating system to the search query
if needed.

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

Re: [Django] #28421: Split up long formset tests

2017-08-11 Thread Django

#28421: Split up long formset tests
-+-
 Reporter:  Windson yang |Owner:  Windson
 Type:   |  yang
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"d04b324969e045d1cf2bf7da18ea0497d8066935" d04b3249]:
 {{{
 #!CommitTicketReference repository=""
 revision="d04b324969e045d1cf2bf7da18ea0497d8066935"
 Fixed #28421 -- Split some long FormSet tests and made other cosmetic
 cleanups.

 Thanks Windson for the initial patch.
 }}}

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

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

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

2017-08-11 Thread Django

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  rubenanapu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Did you experience a change in Django 1.11 compared to Django 1.10 or
 earlier? I think you'll need to debug the problem further and let us know
 why Django is at fault.

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

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

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

2017-08-11 Thread Django

#28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG 
is
False
-+-
 Reporter:  Ruben Alves  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf failed  | Triage Stage:
  settings debug false production|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Maybe you can try to minimize the middleware, etc. in your project and see
 if something like that is causing the 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/068.80ed4476c94f05b3fcab5b5f37212b39%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28252: Translation documentation on default file extensions differ from makemessages --help output

2017-08-11 Thread Django

#28252: Translation documentation on default file extensions differ from
makemessages --help output
-+-
 Reporter:  Markus Amalthea  |Owner:  Jonatas
  Magnuson   |  CD
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"b0ed14644a10dc8263e02b7f075e31169b450ea7" b0ed146]:
 {{{
 #!CommitTicketReference repository=""
 revision="b0ed14644a10dc8263e02b7f075e31169b450ea7"
 [1.11.x] Fixed #28252 -- Corrected docs for default file extensions of
 makemessages.

 Backport of 31f133ea08d41907a67f9e3d667f2a09c167a97c 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/073.75471e334f3d6ae96702b36b04a0ff16%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28489: AttributeError: 'NoneType' object has no attribute 'is_relation' - None is undefined

2017-08-11 Thread Django

#28489: AttributeError: 'NoneType' object has no attribute 'is_relation' - None 
is
undefined
+
   Reporter:  Python Force  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Migrations|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 |
+
 Hello,

 Was going from Django version 1.10.7 to 1.11.4 and my migrations were
 working in 1.10.7 and stopped in 1.11.4. All my migrations were migrated
 before the upgrade. I went back to 1.10.7 and it was working again. Going
 back to 1.11.4 same error.

 {{{
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 363, in
 execute_from_command_line
 utility.execute()
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 355, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 330, in execute
 output = self.handle(*args, **options)
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 163, in handle
 pre_migrate_state =
 executor._create_project_state(with_applied_migrations=True)
   File "/[...]/venv/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 81, in
 _create_project_state
 migration.mutate_state(state, preserve=False)
   File "[...]/venv/lib/python2.7/site-
 packages/django/db/migrations/migration.py", line 92, in mutate_state
 operation.state_forwards(self.app_label, new_state)
   File "[...]/venv/lib/python2.7/site-
 packages/django/db/migrations/operations/fields.py", line 150, in
 state_forwards
 delay = not old_field.is_relation
 AttributeError: 'NoneType' object has no attribute 'is_relation'
 }}}

 When I look in the fields.py file I can see on the line 139 a function:

 {{{
 def state_forwards(self, app_label, state):
 new_fields = []
 old_field = None
 for name, instance in state.models[app_label,
 self.model_name_lower].fields:
 if name != self.name:
 new_fields.append((name, instance))
 else:
 old_field = instance
 state.models[app_label, self.model_name_lower].fields = new_fields
 # Delay rendering of relationships if it's not a relational field
 delay = not old_field.is_relation
 state.reload_model(app_label, self.model_name_lower, delay=delay)
 }}}

 Found out that it was crashing on 1 of the model fields that are not
 existing anymore in the database. I added a line to print the name of the
 model and field to find out what is causing the crash.

 If old_field = None then it is calling a method on empty variable and it
 throws and error.

 Added this line

 {{{
 print app_label + " " + self.model_name_lower + " " + self.name
 }}}

 {{{
 def state_forwards(self, app_label, state):
 new_fields = []
 old_field = None
 print app_label + " " + self.model_name_lower + " " + self.name
 for name, instance in state.models[app_label,
 self.model_name_lower].fields:
 if name != self.name:
 new_fields.append((name, instance))
 else:
 old_field = instance
 state.models[app_label, self.model_name_lower].fields = new_fields
 # Delay rendering of relationships if it's not a relational field
 delay = not old_field.is_relation
 state.reload_model(app_label, self.model_name_lower, delay=delay)
 }}}

 The Output was

 {{{
 cars video subtitle_url
 cars photos gear
 cars news tags
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 363, in
 execute_from_command_line
 utility.execute()
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 355, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "[...]/venv/lib/python2.7/site-
 packages/django/core/management/base.py", line 330, in execute
 output = self.handle(*args, **options)
   File "[...]/venv/lib/python2.7/site-

Re: [Django] #28459: Improve performance of QuerySet

2017-08-11 Thread Django

#28459: Improve performance of QuerySet
-+-
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"47ccefeada926ffbccaa354dec7a987a7e7ca701" 47ccefea]:
 {{{
 #!CommitTicketReference repository=""
 revision="47ccefeada926ffbccaa354dec7a987a7e7ca701"
 Refs #28459 -- Improved performance of BaseExpression.convert_value().
 }}}

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

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

Re: [Django] #27855: Document Python 3.4 support for Django 2.0

2017-08-11 Thread Django

#27855: Document Python 3.4 support for Django 2.0
-+-
 Reporter:  Raffaele Salmaso |Owner:  Raffaele
 Type:   |  Salmaso
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  2.0  | 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 GitHub ):

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


Comment:

 In [changeset:"abd723c6a010be1bc06687d21e8841e07af6fde3" abd723c6]:
 {{{
 #!CommitTicketReference repository=""
 revision="abd723c6a010be1bc06687d21e8841e07af6fde3"
 Fixed #27855 -- Updated docs for Python 3.4 support in Django 2.0.
 }}}

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

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

Re: [Django] #27855: Document Python 3.4 support for Django 2.0

2017-08-11 Thread Django

#27855: Document Python 3.4 support for Django 2.0
-+-
 Reporter:  Raffaele Salmaso |Owner:  Raffaele
 Type:   |  Salmaso
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  2.0  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"bca1ffc87afaff83072030890894a73d3e2478e8" bca1ffc8]:
 {{{
 #!CommitTicketReference repository=""
 revision="bca1ffc87afaff83072030890894a73d3e2478e8"
 [1.11.x] Fixed #27855 -- Updated docs for Python 3.4 support in Django
 2.0.

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

Re: [Django] #27318: Return failed values from memcached.set_many()

2017-08-11 Thread Django

#27318: Return failed values from memcached.set_many()
-+-
 Reporter:  Florent Fourcot  |Owner:  Olivier
 Type:   |  Tabone
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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

Re: [Django] #28252: Translation documentation on default file extensions differ from makemessages --help output

2017-08-11 Thread Django

#28252: Translation documentation on default file extensions differ from
makemessages --help output
-+-
 Reporter:  Markus Amalthea  |Owner:  Jonatas
  Magnuson   |  CD
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.11
 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 Jonatas CD):

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

Re: [Django] #28252: Translation documentation on default file extensions differ from makemessages --help output

2017-08-11 Thread Django

#28252: Translation documentation on default file extensions differ from
makemessages --help output
-+-
 Reporter:  Markus Amalthea  |Owner:  Jonatas
  Magnuson   |  CD
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.11
 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 Jonatas CD):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8893 PR] created.

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

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

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

[Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

Re: [Django] #21021: Default geom_type attribute for GeometryWidget should be "Geometry", not "Unknown"

Re: [Django] #28487: runserver crashes with UncodeDecodeError as of Django 1.11.4 (was: Django1.11.4 Cannot run `manage.py runserver` on Windows (UnicodeDecodeError:))

Re: [Django] #28451: Change in Oracle sequence name truncation causes regression when updating existing database

Re: [Django] #28459: Improve performance of QuerySet

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

Re: [Django] #28456: Defining getstate in class derived from Model doesn't affect model pickling

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

Re: [Django] #28252: Translation documentation on default file extensions differ from makemessages --help output

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

Re: [Django] #28451: Change in Oracle sequence name truncation causes regression when updating existing database

Re: [Django] #28470: Document additional system requirements for unit tests

Re: [Django] #28421: Split up long formset tests

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

Re: [Django] #28488: Django 1.11 to 1.11.4 raises CSRF verification failed if settings.DEBUG is False

Re: [Django] #28252: Translation documentation on default file extensions differ from makemessages --help output

[Django] #28489: AttributeError: 'NoneType' object has no attribute 'is_relation' - None is undefined

Re: [Django] #28459: Improve performance of QuerySet

Re: [Django] #27855: Document Python 3.4 support for Django 2.0

Re: [Django] #27855: Document Python 3.4 support for Django 2.0

Re: [Django] #27318: Return failed values from memcached.set_many()

Re: [Django] #28252: Translation documentation on default file extensions differ from makemessages --help output

Re: [Django] #28252: Translation documentation on default file extensions differ from makemessages --help output

25 matches

Site Navigation

Mail list logo

Footer information