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
-+-
 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):

 I finally solved my problem.

 The problem is: If a user just get a `404` page, a new `CSRF Token` is
 generated,  invalidating the `CSRF Token` that was originally loaded with
 `{% csrf_token %}`.

 **How I've discovered**

 On the WebSite that I work, we have a page  with the URI `/en/courses/`.

 On that page, on the `.html` file we include a JavaScript:  ``

 The `app.js` was trying to load a file named `assets/js/particles.json`
 using the relative path, so the final URL of the static file was
 `/en/courses/assets/js/particles.json`. Load the `particles.json` is the
 only thing that `app.js` was doing. Nothing else.

 That `particles.json` doesn't exist on our system.

 After successfully load `/en/courses/`, the Django Server was receiving a
 request for `/en/courses/assets/js/particles.json` that raises a `404`
 error for the static file, but this error `404` is not even noticed by the
 users because this JS file was doing nothing.

 After I remove this  ``,
 everything worked fine.

 Then with debugs on the `django.middleware.csrf.CsrfViewMiddleware` I
 could confirm that if I reload a page 1000 times, the `CSRF Token`
 returned by `_unsalt_cipher_token`
 
(​https://github.com/django/django/blob/stable/1.11.x/django/middleware/csrf.py#L62)
 is always the same. But if I just try to access a page that doesn't exist,
 then `_unsalt_cipher_token` returns a different value (a new token is
 generated).

 Unbelievable that a single `javascript` that doesn't even exist has broken
 my system and took me 3 days to find out.

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

[Django] #28494: ModelForms calls default on fields that ain't selected.

[Django]

#28494: ModelForms calls default on fields that ain't selected.
-+-
   Reporter:  skruven96  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  1.11
   Severity:  Normal |   Keywords:  ModelForm field
   Triage Stage: |  default
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 Every time you create an instance of MyForm in the example below create_a
 function gets called which creates an instance of ModelA which clutters
 the database with ModelAs.


 {{{

 # models.py
 def create_a():
 return ModelA.objects.create(name='').id

 class ModelA(models.Model):
 pass

 class ModelB(models.Model):
 name = models.CharField(max_length=123)
 reference = models.ForeignKey(ModelA, default=create_a)

 # views.py
 class MyForm(ModelForm):
 class Meta:
 model = ModelB
 fields = ['name']


 }}}

-- 
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.022bbe9ec85927653c53b8cfd6d315f8%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
-+-
 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):

 Tested the system with `Django1.10` and `Django1.11`.

 With `Django1.10` everything works. With `Django1.11` we have the error.

 Do you know where I can see the `diff` (code, not "Release Notes") between
 the two versions of Django (`1.10` and `1.11`)?

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

Re: [Django] #28493: Foreign keys break on migration if models are renamed in a different app

[Django]

#28493: Foreign keys break on migration if models are renamed in a different app
-+-
 Reporter:  Christopher  |Owner:  nobody
  Neugebauer |
 Type:  Uncategorized|   Status:  new
Component:  Migrations   |  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
-+-

Comment (by Christopher Neugebauer):

 n.b. it is possible to make these migrations work by manually adding
 `run_before`, but it seems to me like this *should* be able to run
 automatically.

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

Re: [Django] #27258: Raise an exception if RequestContext is used with template.backends.django.Template.render()

[Django]

#27258: Raise an exception if RequestContext is used with
template.backends.django.Template.render()
-+-
 Reporter:  Andi Albrecht|Owner:  reficul31
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mark Jones):

 And just to add insult to injury I decided I would quit griping and update
 the code to build out it's own Engine instance like so:
 {{{
 from django.template.backends.django import Engine
 from django.template import Context

 engine = Engine(dirs=settings.TEMPLATES[0]['DIRS'],
 app_dirs=True, debug=settings.DEBUG,
 autoescape=False,
 libraries={'deployment_tags':
 'deployment.templatetags.deployment_tags'})
 }}}
 Then I still had to go back and use the Context object anyway
 {{{
 context = Context({"settings": settings,
"sys": sys, "os": os,
"options": options,
"username": getpass.getuser(),
"wsgi_path": wsgi_path,
"ssl": using_ssl,
}, autoescape=False)
 }}}
 Instead of just passing a dict.

 There is  a serious impedance mismatch in the interface around templates
 now.

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

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

Re: [Django] #28493: Foreign keys break on migration if models are renamed in a different app

[Django]

#28493: Foreign keys break on migration if models are renamed in a different app
-+-
 Reporter:  Christopher  |Owner:  nobody
  Neugebauer |
 Type:  Uncategorized|   Status:  new
Component:  Migrations   |  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
-+-
Changes (by Christopher Neugebauer):

 * component:  Uncategorized => Migrations


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

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

Re: [Django] #28493: Foreign keys break on migration if models are renamed in a different app

[Django]

#28493: Foreign keys break on migration if models are renamed in a different app
-+-
 Reporter:  Christopher  |Owner:  nobody
  Neugebauer |
 Type:  Uncategorized|   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 Christopher Neugebauer:

