Re: [Django] #29199: Oracle backend won't connect if password contains '@'

[Django]

#29199: Oracle backend won't connect if password contains '@'
-+-
 Reporter:  Shane Allgeier   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   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 felixxm):

 * status:  new => assigned
 * owner:  nobody => felixxm
 * version:  2.0 => master
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #29205: MultiValueField ignores a required value of a sub field

[Django]

#29205: MultiValueField ignores a required value of a sub field
+--
 Reporter:  Takayuki Hirai  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  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 Takayuki Hirai:

Old description:

> A field and a form definition:
>
> {{{
> #!python
> from django.forms import (
> Form,
> CharField,
> MultiValueField,
> MultiWidget,
> )
>

> class MF(MultiValueField):
> widget = MultiWidget
>
> def __init__(self):
> fields = [
> CharField(required=False),
> CharField(required=True),
> ]
> widget = self.widget(widgets=[
> f.widget
> for f in fields
> ], attrs={})
> super(MF, self).__init__(
> fields=fields,
> widget=widget,
> require_all_fields=False,
> required=False,
> )
>
> def compress(self, value):
> return []
>

> class F(Form):
> mf = MF()
> }}}
>
> When the form is passed empty values for both sub fields,
> {{{form.is_valid() == True}}}.
> But I expected {{{is_valid()}}} returns False, because one of the sub
> fields is set as required.
>
> {{{
> #!python
>
> f = F({
> 'mf_0': '',
> 'mf_1': '',
> })
> assert f.is_valid() == True  # I expect this should return False
> }}}
>
> On the other hand, When one of its sub field is passed a non-empty value,
> {{{form.is_valid() == False}}}
>
> {{{
> #!python
>
> f = F({
> 'mf_0': ''xxx,
> 'mf_1': '',
> })
> assert f.is_valid() == Flase
> }}}
>
> If above behavior is not expected, please fix this problem.

New description:

 A field and a form definition:

 {{{
 #!python
 from django.forms import (
 Form,
 CharField,
 MultiValueField,
 MultiWidget,
 )


 class MF(MultiValueField):
 widget = MultiWidget

 def __init__(self):
 fields = [
 CharField(required=False),
 CharField(required=True),
 ]
 widget = self.widget(widgets=[
 f.widget
 for f in fields
 ], attrs={})
 super(MF, self).__init__(
 fields=fields,
 widget=widget,
 require_all_fields=False,
 required=False,
 )

 def compress(self, value):
 return []


 class F(Form):
 mf = MF()
 }}}

 When the form is passed empty values for both sub fields,
 {{{form.is_valid() == True}}}.
 But I expected {{{is_valid()}}} returns False, because one of the sub
 fields is set as required.

 {{{
 #!python

 f = F({
 'mf_0': '',
 'mf_1': '',
 })
 assert f.is_valid() == True  # I expect this should return False
 }}}

 On the other hand, When one of its sub field is passed a non-empty value,
 {{{form.is_valid() == False}}}

 {{{
 #!python

 f = F({
 'mf_0': 'xxx',
 'mf_1': '',
 })
 assert f.is_valid() == Flase
 }}}

 If above behavior is not expected, please fix this 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/064.abc88dc69e906182f7686b318510bd4b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29205: MultiValueField ignores a required value of a sub field

[Django]

#29205: MultiValueField ignores a required value of a sub field
--+
   Reporter:  Takayuki Hirai  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |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   |
--+
 A field and a form definition:

 {{{
 #!python
 from django.forms import (
 Form,
 CharField,
 MultiValueField,
 MultiWidget,
 )


 class MF(MultiValueField):
 widget = MultiWidget

 def __init__(self):
 fields = [
 CharField(required=False),
 CharField(required=True),
 ]
 widget = self.widget(widgets=[
 f.widget
 for f in fields
 ], attrs={})
 super(MF, self).__init__(
 fields=fields,
 widget=widget,
 require_all_fields=False,
 required=False,
 )

 def compress(self, value):
 return []


 class F(Form):
 mf = MF()
 }}}

 When the form is passed empty values for both sub fields,
 {{{form.is_valid() == True}}}.
 But I expected {{{is_valid()}}} returns False, because one of the sub
 fields is set as required.

 {{{
 #!python

 f = F({
 'mf_0': '',
 'mf_1': '',
 })
 assert f.is_valid() == True  # I expect this should return False
 }}}

 On the other hand, When one of its sub field is passed a non-empty value,
 {{{form.is_valid() == False}}}

 {{{
 #!python

 f = F({
 'mf_0': ''xxx,
 'mf_1': '',
 })
 assert f.is_valid() == Flase
 }}}

 If above behavior is not expected, please fix this 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/049.32fc11e2458bb9457bfcf6c976cb07d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29200: RadioSelect does not render its label in MultiWidget

[Django]

#29200: RadioSelect does not render its label in MultiWidget
+--
 Reporter:  Takayuki Hirai  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  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 Takayuki Hirai):

 * type:  Uncategorized => Bug


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

