date:20190903

Re: [Django] #30753: Add 'Did you mean...' when TemplateDoesNotExist occurs

2019-09-03 Thread Django

#30753: Add 'Did you mean...' when TemplateDoesNotExist occurs
-+--
 Reporter:  Min ho Kim   |Owner:  Min ho Kim
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+--

Comment (by felixxm):

 I'm not sure to be honest. List of templates can be really big and in a
 consequence `difflib.get_close_matches()` would be time-consuming. I would
 prefer to get 500 page quick instead of waiting longer for a hint that may
 not be really helpful.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.be17482202dc01e28bfca39d9891de75%40djangoproject.com.

Re: [Django] #30753: Add 'Did you mean...' when TemplateDoesNotExist occurs

2019-09-03 Thread Django

#30753: Add 'Did you mean...' when TemplateDoesNotExist occurs
-+--
 Reporter:  Min ho Kim   |Owner:  Min ho Kim
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+--
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 You've assigned to yourself so I presume there's a patch incoming? (Super
 🙂)

 Assuming it's not too complicated, this sounds like a nice addition... —
 very happy to have a look and see.

 Thanks for the input!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a2c7485c1de5569eeb60767426334dc3%40djangoproject.com.

Re: [Django] #30750: Add support for check constraints on MySQL 8.0.16+.

2019-09-03 Thread Django

#30750: Add support for check constraints on MySQL 8.0.16+.
-+-
 Reporter:  felixxm  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL, check | Triage Stage:  Accepted
  constraints|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Hasan, sure feel free.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.036fd3a60bd89dfc1e1038645164a1be%40djangoproject.com.

Re: [Django] #30755: Have django.views.generic.base.View.as_view() check argument type, via annotations. (was: Arguments to django.views.generic.base.View.as_view())

2019-09-03 Thread Django

#30755: Have django.views.generic.base.View.as_view() check argument type, via
annotations.
---+-
 Reporter:  David Szotten  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  typing | Triage Stage:  Someday/Maybe
Has patch:  0  |  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.d8e916585615f6f7f62fe9b5eba886c9%40djangoproject.com.

Re: [Django] #30755: Arguments to django.views.generic.base.View.as_view()

2019-09-03 Thread Django

#30755: Arguments to django.views.generic.base.View.as_view()
---+-
 Reporter:  David Szotten  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  typing | Triage Stage:  Someday/Maybe
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Carlton Gibson):

 * status:  new => closed
 * keywords:   => typing
 * version:  2.2 => master
 * resolution:   => needsinfo
 * stage:  Unreviewed => Someday/Maybe


Comment:

 > Django doesn't support typing yet...

 Yeah, I think this is the one.

 Type hints seem to have come on a long way in recent versions. The
 benefits seem to be summing up. So I'm sure they'll come to Django.

 But at current state of play, I'd be **very surprised** if `as_view()`
 raised a `TypeError` here for that.

 I'll mark this as Someday/Maybe but close it as `needsinfo`: all things
 typing are dependent on a DEP being produced and agreed on.
 [https://groups.google.com/d/topic/django-
 developers/trTEbURFhEY/discussion There's a mailing list discussion for
 that]. I'd rather keep everything together there until we have a path
 forward.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.bba9db629396db371b0615dcf4798b25%40djangoproject.com.

Re: [Django] #29724: Admin date_hierarchy filter by month displays an extra day at timezone boundary.

2019-09-03 Thread Django

#29724: Admin date_hierarchy filter by month displays an extra day at timezone
boundary.
-+-
 Reporter:  Lavrenov Ivan|Owner:  Alexander
 |  Holmbäck
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Carlton Gibson):

 OK, thanks for the follow-up yab. TBH I'm still inclined to view these as
 the same issue: incorrect collection of items at time-period boundaries
 (demonstrated with DST and TZ examples). However... one-ticket/two-tickets
 is not so important.

 More is that, we need to make sure we have test cases for both these types
 of example, and then we can make sure any fix addresses both of those.

 Super. 👍

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0826362ff4c2068200dfeda4da00dd3a%40djangoproject.com.

Re: [Django] #30749: Admin date_hierarchy filter by month of October 2019 does not include October 31th when TZ is set to Europe/Paris (UTC+2)

2019-09-03 Thread Django

#30749: Admin date_hierarchy filter by month of October 2019 does not include
October 31th when TZ is set to Europe/Paris (UTC+2)
-+-
 Reporter:  yab  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  timezone daylight| Triage Stage:
  saving time|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yab):

 Hi Carlton,
 Below ticket #29724, I just proposed two solutions to those two distinct
 (I think) issues, one in templatestags/admin_list.py and one
 views/mains.py.

  Replying to [comment:4 Carlton Gibson]

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.eaade140b20ab0d4d16a5bb097d8f024%40djangoproject.com.

Re: [Django] #29724: Admin date_hierarchy filter by month displays an extra day at timezone boundary.

2019-09-03 Thread Django

#29724: Admin date_hierarchy filter by month displays an extra day at timezone
boundary.
-+-
 Reporter:  Lavrenov Ivan|Owner:  Alexander
 |  Holmbäck
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by yab):

 * needs_tests:  0 => 1


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

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

[Django] #30756: ModelForm does not work well with the override field on Inherited Model

2019-09-03 Thread Django

#30756: ModelForm does not work well with the override field on Inherited Model
-+-
   Reporter:  ramon  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  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  |