Old description:

> Steps to reproduce:
>
> 1. Create app `a`, with a model called `A`. Run `makemigrations a`
> 2. Create app `b`, with a model called `B`. Give `B` a `ForeignKey` to
> `A`. Run `makemigrations b`
> 3. Rename model `A` to `Aa`. Run `makemigrations a`
> 4. Run `migrate`
>
> Expected behaviour:
>
> The migration completes successfully
>
> Actual behaviour:
>
> Migration `0001` on `b` is run after migration `0002` on `a`, and the
> migration fails with the following error:
>
> `raise ValueError('Related model %r cannot be resolved' %
> self.remote_field.model)
> ValueError: Related model u'a.A' cannot be resolved`

New description:

 Steps to reproduce:

 1. Create app `a`, with a model called `A`. Run `makemigrations a`
 2. Create app `b`, with a model called `B`. Give `B` a `ForeignKey` to
 `A`. Run `makemigrations b`
 3. Rename model `A` to `Aa`. Run `makemigrations a`
 4. Run `migrate`

 Expected behaviour:

 The migration completes successfully

 Actual behaviour:

 Migration `0001` on `b` is run after migration `0002` on `a`, and the
 migration fails with the following error:

 {{{
 raise ValueError('Related model %r cannot be resolved' %
 self.remote_field.model)
 ValueError: Related model u'a.A' cannot be resolved
 }}}

--

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

[Django] #28493: Foreign keys break on migration if models are renamed in a different app

[Django]

#28493: Foreign keys break on migration if models are renamed in a different app
--+
   Reporter:  Christopher Neugebauer  |  Owner:  nobody
   Type:  Uncategorized   | 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   |
--+
 Steps to reproduce:

 1. Create app `a`, with a model called `A`. Run `makemigrations a`
 2. Create app `b`, with a model called `B`. Give `B` a `ForeignKey` to
 `A`. Run `makemigrations b`
 3. Rename model `A` to `Aa`. Run `makemigrations a`
 4. Run `migrate`

 Expected behaviour:

 The migration completes successfully

 Actual behaviour:

 Migration `0001` on `b` is run after migration `0002` on `a`, and the
 migration fails with the following error:

 `raise ValueError('Related model %r cannot be resolved' %
 self.remote_field.model)
 ValueError: Related model u'a.A' cannot be resolved`

-- 
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.5cd82f61f23dce0200aeff9e755e8c37%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
-+-
 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):

 I've created a template tag named `uncypher` that calls
 `_unsalt_cipher_token` as you can see below:
 {{{
 from django.middleware.csrf import _unsalt_cipher_token
 from django.template import Library

 register = Library()


 @register.simple_tag
 def uncypher(token):
 """
 Testing the CSRF problem
 """
 return _unsalt_cipher_token(token)
 }}}
 Then, on a html template I've added
 {{{
 var parser = new DOMParser();
 var csrf = parser.parseFromString("{% csrf_token %}",
 "text/xml").firstChild;
 console.error('token: {% uncypher csrf_token %}');
 }}}

 After set `settings.DEBUG=True` and reload the page 3 times, on the
 `JavaScript Console` was printed the same value
 `lKnMEqisHw8mxMIXZgZTKt9cirypfv1f` on the 3 times that I've reloaded the
 page.

 Then I've set `settings.DEBUG=False` and reloaded the page 4 times again.
 On the first time it printed the same value
 `lKnMEqisHw8mxMIXZgZTKt9cirypfv1f`. On the second
 `YgnNvwBJJwAID17nl7FLhtA3rObtvGLX`,  third time printed
 `hB1plGV688FpDPNu9waO1H959c04YLPM` and fourth time printed
 `C2sJ9e7coe74juO6HxAY4RIppBY4yi1Y`.

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

Re: [Django] #27258: Raise an exception if RequestContext is used with template.backends.django.Template.render()

[Django]

#27258: Raise an exception if RequestContext is used with
template.backends.django.Template.render()
-+-
 Reporter:  Andi Albrecht|Owner:  reficul31
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mark Jones):

 This was never about a RequestContext (although I can see that being a
 problem).  It had to do with a Context being passed to make_context and
 that causing a type error.  The whole point of me passing a Context was to
 specify turn off auto_escape
 {{{
 context = Context({"settings": settings,
"sys": sys, "os": os,
"options": options,
"username": getpass.getuser(),
"wsgi_path": wsgi_path,
"ssl": using_ssl,
},
   autoescape=False)
 }}}

 I'm rendering a text file on the server in a management command where I'm
 selecting the template based on:

 {{{
 servertemplate = loader.select_template(["deployment/%s" %
 options['webserver'],
 "deployment/default_%s" % options['webserver']])

 }}}
 Because Jinja is incapable of using a context, we've broken the ability to
 pass a context.  The fix I proposed was to let that context on thru,
 instead the context is banned and the only way to get autoescape in now is
 to build out a whole template Engine (where the autoescape flag can be
 passed).

 I've never understood people's fascination with jinja templates but
 nothing made me use them.  But now they are actively thwarting me, I begin
 to dislike them.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.f8a9a76afd98e75db8cb90c11e3387c4%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
