Re: [Django] #30042: Use of kwargs in the tutorial.

[Django]

#30042: Use of kwargs in the tutorial.
-+-
 Reporter:  JPWILSON |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  kwargs, tutorial | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 It's referring to the `kwargs` argument of `path()`.

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

Re: [Django] #28658: Move DISTINCT handling to the Aggregate base class.

[Django]

#28658: Move DISTINCT handling to the Aggregate base class.
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * needs_better_patch:  1 => 0


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

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

[Django] #30042: Use of kwargs in the tutorial.

[Django]

#30042: Use of kwargs in the tutorial.
-+-
   Reporter:  JPWILSON   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  2.1
  Documentation  |
   Severity:  Normal |   Keywords:  kwargs, tutorial
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Lines 360 and 361 of docs/intro/tutorial01.txt states:

 "We aren't going to use this feature of Django in the tutorial."
 However, as the tutorial makes use of it, would it not be better to say:
 "kwargs are used in the URLconf in the 'polls' directory: name='index' "

 Apologies if incorrect, I am just learning Django and going through the
 tutorial for the first time.

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

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

Re: [Django] #29851: Window Frame Doesn't Work In SubQuery

[Django]

#29851: Window Frame Doesn't Work In SubQuery
-+-
 Reporter:  Daniel Fuchs |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (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 felixxm):

 * owner:  nobody => felixxm
 * status:  new => assigned


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

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

Re: [Django] #30023: SQLite schema editor can cause table corruption if used within a transaction since Django 2.0

[Django]

#30023: SQLite schema editor can cause table corruption if used within a
transaction since Django 2.0
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  2.0
 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):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #12952: Models history doesn't use verbose names

[Django]

#12952: Models history doesn't use verbose names
-+-
 Reporter:  Antonio Cangiano |Owner:  Sanyam
 Type:   |  Khurana
  Cleanup/optimization   |   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
-+-
Changes (by Carlton Gibson):

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


Comment:

 There were just a couple more comments on the ticket. Sanyam, please
 uncheck Patch needs improvement when you've had a look at those. (Thanks
 for the great effort!)

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

Re: [Django] #30033: SQLite schema editor should use the documented process to emulate table alterations on SQlite3. (was: SQLite schema editor should use the documented to emulate table alterations o

[Django]

#30033: SQLite schema editor should use the documented process to emulate table
alterations on SQlite3.
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/067.0ef71d2ebb0d2575f74882c59c14675b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29928: TestCase doesn't check for foreign key constraints when using sqlite

[Django]

#29928: TestCase doesn't check for foreign key constraints when using sqlite
-+-
 Reporter:  Michel Samia |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite db foreign| Triage Stage:  Ready for
  key TestCase   |  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.ee6b870d57d2f32294910bb3de016670%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30040: Documentation on permissions on templates is wrong

[Django]

#30040: Documentation on permissions on templates is wrong
-+-
 Reporter:  Adrian Samatan   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  template | Triage Stage:  Accepted
  permissions documentation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Now I see that a confusion may happen because the standard permission
 verbose name is "Can view foo". So I would suggest to either use a
 standard add/change/delete/view permission codename, or use a custom name
 that doesn't have `can` in its name (or anything else which might suggest
 it is a standard permission).

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

Re: [Django] #30040: Documentation on permissions on templates is wrong

[Django]

#30040: Documentation on permissions on templates is wrong
-+-
 Reporter:  Adrian Samatan   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  template | Triage Stage:
  permissions documentation  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 I think `can_vote` here is to be considered as any custom permission
 codename added to some model, it does not refer to a default permission
 name automatically created for models. The default names are `add_foo`,
 `change_foo`, `delete_foo` (and since Django 2.1, `view_foo`).

 So the question is: should we use a standard permission codename in the
 examples instead of an arbitrary permission codename? I have no strong
 opinion on this.

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

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

Re: [Django] #30017: Django should assume port 443 for https in django.utils.http.is_same_domain()

[Django]

#30017: Django should assume port 443 for https in
django.utils.http.is_same_domain()
---+--
 Reporter:  Ruslan Dautkhanov  |Owner:  (none)
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  2.1
 Severity:  Normal |   Resolution:  wontfix
 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 Carlton Gibson):

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


Comment:

 Please TicketClosingReasons/DontReopenTickets.

 I see three options here:

 1. Correct the Nginx config. This seems the obvious answer, the one on the
 Stack Overflow thread, and presumably you have no problem with it, since
 you think `web.site.com` and `web.site.com:443` are equivalent, so there's
 no harm dropping the `$server_port` bit.
 2. Add `web.site.com:443` to `CSRF_TRUSTED_ORIGINS`
 ([https://code.djangoproject.com/ticket/28488#comment:39 as others have
 done here]).
 3. **Add logic** examining the environment to infer the `443` port.

 I'm sure we could get 3 roughly right with some effort. But I'm equally
 sure that it would turn out to be wrong for someone's setup. Then we'd
 have to add edge-case handling and opt-outs and all the rest of it.

 In my view such things are **simply not worth the effort** when options 1
 and 2 are available. I suggest you take one of those.

 > I wish there would be a way to disable referer check altogether.

 You could always subclass the CSRF middleware. I wouldn't do that. (I'd go
 with option 1.)

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

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