-+-
 Following the samples:

 {{{
 class City(models.Model):
 name = models.CharField(max_length=100)


 class AddressBase(models.Model):
 city = models.ForeignKey(City, on_delete=models.PROTECT)
 ...
 country = models.ForeignKey(...)

 class Meta:
 abstract = True


 class Address(AddressBase):
 city = models.CharField(max_length=100)


 class AddessForm(forms.ModelForm):
 class Meta:
 model = Address
 fields = ("city", )
 }}}

 I expect a rendered form with the city field as a CharField, but I got the
 following error:

 {{{ Cannot assign "''": "Address.city" must be a "City" instance. }}}

 The problem, I think, is with the code above, on
 models.Field.contribute_to_class

 {{{
 if self.column:
 # Don't override classmethods with the descriptor. This means
 that
 # if you have a classmethod and a field with the same name,
 then
 # such fields can't be deferred (we don't have a check for
 this).
 if not getattr(cls, self.attname, None):
 setattr(cls, self.attname,
 DeferredAttribute(self.attname))
 }}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.dceb5b3a04cd650f65069d12bcb761f9%40djangoproject.com.

Re: [Django] #30755: Arguments to django.views.generic.base.View.as_view()

2019-09-03 Thread Django

#30755: Arguments to django.views.generic.base.View.as_view()
---+--
 Reporter:  David Szotten  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Generic views  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Simon Charette):

 Not sure I understand the issue here, can't you use `Optional[str]` in
 this case? Django doesn't support typing yet so I'm not sure of the origin
 of this type check failure.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.20557e46ab391344a40063d5f3ff679f%40djangoproject.com.

Re: [Django] #30750: Add support for check constraints on MySQL 8.0.16+.

2019-09-03 Thread Django

#30750: Add support for check constraints on MySQL 8.0.16+.
-+-
 Reporter:  felixxm  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL, check | Triage Stage:  Accepted
  constraints|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hasan Ramezani):

 @felixxm can I continue your work on this ticket?

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

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

Re: [Django] #30755: Arguments to django.views.generic.base.View.as_view()

2019-09-03 Thread Django

#30755: Arguments to django.views.generic.base.View.as_view()
---+--
 Reporter:  David Szotten  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Generic views  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by David Szotten):

 the downside of `foo: annotation = None` is that it doesn't type check:
 `Incompatible types in assignment (expression has type "None", variable
 has type "str")`

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.0c2e9715d0817024fb9e2abe568258da%40djangoproject.com.

Re: [Django] #29724: Admin date_hierarchy filter by month displays an extra day at timezone boundary.

2019-09-03 Thread Django

#29724: Admin date_hierarchy filter by month displays an extra day at timezone
boundary.
-+-
 Reporter:  Lavrenov Ivan|Owner:  Alexander
 |  Holmbäck
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  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:  1
-+-

Comment (by yab):

 Two distinct date_hierarchy bugs : one relate to TZ effects and one
 related to DST effects :

 #29724 (TZ matter)
 When year and month lookup are chosen, if you have an event late in last
 day of the month that is first day of next month in UTC, queryset.dates
 method gives a date_hierarchy choice for next month 1st.
 It seems it can be solved modifiyng
 admin/contrib/templatetags/admin_list.py this way, using **queryset.filter
 and lists that may be very slow** :
 Needs importing:
 {{{
 from django.utils.timezone import make_naive
 from django.conf import settings
 }}}
 and after "elif year_lookup and month_lookup:":
 {{{
 elif year_lookup and month_lookup:
 ### This is a way to avoid using queryset.dates
 fucntion, which was giving naive datetimes with problems when the
 monthrange is different between utc and localtime.

 month_filter=field_name+'__month'
 year_filter=field_name+'__year'
 dates_or_datetimes =
 cl.model.objects.filter(**{year_filter:year_lookup,
 month_filter:month_lookup}).values_list(field_name, flat=True).distinct()

 days = dates_or_datetimes
 if isinstance(dates_or_datetimes[0],
 datetime.datetime) and settings.USE_TZ:
 day_list = []
 days = []
 for day in dates_or_datetimes:
 if make_naive(day).day not in
 day_list:
 day_list.append(make_naive(day).day)
 days.append(make_naive(day))
 ###
 }}}

 ###30749 (DST matter)
 If the month selected by date_hierarchy is the month of the DST, the
 objects of the last day of the month does not appear in the changelist.
 Changing the way "from_date" is set after ''elif month'' line 165 solves
 my problem: Instead of just adding 32 days with timedelta, I use
 make_aware with tzinfo=None. That way the to_date is set to the correct
 date and time.
 {{{
 elif month:
 ### The tzinfo changes between
 first and last day of the month when DST applies.  That's why we need to
 make_aware to_date separately from from_date
 to_date = make_aware((from_date +
 timedelta(days=32)).replace(day=1,tzinfo=None))
 }}}

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

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

Re: [Django] #30748: Abstract model class specifies foreign key – MySQL doesn't have it.

2019-09-03 Thread Django

#30748: Abstract model class specifies foreign key – MySQL doesn't have it.
-+-
 Reporter:  Mike Robinson|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 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 Mike Robinson):

 Changed status to "worksforme" since there *is* something wrong here but
 "it's not going to be quite that easy, as it turns out" to reproduce it.
 So it goes.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.0d496c398b2282833e4c6c1d66cd5977%40djangoproject.com.