-+-
 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):

 But even if they are different, the function `_unsalt_cipher_token`
 
(https://github.com/django/django/blob/stable/1.11.x/django/middleware/csrf.py#L62)
 should return always the same value with the different values on the
 Cookie, right?

 I've called the `_unsalt_cipher_token` function with the different values
 of the Cookie, and the returned values are `ALWAYS` different.

-- 
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.142d97aa14be2c0ff8f6e5f93e2247ac%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
-+-
 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):

 Yes, that's expected after 5112e65ef2df1dbb95ff83026b6a962fb2688661.

-- 
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.2506ca5a4b473cead94ddaa338cf%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
-+-
 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):

 I've being testing to reload the page and see the Cookie named
 `csrftoken`.

 On the system that runs with `Django1.8`, every time I reload the page,
 the `csrftoken` Cookie has the same value.

 On the system that runs with `Django1.11`, every time I reload the page,
 the `csrftoken` Cookie has a different value.

 Do you know if on `Django1.11` is expected to have a different
 `csrftoken` Cookie every time I reload the page? If yes, why is expected
 to be different in `Django1.11` and not in `Django1.8`?

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

Re: [Django] #28492: Allow defining expressions' default output_field as a class attribute rather than in __init__() (was: output_field in __init__-method of expressions)

[Django]

#28492: Allow defining expressions' default output_field as a class attribute
rather than in __init__()
-+-
 Reporter:  Mads Jensen  |Owner:  nobody
 Type:   |   Status:  new
  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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * cc: Simon Charette (added)
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Simon has a [https://github.com/django/django/pull/8872 PR] for this.

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

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

Re: [Django] #28491: TypeError: context must be a dict rather than Context.

[Django]

#28491: TypeError: context must be a dict rather than Context.
-+--
 Reporter:  Mark Jones   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Template system  |  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
-+--

Comment (by Tim Graham):

 To fix your code, you should indeed call `render()` with a plaint `dict`
 rather than a `Context`.

 This is related to [https://docs.djangoproject.com/en/stable/releases/1.11
 /#django-template-backends-django-template-render-prohibits-non-dict-
 context a change in Django 1.11] (#27258). Does some documentation need
 clarification?

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

[Django] #28492: output_field in __init__-method of expressions

[Django]

#28492: output_field in __init__-method of expressions
-+-
   Reporter:  Mads   |  Owner:  nobody
  Jensen |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 There are a few expression-classes that override `__init__` just to set
 `output_field`,

 {{{
 class Extent3D(GeoAggregate):

 def __init__(self, expression, **extra):
 super().__init__(expression, output_field=ExtentField(), **extra)
 }}}

 From this comment
 https://github.com/django/django/pull/7611/files#r131567089 `runtests.py`
 needs to be adjusted, so it's possible to use a class-variable for the
 output field instead.

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

[Django] #28491: TypeError: context must be a dict rather than Context.

[Django]

#28491: TypeError: context must be a dict rather than Context.
---+
   Reporter:  Mark Jones   |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  Template system  |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|
---+
 The render method of the Template class looks like this
 {{{
 def render(self, context=None, request=None):
 context = make_context(context, request,
 autoescape=self.backend.engine.autoescape)
 try:
 return self.template.render(context)
 except TemplateDoesNotExist as exc:
 reraise(exc, self.backend)

 }}}

 The docs show this:
 {{{
 >>> from django.template import Context, Template
 >>> template = Template("My name is {{ my_name }}.")

 >>> context = Context({"my_name": "Adrian"})
 >>> template.render(context)
 "My name is Adrian."

 >>> context = Context({"my_name": "Dolores"})
 >>> template.render(context)
 "My name is Dolores."
 }}}

 However make_context looks like this (and throws an exception because of
 it):
 {{{
 if context is not None and not isinstance(context, dict):
 raise TypeError('context must be a dict rather than %s.' %
 context.__class__.__name__)
 if request is None:
 context = Context(context, **kwargs)
 else:
 # The following pattern is required to ensure values from
 # context override those from template context processors.
 original_context = context
 context = RequestContext(request, **kwargs)
 if original_context:
 context.push(original_context)
 return context
 }}}

 I think it needs this code placed before the original code in make_context
 {{{
 if isinstance(context, Context):
 return context
 }}}
 so that if an actual context is passed in, it works as documented.

 This bug only comes about when you select a template using code that looks
 like this:
 {{{
 from django.template import loader, Context
 servertemplate = loader.select_template(["deployment/%s" %
 options['webserver'],
 "deployment/default_%s" % options['webserver']])
 }}}
 because the loader returns an instance of  instead of   which has a different render method
 that causes this problem.

 My change does fix the issue, but I'm not sure if this is the right fix,
 or if there should be another.

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