Re: [Django] #29203: Cached Session may cause losing a session, when it failed to connect to cache backend

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect to
cache backend
-+-
 Reporter:  Kenial Sookyum Lee   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  session cookie,  | Triage Stage:
  cached session |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Kenial Sookyum Lee):

 * version:  master => 1.11


Old description:

> Some cache backends (AFAIK Memcached and Redis) has a feature to ignore
> connection timeout exception, in order to ensure Django application
> working even if cache has failed. This can lead a subtle bug, deleting a
> session cookie. Following steps are reproduce this bug:
>
> - Set cached session for Django session (refer to
> https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
> sessions)
> - On Django app, try to log in or set a language in order to make a
> session cookie. At this step, cache nodes should be available.
> - To set cache nodes **unavailable**, by changing to wrong node name or
> turning the nodes off.
> - Reload a page on Django app. Django app responds back with this HTTP
> header, which deletes a session cookie:
> {{{
> Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
> Age=0; Path=/
> }}}
>
> The problematic codes are at django/contrib/sessions/middleware.py:37 :
> {{{
>  def process_response(self, request, response):
> """
> If request.session was modified, or if the configuration is to
> save the
> session every time, save the changes and set a session cookie or
> delete
> the session cookie if the session has been emptied.
> """
> try:
> accessed = request.session.accessed
> modified = request.session.modified
> empty = request.session.is_empty()
> except AttributeError:
> pass
> else:
> # First check if we need to delete this cookie.
> # The session should be deleted only if the session is
> entirely empty
> if settings.SESSION_COOKIE_NAME in request.COOKIES and empty:
> # NEED TO UPDATE!
> response.delete_cookie(
> settings.SESSION_COOKIE_NAME,
> path=settings.SESSION_COOKIE_PATH,
> domain=settings.SESSION_COOKIE_DOMAIN,
> )
> ...
> }}}
>
> I guess the initial intention was to delete a session if there is no
> values in it. However, it happens that code execution reaches at :37 that
> code without exception, even if cache nodes are unavailable. The reason
> is, I already explained above, they just work that way even if the cache
> backend failed.
>
> I first met this bug while I was testing failover of AWS Elasticache
> (Redis). I was in testing of failover scenario, but Django application
> got me logged out repeatedly, even though session data itself is
> remaining in the cache replica. (it should, because it was doing
> failover, not reboot)
>
> IMHO, before checking ''empty'' of session data, there should be a logic
> to check cache backend is actually available. I found out
> ''request.session.cache_key'' can do that function, but it looks less
> explicit. Please show be a better way to do this, if you have one.