Re: [Django] #30748: Abstract model class specifies foreign key – MySQL doesn't have it.

2019-09-03 Thread Django

Comment (by Mike Robinson):

I will attempt to produce the simplest possible test case and report back.
However, this issue occurs ''within the Django Admin'' when attempting to
delete a **User**. The table n question is the user-profile as shown
above.

But also: I think that I am seeing other instances of this in the same
application – other cases involving foreign keys and deletion. (Delete
posts, etc.) Yes, it is possible that this is some obscure application
(model) issue and I will indeed pursue this to try to help resolve the
problem. But I am suspicious, specifically, of some issue in
**OneToOneField.**

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/073.ca7f864339b836bce0bacbac2c672af7%40djangoproject.com.

Re: [Django] #20648: Template variable and loss of precision

2019-09-03 Thread Django

#20648: Template variable and loss of precision
-+-
 Reporter:  maciag.artur@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 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 felixxm):

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


Comment:

 Duplicate of #28730.

 Fixed in 9ec7d8e514e09636b0ab4bcac74b5f7a5be335a3.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.a328275598483c07daabb57ca772932b%40djangoproject.com.

Re: [Django] #20648: Template variable and loss of precision

2019-09-03 Thread Django

#20648: Template variable and loss of precision
-+
 Reporter:  maciag.artur@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Min ho Kim):

 This issue seemed to be resolved already (at least master and 2.2.4).
 I don't see any difference from the initial example code.


 {{{
 >>> from django.template import Variable
 >>> Variable(str(2**53)).resolve(None) == 2**53
 True
 >>> Variable(str(2**53+1)).resolve(None) == 2**53+1
 True
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.c02ca4892367c167b8c9a1ed99b23e62%40djangoproject.com.

Re: [Django] #28935: Template error raised in an {% extends %} child template shows incorrect source location on debug page

2019-09-03 Thread Django

#28935: Template error raised in an {% extends %} child template shows incorrect
source location on debug page
-+
 Reporter:  Matt Westcott|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Min ho Kim):

 * cc: Min ho Kim (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.4083483dfa3d23f9d1431095aa33fae3%40djangoproject.com.

Re: [Django] #30741: sqlmigrate doesn't show a drop constraint SQL when previous create constrain operation wasn't perform.

2019-09-03 Thread Django

#30741: sqlmigrate doesn't show a drop constraint SQL when previous create
constrain operation wasn't perform.
-+-
 Reporter:  Scott Stafford   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  db_constraint,   | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 I cannot reproduce this issue with provided models, everything works for
 me. Maybe you have some local issues with constraints introspection, it's
 hard to tell. Please don't reopen this ticket without providing a sample
 project.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.8a3ef92511a766cc04b0b7cd1c03a644%40djangoproject.com.

Re: [Django] #30755: Arguments to django.views.generic.base.View.as_view()

2019-09-03 Thread Django

#30755: Arguments to django.views.generic.base.View.as_view()
---+--
 Reporter:  David Szotten  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Generic views  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Simon Charette):

 * type:  Uncategorized => New feature


Comment:

 I think we should keep the `TypeError` behaviour as it's an effective way
 of catching typos and follows the configurable pattern.

 If we were adding support fallback for `__annotations__` I believe a
 `TypeError` should be raised if no value is provided.

 Not sure it's worth doing though as `foo: annotation = None` is a good way
 to provide a default and an annotation.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.d00a6b2f74fb811ee213a84719779f29%40djangoproject.com.

Re: [Django] #30754: Partial indexes break future migrations in sqlite

2019-09-03 Thread Django

#30754: Partial indexes break future migrations in sqlite
-+
 Reporter:  cuu508   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  sqlite   | 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):

 * severity:  Normal => Release blocker


Comment:

 Bumping to a release blocker because partial indexes are a new feature.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.5beb1bfbdfd986d42fe4ef268e95cfcb%40djangoproject.com.

Re: [Django] #30754: Partial indexes break future migrations in sqlite

2019-09-03 Thread Django

#30754: Partial indexes break future migrations in sqlite
+
 Reporter:  cuu508  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  2.2
 Severity:  Normal  |   Resolution:
 Keywords:  sqlite  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Simon Charette):

 * keywords:   => sqlite
 * stage:  Unreviewed => Accepted


Comment:

 This is probably another edge cased missed by the create/rename table
 workaround on SQLite to emulate `ALTER TABLE` wrt to partial indices.

 If possible we should simply not include the table alias in the partial
 index predicate else I suspect we'll need to defer index re-creation on
 the table '''after''' the rename.

 I haven't reproduced but I feel confident accepting the ticket based on
 the detailed report and reduced reproduction case.

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

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

Re: [Django] #30741: sqlmigrate doesn't show a drop constraint SQL when previous create constrain operation wasn't perform.

2019-09-03 Thread Django

#30741: sqlmigrate doesn't show a drop constraint SQL when previous create
constrain operation wasn't perform.
-+-
 Reporter:  Scott Stafford   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  db_constraint,   | Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Scott Stafford):

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