New description:

 Some cache backends (AFAIK Memcached and Redis) has a feature to ignore
 connection timeout exception, in order to ensure Django application
 working even if cache has failed. This can lead a subtle bug, deleting a
 session cookie. Following steps are reproduce this bug:

 - Set cached session for Django session (refer to
 https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
 sessions)
 - On Django app, try to log in or set a language in order to make a
 session cookie. At this step, cache nodes should be available.
 - To set cache nodes **unavailable**, by changing to wrong node name or
 turning the nodes off.
 - Reload a page on Django app. Django app responds back with this HTTP
 header, which deletes a session cookie:
 {{{
 Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
 Age=0; Path=/
 }}}

 The problematic codes are at django/contrib/sessions/middleware.py:37 :
 {{{
  def process_response(self, request, response):
 """
 If request.session was modified, or if the configuration is to
 save the
 session every time, save the changes and set a session cookie or
 delete
 the 

Re: [Django] #29203: Cached Session may cause losing a session, when it failed to connect to cache backend

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect to
cache backend
-+-
 Reporter:  Kenial Sookyum Lee   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  session cookie,  | Triage Stage:
  cached session |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Kenial Sookyum Lee):

 When I tested the settings with SESSION_ENGINE =
 "django.contrib.sessions.backends.cached_db" (ie. 'write-through cache'),
 I didn't get through this bug. Configuration is: Django 1.11, MySQL
 5.6.35, mysqlclient 1.3.12, Redis 3.2.7 (x64), django-redis 4.9.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.b0e7436ac91997ea76ee583eef3526b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29204: Problems with Django and timezone

[Django]

#29204: Problems with Django and timezone
-+
   Reporter:  ovalseven8 |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 First of all my settings.py:

 {{{
 LANGUAGE_CODE = 'de-DE'

 TIME_ZONE = 'Europe/Berlin'

 USE_I18N = True

 USE_L10N = True

 USE_TZ = True
 }}}

 Also, I have a model with one DateTimeField:

 {{{
 from django.utils import timezone

 class CustomModel(models.Model):
time = models.DateTimeField(default=timezone.now, editable=False)
 }}}

 However, I have a problem in my admin: It's ~ 22:00 now (my local time).
 When I create an instance of CustomModel, it looks so in the admin page:
 [[Image(https://i.imgur.com/GGUuCsZ.png)]]

 You can see the inconsistency? **I do not know if the time is saved
 correctly because it's 22:00 in my time zone.**

 Now look, if I change my CustomModel:

 {{{
 class CustomModel(models.Model):
 time = models.DateTimeField(auto_now_add=True)
 }}}

 The admin page looks so now (no inconsistencies anymore!). **However, it's
 22:12 in my time zone now.**
 [[Image(https://i.imgur.com/H4IV0e5.png)]]

 So there is definitely a bug somewhere.

 Anyway, I have a question:
 What should I do, is the time saved correctly and only the display wrong?

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

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

[Django]

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  Daniel Menzel|Owner:  Dan
 |  Watson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Replying to [comment:28 Tim Graham]:
 > Is there a disadvantage to waiting to revert
 51673c146e48ff6230eace39bac18fd555607bee until after Python 2 is end-of-
 life in 2020? I'm not really sure, but ignoring of pyc files may still
 have some value as long as third-party apps  support Python 2 and 3.

 I can't quite see how an issue would come up (given that this would go
 into Django 2.1, which is Python 3 only) but I can't rule it out either.
 (There's nothing so weird and wonderful as programming. :)

 There's no disadvantage really. Dan's PR is clean enough. If we're not
 going to revert 51673c14 (and not go for wontfix) I think we should re-
 open the PR and treat it as Ready for checkin, for a final review from
 you. (I was at the point of marking it so, bar the revert option coming
 up.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from 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.61e221f1cb1a340df970cd52ea26348a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29189: BoundField: extra css classes

[Django]

#29189: BoundField: extra css classes
-+--
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  2.0
 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 James Pic):

 We can try to make a proposal in Django but currently in adapters the
 proposal is:

 {{{

 # Time to show off for some user love !
 assert
 a.adapters.add('elementui.Form').steps.render().payload.rendered == ''

 # So yeah, this kind of presentational adapters will love visiting a's
 map
 # and add()'s adapters the see fit !
 assert
 a.adapters.add('googlemdc.Form').steps.render().payload.rendered == ''

 # Let's just make an HTTP response !
 assert
 
a.adapters.add('googlemdc.Form').add('django.ProcessFormResponse').steps.process().payload.response

 }}}

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

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

[Django]

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  Daniel Menzel|Owner:  Dan
 |  Watson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Is there a disadvantage to waiting to revert
 51673c146e48ff6230eace39bac18fd555607bee until after Python 2 is end-of-
 life in 2020? I'm not really sure, but ignoring of pyc files may still
 have some value as long as third-party apps  support Python 2 and 3.

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

Re: [Django] #29189: BoundField: extra css classes

[Django]

#29189: BoundField: extra css classes
-+--
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  2.0
 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 James Pic):

 I just don't understand how to properly override how a form field
 container renders in Django ... i hoped the new forms rendering API would
 help but i don't understand how ... i see many external libraries do this
 ... but we should probably not  invest in this as there's currently a
 second breath in django-adapters let's see if that's a better way to spend
 our time

 best regards friend

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

Re: [Django] #29189: BoundField: extra css classes

[Django]

#29189: BoundField: extra css classes
-+--
 Reporter:  James Pic|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  2.0
 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):

 Could you elaborate on your proposal? I'm not sure exactly what it means.

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

Re: [Django] #29188: ContentFile.size remains constant after initializing

[Django]

#29188: ContentFile.size remains constant after initializing
-+-
 Reporter:  Maksim Iakovlev  |Owner:  Alex
 |  Stovbur
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.11
  uploads/storage|
 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:"2d9ec4d735871b44c7a05d6e0aa3f92763f667f5" 2d9ec4d7]:
 {{{
 #!CommitTicketReference repository=""
 revision="2d9ec4d735871b44c7a05d6e0aa3f92763f667f5"
 Fixed #29188 -- Fixed ContentFile.size after a write().
 }}}

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

Re: [Django] #29195: Postgres Regression, annotating Exists through a OuterRef query.

[Django]

#29195: Postgres Regression, annotating Exists through a OuterRef query.
-+-
 Reporter:  Oli Warner   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   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:"277ed072094ad87fc6b2c4669f21d43b1f39043c" 277ed072]:
 {{{
 #!CommitTicketReference repository=""
 revision="277ed072094ad87fc6b2c4669f21d43b1f39043c"
 Fixed #29195 -- Fixed Exists.output_field resolution on single-valued
 queries.

 The Subquery class which Exists inherits from defaulted to using single-
 valued
 querie's field if no output_field was explicitly specified on
 initialization
 which was bypassing the Exists.output_field defined at the class level.

 Moving Subquery's dynamic output_field resolution to _resolve_output_field
 should make sure the fallback logic is only performed if required.

 Regression in 08654a99bbdd09049d682ae57cc94241534b29f0.

 Thanks Oli Warner for the detailed report.
 }}}

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

Re: [Django] #29195: Postgres Regression, annotating Exists through a OuterRef query.

[Django]

#29195: Postgres Regression, annotating Exists through a OuterRef query.
-+-
 Reporter:  Oli Warner   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   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:"0fd21febe7b3969460e3e6f17bfedc63529f194b" 0fd21feb]:
 {{{
 #!CommitTicketReference repository=""
 revision="0fd21febe7b3969460e3e6f17bfedc63529f194b"
 [2.0.x] Fixed #29195 -- Fixed Exists.output_field resolution on single-
 valued queries.

 The Subquery class which Exists inherits from defaulted to using single-
 valued
 querie's field if no output_field was explicitly specified on
 initialization
 which was bypassing the Exists.output_field defined at the class level.

 Moving Subquery's dynamic output_field resolution to _resolve_output_field
 should make sure the fallback logic is only performed if required.

 Regression in 08654a99bbdd09049d682ae57cc94241534b29f0.

 Thanks Oli Warner for the detailed report.

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

Re: [Django] #29183: "cache" template tag should not render empty strings on failure

[Django]

#29183: "cache" template tag should not render empty strings on failure
-+-
 Reporter:  Nicolas Le Manchet   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Cache system)  |  Version:  2.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  cache, template, | Triage Stage:
  memcached, pylibmc |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Marking as invalid since the cache template tag doesn't have the reported
 behavior.

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

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

Re: [Django] #29190: timezone.is_aware() raises unhandled exception when receiving datetime.date object as argument

[Django]

#29190: timezone.is_aware() raises unhandled exception when receiving 
datetime.date
object as argument
-+-
 Reporter:  Dariem Pérez |Owner:  nobody
  Herrera|
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  timezone date| Triage Stage:
  datetime   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


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

Re: [Django] #29197: TemplateDoesNotExist: postgres/widgets/split_array.html

[Django]

#29197: TemplateDoesNotExist: postgres/widgets/split_array.html
-+-
 Reporter:  linluc   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  2.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  postgres template| Triage Stage:
  SplitArrayWidget   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => contrib.postgres
 * resolution:   => invalid
 * status:  new => closed
 * type:  Uncategorized => Bug


Comment:

 Probably you don't have `django.contrib.postgres` in your
 `INSTALLED_APPS`, or you've otherwise incorrectly configured
 [https://docs.djangoproject.com/en/stable/ref/forms/renderers/ widget
 rendering].

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

Re: [Django] #29203: Cached Session may cause losing a session, when it failed to connect to cache backend

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect to
cache backend
-+-
 Reporter:  Kenial Sookyum Lee   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  session cookie,  | Triage Stage:
  cached session |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Kenial Sookyum Lee:

Old description:

> Some cache backends (AFAIK Memcached and Redis) has a feature to ignore
> connection timeout exception, in order to ensure Django application
> working even if cache has failed. This can lead a subtle bug, deleting a
> session cookie. Following steps are reproduce this bug:
>
> - Set cached session for Django session (refer to
> https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
> sessions)
> - On Django app, try to log in or set a language in order to make a
> session cookie. At this step, cache nodes should be available.
> - To set cache nodes **unavailable**, by changing to wrong node name or
> turning the nodes off.
> - Reload a page on Django app. Django app responds back with this HTTP
> header, which deletes a session cookie:
> {{{
> Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
> Age=0; Path=/
> }}}
>
> The problematic codes are at django/contrib/sessions/middleware.py:37 :
> {{{
>  def process_response(self, request, response):
> """
> If request.session was modified, or if the configuration is to
> save the
> session every time, save the changes and set a session cookie or
> delete
> the session cookie if the session has been emptied.
> """
> try:
> accessed = request.session.accessed
> modified = request.session.modified
> empty = request.session.is_empty()
> except AttributeError:
> pass
> else:
> # First check if we need to delete this cookie.
> # The session should be deleted only if the session is
> entirely empty
> if settings.SESSION_COOKIE_NAME in request.COOKIES and empty:
> response.delete_cookie(
> settings.SESSION_COOKIE_NAME,
> path=settings.SESSION_COOKIE_PATH,
> domain=settings.SESSION_COOKIE_DOMAIN,
> )
> ...
> }}}
>
> I guess the initial intention was to delete a session if there is no
> values in it. However, it happens that code execution reaches at that
> code without exception, even if cache nodes are unavailable. The reason
> is, I already explained above, they just work that way even if the cache
> backend failed.
>
> I first met this bug while I was testing failover of AWS Elasticache
> (Redis). I was in testing of failover scenario, but Django application
> got me logged out repeatedly, even though session data itself is
> remaining in the cache replica. (it should, because it was doing
> failover, not reboot)
>
> IMHO, before checking ''empty'' of session data, there should be a logic
> to check cache backend is actually available. I found out
> ''request.session.cache_key'' can do that function, but it looks less
> explicit. Please show be a better way to do this, if you have one.

New description:

 Some cache backends (AFAIK Memcached and Redis) has a feature to ignore
 connection timeout exception, in order to ensure Django application
 working even if cache has failed. This can lead a subtle bug, deleting a
 session cookie. Following steps are reproduce this bug:

 - Set cached session for Django session (refer to
 https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
 sessions)
 - On Django app, try to log in or set a language in order to make a
 session cookie. At this step, cache nodes should be available.
 - To set cache nodes **unavailable**, by changing to wrong node name or
 turning the nodes off.
 - Reload a page on Django app. Django app responds back with this HTTP
 header, which deletes a session cookie:
 {{{
 Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
 Age=0; Path=/
 }}}

 The problematic codes are at django/contrib/sessions/middleware.py:37 :
 {{{
  def process_response(self, request, response):
 """
 If request.session was modified, or if the configuration is to
 save the
 session every time, save the changes and set a session cookie or
 delete
 the session cookie if the session has been emptied.
 

Re: [Django] #29203: Cached Session may cause losing a session, when it failed to connect to cache backend

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect to
cache backend
-+-
 Reporter:  Kenial Sookyum Lee   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  session cookie,  | Triage Stage:
  cached session |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Kenial Sookyum Lee:

Old description:

> Some cache backends (AFAIK Memcached and Redis) has a feature to ignore
> connection timeout exception, in order to ensure Django application
> working even if cache has failed. This can lead a subtle bug, deleting a
> session cookie. Following steps are reproduce this bug:
>
> - Set cached session for Django session (refer to
> https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
> sessions)
> - On Django app, try to log in or set a language in order to make a
> session cookie. At this step, cache nodes should be available.
> - To set cache nodes **unavailable**, by changing to wrong node name or
> turning the nodes off.
> - Reload a page on Django app. Django app responds back with this HTTP
> header, which deletes a session cookie:
> {{{
> Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
> Age=0; Path=/
> }}}
>
> The problematic codes are at django/contrib/sessions/middleware.py:22 :
> {{{
>  def process_response(self, request, response):
> """
> If request.session was modified, or if the configuration is to
> save the
> session every time, save the changes and set a session cookie or
> delete
> the session cookie if the session has been emptied.
> """
> try:
> accessed = request.session.accessed
> modified = request.session.modified
> empty = request.session.is_empty()
> except AttributeError:
> pass
> else:
> # First check if we need to delete this cookie.
> # The session should be deleted only if the session is
> entirely empty
> if settings.SESSION_COOKIE_NAME in request.COOKIES and empty:
> response.delete_cookie(
> settings.SESSION_COOKIE_NAME,
> path=settings.SESSION_COOKIE_PATH,
> domain=settings.SESSION_COOKIE_DOMAIN,
> )
> ...
> }}}
>
> I guess the initial intention was to delete a session if there is no
> values in it. However, it happens that code execution reaches at that
> code without exception, even if cache nodes are unavailable. The reason
> is, I already explained above, they just work that way even if the cache
> backend failed.
>
> I first met this bug while I was testing failover of AWS Elasticache
> (Redis). I was in testing of failover scenario, but Django application
> got me logged out repeatedly, even though session data itself is
> remaining in the cache replica. (it should, because it was doing
> failover, not reboot)
>
> IMHO, before checking ''empty'' of session data, there should be a logic
> to check cache backend is actually available. I found out
> ''request.session.cache_key'' can do that function, but it looks less
> explicit. Please show be a better way to do this, if you have one.

New description:

 Some cache backends (AFAIK Memcached and Redis) has a feature to ignore
 connection timeout exception, in order to ensure Django application
 working even if cache has failed. This can lead a subtle bug, deleting a
 session cookie. Following steps are reproduce this bug:

 - Set cached session for Django session (refer to
 https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
 sessions)
 - On Django app, try to log in or set a language in order to make a
 session cookie. At this step, cache nodes should be available.
 - To set cache nodes **unavailable**, by changing to wrong node name or
 turning the nodes off.
 - Reload a page on Django app. Django app responds back with this HTTP
 header, which deletes a session cookie:
 {{{
 Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
 Age=0; Path=/
 }}}

 The problematic codes are at django/contrib/sessions/middleware.py:37 :
 {{{
  def process_response(self, request, response):
 """
 If request.session was modified, or if the configuration is to
 save the
 session every time, save the changes and set a session cookie or
 delete
 the session cookie if the session has been emptied.
 

Re: [Django] #29203: Cached Session may cause losing a session, when it failed to connect to cache backend (was: Cached Session may cause losing a session, when it failed to connect backend cache)

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect to
cache backend
-+-
 Reporter:  Kenial Sookyum Lee   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  session cookie,  | Triage Stage:
  cached session |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  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.04d1c428c55fd643c11d1496c5343add%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29203: Cached Session may cause losing a session, when it failed to connect backend cache

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect
backend cache
-+-
 Reporter:  Kenial Sookyum Lee   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  session cookie,  | Triage Stage:
  cached session |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Kenial Sookyum Lee:

Old description:

> Some cache backends, Memcached and Redis, has a feature to ignore
> connection timeout exception, in order to ensure Django application
> working even if cache has failed. This can lead a subtle bug, deleting a
> session cookie. Following steps are reproduce this bug:
>
> - Set cached session for Django session (refer to
> https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
> sessions)
> - On Django app, try to log in or set a language in order to make a
> session cookie. At this step, cache nodes should be available.
> - To set cache nodes **unavailable**, by changing to wrong node name or
> turning the nodes off.
> - Reload a page on Django app. Django app responds back with this HTTP
> header, which deletes a session cookie:
> {{{
> Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
> Age=0; Path=/
> }}}
>
> The problematic codes are at django/contrib/sessions/middleware.py:22 :
> {{{
>  def process_response(self, request, response):
> """
> If request.session was modified, or if the configuration is to
> save the
> session every time, save the changes and set a session cookie or
> delete
> the session cookie if the session has been emptied.
> """
> try:
> accessed = request.session.accessed
> modified = request.session.modified
> empty = request.session.is_empty()
> except AttributeError:
> pass
> else:
> # First check if we need to delete this cookie.
> # The session should be deleted only if the session is
> entirely empty
> if settings.SESSION_COOKIE_NAME in request.COOKIES and empty:
> response.delete_cookie(
> settings.SESSION_COOKIE_NAME,
> path=settings.SESSION_COOKIE_PATH,
> domain=settings.SESSION_COOKIE_DOMAIN,
> )
> ...
> }}}
>
> I guess the initial intention was to delete a session if there is no
> values in it. However, it happens that code execution reaches at that
> code without exception, even if cache nodes are unavailable. The reason
> is, I already explained above, they just work that way even if the cache
> backend failed.
>
> I first met this bug while I was testing failover of AWS Elasticache
> (Redis). I was in testing of failover scenario, but Django application
> got me logged out repeatedly, even though session data itself is
> remaining in the cache replica. (it should, because it was doing
> failover, not reboot)
>
> IMHO, before checking ''empty'' of session data, there should be a logic
> to check cache backend is actually available. I found out
> ''request.session.cache_key'' can do that function, but it looks less
> explicit. Please show be a better way to do this, if you have one.

New description:

 Some cache backends (AFAIK Memcached and Redis) has a feature to ignore
 connection timeout exception, in order to ensure Django application
 working even if cache has failed. This can lead a subtle bug, deleting a
 session cookie. Following steps are reproduce this bug:

 - Set cached session for Django session (refer to
 https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
 sessions)
 - On Django app, try to log in or set a language in order to make a
 session cookie. At this step, cache nodes should be available.
 - To set cache nodes **unavailable**, by changing to wrong node name or
 turning the nodes off.
 - Reload a page on Django app. Django app responds back with this HTTP
 header, which deletes a session cookie:
 {{{
 Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
 Age=0; Path=/
 }}}

 The problematic codes are at django/contrib/sessions/middleware.py:22 :
 {{{
  def process_response(self, request, response):
 """
 If request.session was modified, or if the configuration is to
 save the
 session every time, save the changes and set a session cookie or
 delete
 the session cookie if the session has been emptied.
 

Re: [Django] #29203: Cached Session may cause losing a session, when it failed to connect backend cache

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect
backend cache
-+-
 Reporter:  Kenial Sookyum Lee   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  session cookie,  | Triage Stage:
  cached session |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Kenial Sookyum Lee):

 * type:  Uncategorized => Bug


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

Re: [Django] #29203: Cached Session may cause losing a session, when it failed to connect backend cache

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect
backend cache
-+-
 Reporter:  Kenial Sookyum Lee   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  session cookie,  | Triage Stage:
  cached session |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Kenial Sookyum Lee):

 * Attachment "patch_cached_session_deleting_session_cookie.diff" added.

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

[Django] #29203: Cached Session may cause losing a session, when it failed to connect backend cache

[Django]

#29203: Cached Session may cause losing a session, when it failed to connect
backend cache
-+-
   Reporter:  Kenial |  Owner:  nobody
  Sookyum Lee|
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  master
  contrib.sessions   |   Keywords:  session cookie,
   Severity:  Normal |  cached session
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Some cache backends, Memcached and Redis, has a feature to ignore
 connection timeout exception, in order to ensure Django application
 working even if cache has failed. This can lead a subtle bug, deleting a
 session cookie. Following steps are reproduce this bug:

 - Set cached session for Django session (refer to
 https://docs.djangoproject.com/en/2.0/topics/http/sessions/#using-cached-
 sessions)
 - On Django app, try to log in or set a language in order to make a
 session cookie. At this step, cache nodes should be available.
 - To set cache nodes **unavailable**, by changing to wrong node name or
 turning the nodes off.
 - Reload a page on Django app. Django app responds back with this HTTP
 header, which deletes a session cookie:
 {{{
 Set-Cookie:  sessionid=""; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-
 Age=0; Path=/
 }}}

 The problematic codes are at django/contrib/sessions/middleware.py:22 :
 {{{
  def process_response(self, request, response):
 """
 If request.session was modified, or if the configuration is to
 save the
 session every time, save the changes and set a session cookie or
 delete
 the session cookie if the session has been emptied.
 """
 try:
 accessed = request.session.accessed
 modified = request.session.modified
 empty = request.session.is_empty()
 except AttributeError:
 pass
 else:
 # First check if we need to delete this cookie.
 # The session should be deleted only if the session is
 entirely empty
 if settings.SESSION_COOKIE_NAME in request.COOKIES and empty:
 response.delete_cookie(
 settings.SESSION_COOKIE_NAME,
 path=settings.SESSION_COOKIE_PATH,
 domain=settings.SESSION_COOKIE_DOMAIN,
 )
 ...
 }}}

 I guess the initial intention was to delete a session if there is no
 values in it. However, it happens that code execution reaches at that code
 without exception, even if cache nodes are unavailable. The reason is, I
 already explained above, they just work that way even if the cache backend
 failed.

 I first met this bug while I was testing failover of AWS Elasticache
 (Redis). I was in testing of failover scenario, but Django application got
 me logged out repeatedly, even though session data itself is remaining in
 the cache replica. (it should, because it was doing failover, not reboot)

 IMHO, before checking ''empty'' of session data, there should be a logic
 to check cache backend is actually available. I found out
 ''request.session.cache_key'' can do that function, but it looks less
 explicit. Please show be a better way to do this, if you have 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/049.edb9502c640d38b5ea4de14d8f82dcfe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29165: Initial data howto could better explain how to use migrations

[Django]

#29165: Initial data howto could better explain how to use migrations
-+-
 Reporter:  Michel Samia |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  initial data | Triage Stage:  Ready for
  migrations |  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:"8d3bd724ab996078a570dd736b85a8ad5b317f97" 8d3bd724]:
 {{{
 #!CommitTicketReference repository=""
 revision="8d3bd724ab996078a570dd736b85a8ad5b317f97"
 [2.0.x] Fixed #29165 -- Clarified how to load initial data with
 migrations.

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

Re: [Django] #29165: Initial data howto could better explain how to use migrations

[Django]

#29165: Initial data howto could better explain how to use migrations
-+-
 Reporter:  Michel Samia |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  initial data | Triage Stage:  Ready for
  migrations |  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:"fd9398816e14554b52362f1152349da832fab4b1" fd93988]:
 {{{
 #!CommitTicketReference repository=""
 revision="fd9398816e14554b52362f1152349da832fab4b1"
 Fixed #29165 -- Clarified how to load initial data with 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/068.2a18a862649e4133be9c0c3c0e3e91cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29178: Index.__init__()'s fields parameter shouldn't be mutable

[Django]

#29178: Index.__init__()'s fields parameter shouldn't be mutable
-+-
 Reporter:  Flavio Curella   |Owner:  Atul
 Type:   |  mishra
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"10c0fe528a2089f4ba206caa50f9a98f8d9c8a15" 10c0fe5]:
 {{{
 #!CommitTicketReference repository=""
 revision="10c0fe528a2089f4ba206caa50f9a98f8d9c8a15"
 Fixed #29178 -- Allowed Index.fields to accept a tuple.
 }}}

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

Re: [Django] #28712: Add ability to apply separate attributes to ChoiceWidget options

[Django]

#28712: Add ability to apply separate attributes to ChoiceWidget options
-+-
 Reporter:  Stephen Swatman  |Owner:  Stephen
 |  Swatman
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  ChoiceWidget | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Stephen Swatman):

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


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

Re: [Django] #29165: Initial data howto could better explain how to use migrations

[Django]

#29165: Initial data howto could better explain how to use migrations
-+-
 Reporter:  Michel Samia |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  initial data | Triage Stage:  Ready for
  migrations |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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

Re: [Django] #28250: Ignore soft applied migrations in consistency check

[Django]

#28250: Ignore soft applied migrations in consistency check
-+-
 Reporter:  Brian May|Owner:  Marten
 Type:   |  Kenbeek
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  master
 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 Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 Marten's PR looks good. It just needs minor tweaks and it should be RFC.
 Comments on PR.

 Please uncheck Patch needs improvement when it's ready and we can have
 another look.

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

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

[Django] #29202: KeyError in django-sites caching (race condition?)

[Django]

#29202: KeyError in django-sites caching (race condition?)
--+
   Reporter:  Dominik George  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.sites   |Version:  1.10
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 Django Version: 1.10.8
 Python Version: 3.5.3

 Relevant backtrace:

 {{{
 File
 "/srv/www/teckids-website/venv/lib/python3.5/site-
 packages/django/contrib/sites/models.py"
 in _get_site_by_id
   37. return SITE_CACHE[site_id]

 File "/srv/www/teckids-website/venv/lib/python3.5/site-
 packages/multisite/hacks.py" in
 __getitem__
   124. raise KeyError(key)
 }}}

 In theory, there cannot be a KeyError there, unless the cache is cleared
 while the method is running. The code does not seem to be thread-safe.

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

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

[Django]

#25313: Document how to migrate from a built-in User model to a custom User 
model
---+
 Reporter:  Carl Meyer |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Luke Plant):

 I created this project which was my attempt to automate the process:

 https://bitbucket.org/spookylukey/django_custom_user_migration

 However, I think Aymeric's solution looks better.

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

Re: [Django] #25590: Allow fields to set join class

[Django]

#25590: Allow fields to set join class
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tyson Clugg):

 * cc: Tyson Clugg (added)


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

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

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tyson Clugg):

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

Re: [Django] #29195: Postgres Regression, annotating Exists through a OuterRef query.

[Django]

#29195: Postgres Regression, annotating Exists through a OuterRef query.
-+-
 Reporter:  Oli Warner   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Oli Warner):

 Thank you, Simon. I really appreciate you picking this up so fast and
 fixing it.

 I've tested your branch and it does fix my little test harness too.

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

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

[Django]

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  Daniel Menzel|Owner:  Dan
 |  Watson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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

Re: [Django] #29201: Rendering issues when using ArrayField(models.BooleanField())

[Django]

#29201: Rendering issues when using ArrayField(models.BooleanField())
-+-
 Reporter:  linluc   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  ArrayField   | Triage Stage:
  BooleanField SplitArrayWidget  |  Unreviewed
  rendering  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by linluc):

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

[Django] #29201: Rendering issues when using ArrayField(models.BooleanField())

[Django]

#29201: Rendering issues when using ArrayField(models.BooleanField())
-+-
   Reporter:  linluc |  Owner:  (none)
   Type:  Bug| Status:  new
  Component: |Version:  2.0
  contrib.postgres   |   Keywords:  ArrayField
   Severity:  Normal |  BooleanField SplitArrayWidget
   Triage Stage: |  rendering
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 My goal is to replace 50 Boolean fields with one
 ArrayField(models.BooleanField(), size=50) so I am prototyping this
 approach. I have not found a single online example with such combination
 (ArrayField + BooleanField) and also this area is very poorly documented.
 I am running into numerous issues and that makes me feel that it  was
 never properly tested. Well, I am offering my help in future testing
 regarding this issue.

 Here is my simple model (using Django 2.0.3):


 {{{
 class Test1Model(models.Model):
user = models.OneToOneField(settings.AUTH_USER_MODEL,
 on_delete=models.CASCADE)
user_choices = ArrayField(models.BooleanField(), default=(), size=5,
 null=True)
 }}}

 form:


 {{{
 class Test1Form(forms.ModelForm):
class Meta:
   model = Test1Model

   fields = ('user_choices',)

   widgets = {
  'user_choices' : SplitArrayWidget(forms.CheckboxInput(),5)
   }
 }}}

 view:


 {{{
 def run_test1(request):
if request.method == 'POST':
   test_form = Test1Form(instance=request.user.test1model,
 data=request.POST)

   if test_form.is_valid():
  test_form.save()
   else:
 print(test_form.errors)
else:
   test_form = Test1Form(instance=request.user.test1model)
return render(request, 'test1/test1.html' , {'test_form': test_form})
 }}}


 template (test1.html):


 {{{
 
 
 
 TEST1
 
 

 

  {{ test_form.as_p }}
  {% csrf_token %}

 

 

 
 
 }}}

 Here you will encounter a bug which I already reported
 ([https://code.djangoproject.com/ticket/29197]) but it is easy to fix by
 moving the template directory.

 After fixing the template issue the initial page renders OK, 5 check-boxes
 are present (see attached image, section A).

 Problem 1: by default all check-boxes are required and I was unable to
 reverse that. Adding "required = False" caused the following error:

 {{{
 TypeError: __init__() got an unexpected keyword argument 'required'
 }}}

 See the image, section B.

 OK, for the purpose of prototyping I checked all check boxes and submitted
 the form. The output was highly unexpected (image, section C).

 The output page includes 24 check-boxes and by looking at the generated
 HTML we can see why (hint: value=""):


 {{{
 User choices:
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 }}}

 I should note that the values are saved in the database correctly, but
 still the Django included rendering choices (as_p, as_ul, as_table) are
 broken here.

 Please also note that the label assignment is broken as well, there is
 only one label generated for all check-boxes.

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

Re: [Django] #23406: Migrations not found when only .pyc files are available (e.g. in a frozen environment)

[Django]

#23406: Migrations not found when only .pyc files are available (e.g. in a 
frozen
environment)
-+-
 Reporter:  Daniel Menzel|Owner:  Dan
 |  Watson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, .pyc,| Triage Stage:  Accepted
  frozen, cx_Freeze  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Dan can you close your existing PR and open a new one reverting the
 original change (explaining why that's OK now)?

 From there we'll mark that RFC and get Tim to make a final review.

 (We'll either revert, or say "no, lets take the patch", or failing that
 the only other option is `wontfix` — either way we'll get this one
 resolved.)

 Thanks!

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

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

Re: [Django] #29180: makemigrations autodetector ignoring existing migrations

[Django]

#29180: makemigrations autodetector ignoring existing migrations
-+-
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   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 Carlton Gibson):

 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


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

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