Comment:

 Thank you for looking into this!  Curiously, I am not seeing what you are
 seeing, however.  We encountered this bug first in normal course of usage
 and found that the constraint had not been removed.  And, in the test
 example I set up for this ticket, I just now ran the first migration and
 then sqlmigrate-checked the second, and it still is a no-op:


 {{{
 (.env) c:\wc\dbconstraintnotdropped>python manage.py migrate myapp 0001
 Operations to perform:
   Target specific migration: 0001_initial, from myapp
 Running migrations:
   Applying myapp.0001_initial... OK

 (.env) c:\wc\dbconstraintnotdropped>python manage.py sqlmigrate myapp 0002
 BEGIN;
 --
 -- Alter field submission on child
 --
 COMMIT;
 }}}


 Then also, I ran the second migration yet the constraint remained:


 {{{
 (.env) c:\wc\dbconstraintnotdropped>python manage.py dbshell
 psql (11.2)
 WARNING: Console code page (437) differs from Windows code page (1252)
  8-bit characters might not work correctly. See psql reference
  page "Notes for Windows users" for details.
 Type "help" for help.

 ventus_master=# \d+ myapp_child
 Table
 "public.myapp_child"
 Column |  Type   | Collation | Nullable | Default
 | Storage | Stats target | Description
 
---+-+---+--+-+-+--+-
  id| integer |   | not null |
 nextval('myapp_child_id_seq'::regclass) | plain   |  |
  parent_id | integer |   | not null |
 | plain   |  |
 Indexes:
 "myapp_child_pkey" PRIMARY KEY, btree (id)
 "myapp_child_parent_id_af46d0ab" btree (parent_id)
 Foreign-key constraints:
 "myapp_child_parent_id_af46d0ab_fk_myapp_parent_id" FOREIGN KEY
 (parent_id) REFERENCES myapp_parent(id) DEFERRABLE INITIALLY DEFERRED
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.98d9ebd2b27e11826a3c3c38b5e04e0b%40djangoproject.com.

Re: [Django] #30752: Allow using ExceptionReporter subclass in django.views.debug.technical_500_response

2019-09-03 Thread Django

#30752: Allow using ExceptionReporter subclass in
django.views.debug.technical_500_response
-+
 Reporter:  Carlton Gibson   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Description changed by Carlton Gibson:

Old description:

> #29714 allows using an ExceptionReporter subclass with AdminEmailHandler.
>
> Ideally we'd make the similar available for the 500 debug error view.
>
> [https://github.com/django/django/blob/52e9c753659ffeab67149fcf26b95c10cf137c40/django/views/debug.py#L84-L95
> Currently the use of `ExceptionReporter` is hardcoded.]
>
> * Move this to a parameter
> * Provide an example of using, e.g., `functools.partial` to configure a
> subclass with specifying `handler500`.

New description:

 #29714 allows using an ExceptionReporter subclass with AdminEmailHandler.

 Ideally we'd make the similar available for the 500 debug error view.

 
[https://github.com/django/django/blob/52e9c753659ffeab67149fcf26b95c10cf137c40/django/views/debug.py#L84-L95
 Currently the use of `ExceptionReporter` is hardcoded.]

 * Move this to a parameter
 * Provide an example of using, e.g., `functools.partial` to configure a
 subclass when specifying `handler500`.

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.8b78783224a45756f442caec57c3b2b7%40djangoproject.com.

Re: [Django] #30752: Allow using ExceptionReporter subclass in django.views.debug.technical_500_response

2019-09-03 Thread Django

#30752: Allow using ExceptionReporter subclass in
django.views.debug.technical_500_response
-+
 Reporter:  Carlton Gibson   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by felixxm):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.37e8778bd70e47e5f6e3b87410f05b0c%40djangoproject.com.

Re: [Django] #30749: Admin date_hierarchy filter by month of October 2019 does not include October 31th when TZ is set to Europe/Paris (UTC+2)

2019-09-03 Thread Django

#30749: Admin date_hierarchy filter by month of October 2019 does not include
October 31th when TZ is set to Europe/Paris (UTC+2)
-+-
 Reporter:  yab  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  timezone daylight| Triage Stage:
  saving time|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi yab.

 Seems similar enough: both have a incorrect result on the boundary
 condition. If you can add a test case showing your particular case to the
 other ticket, or the PR on GitHub, we can make sure that it passes for any
 proposed solution. Happy to re-open a separate ticket if we can pin down
 that there are actually two bugs, but it doesn't look that way with what
 we have right now. (I think 🙂)

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

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

Re: [Django] #30691: Change uuid field to FK does not create dependency

2019-09-03 Thread Django

#30691: Change uuid field to FK does not create dependency
+-
 Reporter:  Dart|Owner:  Dart
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  UUID, FK| 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"5931d2e96ae94b204d146b7f751e0e804da74953" 5931d2e9]:
 {{{
 #!CommitTicketReference repository=""
 revision="5931d2e96ae94b204d146b7f751e0e804da74953"
 Fixed #30691 -- Made migrations autodetector find dependencies for foreign
 keys altering.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.6fedbbe44dac6628cbc6869537541887%40djangoproject.com.

Re: [Django] #30751: IntegrityError with TransactionTestCase and serialized_rollback=True. (was: Old bug: IntegrityError with TransactionTestCase and serialized_rollback=True)

2019-09-03 Thread Django

#30751: IntegrityError with TransactionTestCase and serialized_rollback=True.
-+-
 Reporter:  Ray Tham |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  APITransactionTestCase |  Unreviewed
Has patch:  0|  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.5c0eb6a91d1bdc68a9cb70f5735d6888%40djangoproject.com.

Re: [Django] #30751: Old bug: IntegrityError with TransactionTestCase and serialized_rollback=True

2019-09-03 Thread Django

#30751: Old bug: IntegrityError with TransactionTestCase and
serialized_rollback=True
-+-
 Reporter:  Ray Tham |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  APITransactionTestCase |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => needsinfo


Comment:

 It is definitely not exactly the same issue, because added test passes and
 sample project attached to the #23727 (fixed in Django 1.9) also works
 properly. Can you provide a sample project to reproduce your issue?

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

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

[Django] #30755: Arguments to django.views.generic.base.View.as_view()

2019-09-03 Thread Django

#30755: Arguments to django.views.generic.base.View.as_view()
-+
   Reporter:  David Szotten  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Generic views  |Version:  2.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 `django.views.generic.base.View.as_view()` raises a `TypeError` if passed
 a kwarg that's not already an attribute to the class
 https://github.com/django/django/blame/master/django/views/generic/base.py#L57

 From the git blame i can't tell what the reason for this is. Is it only to
 catch potential mistakes/typos?

 If so, would we be open to also accepting attributes in
 `cls.__annotations__`?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.f883e7b2667f44f48e915ba81d89e7d2%40djangoproject.com.

Re: [Django] #30691: Change uuid field to FK does not create dependency

2019-09-03 Thread Django

#30691: Change uuid field to FK does not create dependency
+-
 Reporter:  Dart|Owner:  Dart
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  UUID, FK| 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 Simon Charette):

 * stage:  Accepted => Ready for checkin


Comment:

 Hey Dart, thanks for submitting a PR!

 Since this is a bug fix it shouldn't not require any docs. I've marked the
 patch RFC since only trivial changes need to be made before the patch is
 merged which is something committers can take care of.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.11ded545e922dc129b8a11839c4250f5%40djangoproject.com.

Re: [Django] #30753: Add 'Did you mean...' when TemplateDoesNotExist occurs

2019-09-03 Thread Django

#30753: Add 'Did you mean...' when TemplateDoesNotExist occurs
-+--
 Reporter:  Min ho Kim   |Owner:  Min ho Kim
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+--
Changes (by Min ho Kim):

 * Attachment "Proposed outcome multiple templates.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8230725142741a94438ff4caeb2bf3d6%40djangoproject.com.

[Django] #30754: Partial indexes break future migrations in sqlite

2019-09-03 Thread Django

#30754: Partial indexes break future migrations in sqlite
--+
   Reporter:  cuu508  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  2.2
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 How to reproduce:

 1. Create a dummy "Question" model (lifted from Django's tutorial)
 2. Add a partial index on one of its fields, create a migration and apply
 it
 3. Add another field to the model, create the migration (works) and apply
 it (throws an error)

 The error I get looks like this:

 {{{
 $ ./manage.py migrate
 Operations to perform:
   Apply all migrations: admin, auth, contenttypes, polls, sessions
 Running migrations:
   Applying polls.0003_question_hint...Traceback (most recent call last):
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/sqlite3/base.py", line 383, in execute
 return Database.Cursor.execute(self, query, params)
 sqlite3.OperationalError: no such column:
 new__polls_question.question_text

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "./manage.py", line 21, in 
 main()
   File "./manage.py", line 17, in main
 execute_from_command_line(sys.argv)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/core/management/__init__.py", line 381, in
 execute_from_command_line
 utility.execute()
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/core/management/__init__.py", line 375, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/core/management/base.py", line 323, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/core/management/base.py", line 364, in execute
 output = self.handle(*args, **options)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/core/management/base.py", line 83, in wrapped
 res = handle_func(*args, **kwargs)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/core/management/commands/migrate.py", line 234, in handle
 fake_initial=fake_initial,
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/migrations/executor.py", line 117, in migrate
 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/migrations/executor.py", line 147, in
 _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/migrations/executor.py", line 245, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/migrations/migration.py", line 124, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/migrations/operations/fields.py", line 112, in
 database_forwards
 field,
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/sqlite3/schema.py", line 327, in add_field
 self._remake_table(model, create_field=field)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/sqlite3/schema.py", line 300, in _remake_table
 self.execute(sql)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/base/schema.py", line 137, in execute
 cursor.execute(sql, params)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 99, in execute
 return super().execute(sql, params)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 67, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/tmp/htemp/lib/python3.7/site-packages/django/db/utils.py", line
 89, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/tmp/htemp/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)

Re: [Django] #30753: Add 'Did you mean...' when TemplateDoesNotExist occurs

2019-09-03 Thread Django

#30753: Add 'Did you mean...' when TemplateDoesNotExist occurs
-+--
 Reporter:  Min ho Kim   |Owner:  Min ho Kim
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+--
Description changed by Min ho Kim:

Old description:

> When 'TemplateDoesNotExist' occurs from using {% extends %} or {% include
> %} with wrong file names,
> technical_500.html only tells you that source does not exist.
>
> For example, use of below code...
> {{{
> base.html
> {% block content %}
> {% endblock %}
>
> home.html
> {% extends 'baseXX.html' %}
> {% block content %}
> This is home
> {% endblock %}
> }}}
> will give you...
>
> {{{
> TemplateDoesNotExist at /
> baseXX.html
> }}}
>

> I propose we add some informative message to help find the source of
> error by adding
>
> {{{
> Did you mean...
> base.html
> }}}

New description:

 When 'TemplateDoesNotExist' occurs from using {% extends %} or {% include
 %} with wrong file names,
 technical_500.html only tells you that source does not exist.

 For example, use of below code...
 {{{
 base.html
 {% block content %}
 {% endblock %}

 home.html
 {% extends 'baseX.html' %}
 {% block content %}
 This is home
 {% endblock %}
 }}}
 will give you...

 {{{
 TemplateDoesNotExist at /
 baseX.html
 }}}


 I propose we add some informative message to help find the source of error
 by adding

 {{{
 Did you mean...
 /Users/minhokim/Code/Django/djangodev/empty/templates/base.html
 /Users/minhokim/Code/Django/djangodev/empty/templates2/baseXX.html
 }}}

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.0b16a4e1c10b4a87d4717988ac45cf75%40djangoproject.com.

Re: [Django] #30753: Add 'Did you mean...' when TemplateDoesNotExist occurs

2019-09-03 Thread Django

#30753: Add 'Did you mean...' when TemplateDoesNotExist occurs
-+--
 Reporter:  Min ho Kim   |Owner:  Min ho Kim
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+--
Changes (by Min ho Kim):

 * Attachment "Proposed outcome.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c040d37940b4dbedbe8f88d0d7b29132%40djangoproject.com.

Re: [Django] #30753: Add 'Did you mean...' when TemplateDoesNotExist occurs

2019-09-03 Thread Django

#30753: Add 'Did you mean...' when TemplateDoesNotExist occurs
-+--
 Reporter:  Min ho Kim   |Owner:  Min ho Kim
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+--
Changes (by Min ho Kim):

 * Attachment "Screen Shot 2019-09-03 at 21.53.38.png" added.

 Proposed outcome

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.aa08cafa052e068b84d22be8dda97233%40djangoproject.com.

Re: [Django] #30753: Add 'Did you mean...' when TemplateDoesNotExist occurs

2019-09-03 Thread Django

#30753: Add 'Did you mean...' when TemplateDoesNotExist occurs
-+--
 Reporter:  Min ho Kim   |Owner:  Min ho Kim
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+--
Changes (by Min ho Kim):

 * owner:  nobody => Min ho Kim


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.3bb916b430c50233e8dce46b231923eb%40djangoproject.com.

[Django] #30753: Add 'Did you mean...' when TemplateDoesNotExist occurs

2019-09-03 Thread Django

#30753: Add 'Did you mean...' when TemplateDoesNotExist occurs
---+--
   Reporter:  Min ho Kim   |  Owner:  nobody
   Type:  New feature  | Status:  assigned
  Component:  Template system  |Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  1|
---+--
 When 'TemplateDoesNotExist' occurs from using {% extends %} or {% include
 %} with wrong file names,
 technical_500.html only tells you that source does not exist.

 For example, use of below code...
 {{{
 base.html
 {% block content %}
 {% endblock %}

 home.html
 {% extends 'baseXX.html' %}
 {% block content %}
 This is home
 {% endblock %}
 }}}
 will give you...

 {{{
 TemplateDoesNotExist at /
 baseXX.html
 }}}


 I propose we add some informative message to help find the source of error
 by adding

 {{{
 Did you mean...
 base.html
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.984c89c7482ccf038c959b46a8fadc9d%40djangoproject.com.

Re: [Django] #29444: Allow fields to be part of the RETURNING clause during INSERT

2019-09-03 Thread Django

#29444: Allow fields to be part of the RETURNING clause during INSERT
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 Type:   |  Hoppe
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django, db,  | Triage Stage:  Accepted
  returning, default, model, field   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"003bb34b218adb23d1a7e67932a6ba9b3c4dcc81" 003bb34b]:
 {{{
 #!CommitTicketReference repository=""
 revision="003bb34b218adb23d1a7e67932a6ba9b3c4dcc81"
 Refs #29444 -- Made db.backends.oracle.utils.InsertVar use str as default.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.450f6fd623f16e20536f6cb4e0f8d893%40djangoproject.com.

Re: [Django] #30691: Change uuid field to FK does not create dependency

2019-09-03 Thread Django

#30691: Change uuid field to FK does not create dependency
+
 Reporter:  Dart|Owner:  Dart
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  UUID, FK| Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Dart):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/11740

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0cc04c59bc2f8051ce46842465ff68ca%40djangoproject.com.

Re: [Django] #30691: Change uuid field to FK does not create dependency

2019-09-03 Thread Django

#30691: Change uuid field to FK does not create dependency
+
 Reporter:  Dart|Owner:  Dart
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  UUID, FK| Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Dart):

 Hi! Send pull request, please check it. And please can you help me where
 to put docs.

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

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

Re: [Django] #30749: Admin date_hierarchy filter by month of October 2019 does not include October 31th when TZ is set to Europe/Paris (UTC+2)

2019-09-03 Thread Django

#30749: Admin date_hierarchy filter by month of October 2019 does not include
October 31th when TZ is set to Europe/Paris (UTC+2)
-+-
 Reporter:  yab  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  timezone daylight| Triage Stage:
  saving time|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yab):

 Replying to [comment:2 Carlton Gibson]:
 Hello, thanks for reading this ticket. It may be a different problem than
 the #29724 ticket. I just told it to ahbk on github (/django/pull/10380).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.45d8a3e2ae7cdf1aa431940a6e16a904%40djangoproject.com.

Re: [Django] #30200: Add support for using indexes in update() for ArrayFields.

2019-09-03 Thread Django

#30200: Add support for using indexes in update() for ArrayFields.
-+-
 Reporter:  felixxm  |Owner:  Nasir
 |  Hussain
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  ArrayField   | Triage Stage:  Accepted
  PostreSQL index update |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nasir Hussain):

 * has_patch:  0 => 1


Comment:

 Created a [https://github.com/django/django/pull/11712 PR].

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

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

Re: [Django] #30752: Allow using ExceptionReporter subclass in django.views.debug.technical_500_response

2019-09-03 Thread Django

#30752: Allow using ExceptionReporter subclass in
django.views.debug.technical_500_response
-+--
 Reporter:  Carlton Gibson   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Description changed by Carlton Gibson:

Old description:

> #29714 allows using an ExceptionReporter subclass with AdminEmailHandler.
>
> Ideally we'd make the similar available for the 500 debug error view.
>
> Currently the use of `ExceptionReporter` is hardcoded.
>
> * Move this to a parameter
> * Provide an example of using, e.g., `functools.partial` to configure a
> subclass with specifying `handler500`.

New description:

 #29714 allows using an ExceptionReporter subclass with AdminEmailHandler.

 Ideally we'd make the similar available for the 500 debug error view.

 
[https://github.com/django/django/blob/52e9c753659ffeab67149fcf26b95c10cf137c40/django/views/debug.py#L84-L95
 Currently the use of `ExceptionReporter` is hardcoded.]

 * Move this to a parameter
 * Provide an example of using, e.g., `functools.partial` to configure a
 subclass with specifying `handler500`.

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.8c6fbdd5c6c040b71f3b3928c9565149%40djangoproject.com.

[Django] #30752: Allow using ExceptionReporter subclass in django.views.debug.technical_500_response

2019-09-03 Thread Django

#30752: Allow using ExceptionReporter subclass in
django.views.debug.technical_500_response
---+
   Reporter:  Carlton Gibson   |  Owner:  (none)
   Type:  New feature  | Status:  new
  Component:  Error reporting  |Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+
 #29714 allows using an ExceptionReporter subclass with AdminEmailHandler.

 Ideally we'd make the similar available for the 500 debug error view.

 Currently the use of `ExceptionReporter` is hardcoded.

 * Move this to a parameter
 * Provide an example of using, e.g., `functools.partial` to configure a
 subclass with specifying `handler500`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.4e1f53bbbce7018ee2b90bbfc317ca87%40djangoproject.com.

[Django] #30751: Old bug: IntegrityError with TransactionTestCase and serialized_rollback=True

2019-09-03 Thread Django

#30751: Old bug: IntegrityError with TransactionTestCase and
serialized_rollback=True
-+-
   Reporter:  raywtham   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing|Version:  2.2
  framework  |   Keywords:
   Severity:  Normal |  APITransactionTestCase
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I experienced the same issue in #23727 (which is marked as fixed)

 {{{
 Traceback (most recent call last):
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UniqueViolation: duplicate key value violates unique
 constraint "django_content_type_app_label_model_76bd3d3b_uniq"
 DETAIL:  Key (app_label, model)=(admin, logentry) already exists.


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/usr/local/lib/python3.6/site-packages/django/test/testcases.py",
 line 267, in __call__
 self._pre_setup()
   File "/usr/local/lib/python3.6/site-packages/django/test/testcases.py",
 line 938, in _pre_setup
 self._fixture_setup()
   File "/usr/local/lib/python3.6/site-packages/django/test/testcases.py",
 line 987, in _fixture_setup
 connections[db_name]._test_serialized_contents
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/base/creation.py", line 133, in
 deserialize_db_from_string
 obj.save()
   File "/usr/local/lib/python3.6/site-
 packages/django/core/serializers/base.py", line 223, in save
 models.Model.save_base(self.object, using=using, raw=True, **kwargs)
   File "/usr/local/lib/python3.6/site-packages/django/db/models/base.py",
 line 779, in save_base
 force_update, using, update_fields,
   File "/usr/local/lib/python3.6/site-packages/django/db/models/base.py",
 line 870, in _save_table
 result = self._do_insert(cls._base_manager, using, fields, update_pk,
 raw)
   File "/usr/local/lib/python3.6/site-packages/django/db/models/base.py",
 line 908, in _do_insert
 using=using, raw=raw)
   File "/usr/local/lib/python3.6/site-
 packages/django/db/models/manager.py", line 82, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/usr/local/lib/python3.6/site-packages/django/db/models/query.py",
 line 1186, in _insert
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/usr/local/lib/python3.6/site-
 packages/django/db/models/sql/compiler.py", line 1332, in execute_sql
 cursor.execute(sql, params)
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 67, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/usr/local/lib/python3.6/site-packages/django/db/utils.py", line
 89, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/usr/local/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 django.db.utils.IntegrityError: duplicate key value violates unique
 constraint "django_content_type_app_label_model_76bd3d3b_uniq"
 DETAIL:  Key (app_label, model)=(admin, logentry) already exists.
 }}}

 I am currently using this as a workaround:
 {{{
 TEST_NON_SERIALIZED_APPS = ['django.contrib.contenttypes',
 'django.contrib.auth']
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.84c31351d803244a7f6eb664a1e8777d%40djangoproject.com.

Re: [Django] #29714: Make it easier to customise ExceptionReporter output.

2019-09-03 Thread Django

#29714: Make it easier to customise ExceptionReporter output.
-+-
 Reporter:  Vasili Korol |Owner:  Nasir
 |  Hussain
 Type:  New feature  |   Status:  assigned
Component:  Error reporting  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  email, reports,  | Triage Stage:  Ready for
  cookies|  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/11021 PR #11021] allows using an
 ExceptionReporter subclass with AdminEmailHandler.

 That's half the job. The other bit is making the reporter class pluggable
 for the 500 debug error view. I think we should address that separately.
 (Being DEBUG only it's not quite so pressing.)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fda8b3e1f444185f62c0ed53f701%40djangoproject.com.

Re: [Django] #30691: Change uuid field to FK does not create dependency

2019-09-03 Thread Django

#30691: Change uuid field to FK does not create dependency
+
 Reporter:  Dart|Owner:  Dart
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  UUID, FK| Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Dart):

 Replying to [comment:4 Simon Charette]:
 > Hello Dart,
 >
 > Are you still planing to work on this? Do you need any assistance
 submitting a patch?

 Hi! Today i will send a patch. I found a problem and resolve it.

 Regards

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.59d25d4d8626b6b1c1c9ddb574aeaa98%40djangoproject.com.

Re: [Django] #28699: Document that REMOTE_USER must be logged in before making CSRF protected requests.

2019-09-03 Thread Django

#28699: Document that REMOTE_USER must be logged in before making CSRF protected
requests.
---+
Reporter: stephanm |Owner: Rodrigo
Type: Bug| Status: assigned
Component: Documentation | Version: 1.11
Severity: Normal | Resolution:
Keywords: remote user| Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
---+

Comment (by Carlton Gibson):

> For this ticket I think documenting that remote user auth will require
two requests — one to login, on to submit further data passing CSRF — is
the best we can do.

Actually, I'm not exactly sure what to say here. Thinking about it,
exactly the same considerations apply to all login. You'd have to take
special measures to login a user and submit additional form data, whilst
also checking CSRF, in a single request, even if you were using session
based authentication with the model backend. (You'd write a view to do it,
manually calling `login()` yourself...)

I'm kind of inclined towards `wontfix` for that reason...

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.fbb4de0bc3b53b58b9b4e71e0515517f%40djangoproject.com.

Re: [Django] #30750: Add support for check constraints on MySQL 8.0.16+.

2019-09-03 Thread Django

#30750: Add support for check constraints on MySQL 8.0.16+.
-+-
 Reporter:  felixxm  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL, check | Triage Stage:  Accepted
  constraints|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 Thanks for making the ticket Mariusz. Yeah MySQL 8 is quite a change.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a9a1469e420d2bf63d942dfdad320624%40djangoproject.com.

Re: [Django] #28699: Document that REMOTE_USER must be logged in before making CSRF protected requests. (was: Document middleware ordering requirements following CSRF change in Django 1.11.6)

2019-09-03 Thread Django

#28699: Document that REMOTE_USER must be logged in before making CSRF protected
requests.
---+
 Reporter:  stephanm   |Owner:  Rodrigo
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  remote user| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Carlton Gibson):

 * keywords:   => remote user
 * needs_better_patch:  1 => 0
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c72a90d3a2212b6facd2e31917188db6%40djangoproject.com.

Re: [Django] #28699: Document middleware ordering requirements following CSRF change in Django 1.11.6

2019-09-03 Thread Django

Comment (by Carlton Gibson):

Right, some time later...

I think that prior to c4c128d67c7dc2830631c6859a204c9d259f1fb1 (for
#28488) there was actually a security issue in the way
`CsrfViewMiddleware` worked.
It would call `_get_token()` in `process_view()`, resetting the CSRF token
to the one submitted in the request, even though `rotate_token()` had
previously been
called during `login()` by the `RemoteUserMiddleware`.

This is equivalent to the `CsrfViewMiddleware` second case discussed
above. It allows the Login + CSRF check in the single request but is not
safe.
As such, that the behaviour changed slightly cannot be considered a
regression. (It should never have worked.)

**Possibly** `RemoteUserMiddleware` could be adjusted to defer rotating
the CSRF token (until say `process_response()`), but anything in that
ball-park is highly sensitive, and probably not worth the price of
admission.

For this ticket I think documenting that remote user auth will require two
requests — one to login, on to submit further data passing CSRF — is the
best we can do.

--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.cb7640a5f539d7b1a8cb33cd1ba1830e%40djangoproject.com.

Re: [Django] #30750: Add support for check constraints on MySQL 8.0.16+.

2019-09-03 Thread Django

#30750: Add support for check constraints on MySQL 8.0.16+.
-+-
 Reporter:  felixxm  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL, check | Triage Stage:  Accepted
  constraints|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 I've started to work on a patch but still a lot of `schema` tests are
 failing on MySQL 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.38a315477be53f40c5954850bfe9cc89%40djangoproject.com.

Re: [Django] #30750: Add support for check constraints on MySQL 8.0.16+.

2019-09-03 Thread Django

#30750: Add support for check constraints on MySQL 8.0.16+.
-+-
 Reporter:  felixxm  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL, check | Triage Stage:  Accepted
  constraints|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * Attachment "30750.diff" added.

 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b343bfe2a779dde6fa097f972ed23dd2%40djangoproject.com.

54 matches

Mail list logo