Re: [Django] #30107: Templates cached Loader documentation is outdated

[Django]

#30107: Templates cached Loader documentation is outdated
-+-
 Reporter:  Nasir Hussain|Owner:  Nasir
 Type:   |  Hussain
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 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 Nasir Hussain):

 * owner:  nobody => Nasir Hussain
 * 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/069.1cbcc7950e3fbab2fa401c1bd8157343%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30107: Templates cached Loader documentation is outdated

[Django]

#30107: Templates cached Loader documentation is outdated
+
   Reporter:  Nasir Hussain |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   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 |
+
 Regarding the comment on
 
https://github.com/django/django/blob/master/django/template/loaders/cached.py#L69

 There was a parameter **template_dirs** which was deprecated and removed a
 long time ago. Now cache key only uses template_name and skip. So the
 comment should be updated from **Generate a cache key for the template
 name, dirs, and skip** to  **Generate a cache key for the template name
 and skip.**

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

[Django] #30106: Use bulk_update to perform order_with_respect to updates

[Django]

#30106: Use bulk_update to perform order_with_respect to updates
-+-
   Reporter:  Simon  |  Owner:  nobody
  Charette   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 There's a FIXME about it

 
https://github.com/django/django/blob/aa5fd84f53f09338d01a3cfd9fa6ab08e418fe00/django/db/models/base.py#L1785-L1789

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

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

Re: [Django] #30091: Invalid HTTP_HOST header causes CsrfViewMiddleware failure

[Django]

#30091: Invalid HTTP_HOST header causes CsrfViewMiddleware failure
---+--
 Reporter:  Mark Gregson   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Mark Gregson):

 Okay, I've just attached a minimal working example.  I've provided it as a
 patch to a 'django-admin startproject' site template using Django 1.11.18.
 You should just be able to do:
 1. django-admin startproject mysite
 2. cd mysite
 3. patch -p1 < min_example.diff

 In this example I've configured ALLOWED_HOSTS = ['localhost'] and added
 '127.0.0.1 dummy' to my /etc/hosts file. Requesting http://dummy:8000/
 reproduces the ImproperlyConfigured exception.

 While producing this example I found that placing CommonMiddleware before
 SessionMiddleware was also required to reproduce the bug.  I'm unsure if
 this is a configuration error; but I couldn't see anything about ordering
 of those two middleware classes when I scanned the documentation just now.

 Cheers
 Mark

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

Re: [Django] #30091: Invalid HTTP_HOST header causes CsrfViewMiddleware failure

[Django]

#30091: Invalid HTTP_HOST header causes CsrfViewMiddleware failure
---+--
 Reporter:  Mark Gregson   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mark Gregson):

 * Attachment "min_example.diff" added.

 Patch to create minimal project reproducing the bug

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

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

Re: [Django] #30091: Invalid HTTP_HOST header causes CsrfViewMiddleware failure

[Django]

#30091: Invalid HTTP_HOST header causes CsrfViewMiddleware failure
---+--
 Reporter:  Mark Gregson   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Mark Gregson):

 Hi Carlton. Not one I can easily share. I'll see if I can create a minimal
 project that reproduces it.

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

Re: [Django] #30090: Cannot reverse MySQL DB migration when model has unique_together and one of the fields has db_index=True

[Django]

#30090: Cannot reverse MySQL DB migration when model has unique_together and 
one of
the fields has db_index=True
--+--
 Reporter:  Andy McCurdy  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Migrations|  Version:  2.1
 Severity:  Normal|   Resolution:  needsinfo
 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:   => needsinfo


Comment:

 >  … if I can figure out how to repro it again I'll reopen this …

 OK. Lets do that. A test case is obviously best but a test project would
 do. 

 Thanks for the follow up Andy.

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

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

Re: [Django] #30090: Cannot reverse MySQL DB migration when model has unique_together and one of the fields has db_index=True

[Django]

#30090: Cannot reverse MySQL DB migration when model has unique_together and 
one of
the fields has db_index=True
--+--
 Reporter:  Andy McCurdy  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 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 Andy McCurdy):

 Hi Carlton. I added a test but couldn't reproduce the error in the test
 suite against a branch based off master. I went back to the test project I
 made (where the code above is copied from and using Django 2.1.5) and that
 too seems to be working now. I'm very confused. The test project is
 isolated in its own virtualenv and no dependencies have been changed since
 I created the test project and filed the bug report.

 So at this point I'm unable to reproduce the issue. Perhaps we should
 close this and if I can figure out how to repro it again I'll reopen this
 or file a new bug.

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

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

Re: [Django] #29975: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Django]

#29975: Password reset emails in combination with click tracking do not work 
with
Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave
-+-
 Reporter:  Mat Gadd |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  safari, privacy, | Triage Stage:
  auth, password reset   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by René Fleschenberg):

 Just for the record: I believe this affects all users who use Safari in
 combination with Gmail, which seems to be a somewhat popular combination.

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

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

Re: [Django] #29975: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Django]

#29975: Password reset emails in combination with click tracking do not work 
with
Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave
-+-
 Reporter:  Mat Gadd |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  safari, privacy, | Triage Stage:
  auth, password reset   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by René Fleschenberg):

 * cc: René Fleschenberg (added)


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

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

Re: [Django] #29975: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Django]

#29975: Password reset emails in combination with click tracking do not work 
with
Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave
-+-
 Reporter:  Mat Gadd |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  safari, privacy, | Triage Stage:
  auth, password reset   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by René Fleschenberg):

 I filed an issue on the WebKit bug tracker:
 https://bugs.webkit.org/show_bug.cgi?id=193502

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

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

Re: [Django] #30044: A FieldError should be raised when trying to update with F reference to MTI inherited field

[Django]

#30044: A FieldError should be raised when trying to update with F reference to 
MTI
inherited field
-+-
 Reporter:  Tom Carrick  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"9e5e5a657b95ee49923fe3d2691c5d73813b4c53" 9e5e5a65]:
 {{{
 #!CommitTicketReference repository=""
 revision="9e5e5a657b95ee49923fe3d2691c5d73813b4c53"
 Fixed #30044 -- Raised a FieldError on inherited field update attempts.
 }}}

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

Re: [Django] #20147: Provide an alternative to request.META for accessing HTTP headers

[Django]

#20147: Provide an alternative to request.META for accessing HTTP headers
-+-
 Reporter:  Luke Plant   |Owner:  Santiago
 |  Basulto
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"4fc35a9c3efdc9154efce28cb23cb84f8834517e" 4fc35a9c]:
 {{{
 #!CommitTicketReference repository=""
 revision="4fc35a9c3efdc9154efce28cb23cb84f8834517e"
 Fixed #20147 -- Added HttpRequest.headers.
 }}}

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

Re: [Django] #28687: Add a 'Not Empty' option to admin's related filter

[Django]

#28687: Add a 'Not Empty' option to admin's related filter
-+-
 Reporter:  Brillgen Developers  |Owner:  Jake
 Type:   |  Barber
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * resolution:  fixed => wontfix


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

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

Re: [Django] #30079: Prefetch cache should be aware of database source and .using() should not always trigger a new query

[Django]

#30079: Prefetch cache should be aware of database source and .using() should 
not
always trigger a new query
-+-
 Reporter:  Mike Lissner |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch,| Triage Stage:
  multidatabase  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mike Lissner):

 Replying to [comment:1 Carlton Gibson]:
 > On the basis of the difference between `ln64` and `ln65` I'm inclined to
 accept this. `pizza0` came from `replica` and the `ln64` call just goes
 with that. (That seems right/expected to me...) I see your point that
 adding the `using()` shouldn't change that.

 Good! I made myself clear. Always a good thing.

 > At first glance the ''"if you didn't add a `filter()`/`exclude()`"''
 idea seems OK too.

 That was my analysis too: "This seems to be a reasonable line in the
 sand."

 > Two questions though:
 >
 > 1. What's the use-case for re-adding the `using()` call in `ln65`? I
 can't quite see why you'd do that...? (Another way of looking at `using()`
 might be "go back to **this** DB"...)

 I can't make a really clear argument for my use case, but basically it
 was, "I'm doing weird things with prefetching and I want to be sure Django
 pulls this data properly from the right DB/cache." In other words, it was
 me trying to be explicit about where the caches were *supposed* come from,
 and then getting bit by having the caches busted. From my reading, ln64 is
 totally unclear which DB it would use since it would normally use the
 "default" DB, but had a cached value, so which wins? My solution was to be
 more explicit to make sure it used the cache, but that backfired (luckily,
 I was watching the query logs).

 > 2. Have you looked at all at what a patch might look like? (If it's
 simple enough, that helps...)

 No, not at all, unfortunately. I've looked into the Django code from time
 to time, but mostly I stay on my side of the API, lest I get in trouble.
 Especially when it comes to the ORM bits.

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

Re: [Django] #28687: Add a 'Not Empty' option to admin's related filter

[Django]

#28687: Add a 'Not Empty' option to admin's related filter
-+-
 Reporter:  Brillgen Developers  |Owner:  Jake
 Type:   |  Barber
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Sardorbek.

 This looks like a (related but) separate issue. Can you submit a new
 ticket, something along the lines of "Empty value `selected` check in
 Admin Filter prevents subclassing" and we can have a look.

 At first glance I can't see how both `bool(self.lookup_val_isnull)` and
 `self.lookup_val_isnull == 'False'` evaluate as `True` in the `Not Empty`
 case. (???) Surely the existing `empty_choice` logic would already be
 broken if they did.

 If you have a PR (with a test case showing the broken example) available
 (or can provide one when opening the ticket) it makes it much easier to
 assess.

 Thanks.

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

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

Re: [Django] #28290: Doc sections are missing target (labels) links

[Django]

#28290: Doc sections are missing target (labels) links
-+-
 Reporter:  Tony Narlock |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  docs labels  | Triage Stage:  Accepted
  intersphinx|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * owner:  Tony Narlock => (none)
 * status:  assigned => new


Comment:

 Hi Tony, I'm going to deassign this. It's been 20months without a patch,
 and as an Easy Pickings ticket it's likely to get picked up quickly if not
 claimed. Please do reclaim if you do in fact have a patch. Thanks for the
 report!

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

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

Re: [Django] #30102: Optimize the `page_not_found` view after #30070

[Django]

#30102: Optimize the `page_not_found` view after #30070
-+-
 Reporter:  Illia Volochii   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 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
-+-

Comment (by GitHub ):

 In [changeset:"876dc306cd508a041ccc62cf87397514fce4c9f3" 876dc30]:
 {{{
 #!CommitTicketReference repository=""
 revision="876dc306cd508a041ccc62cf87397514fce4c9f3"
 Refs #30102 -- Added comment on use of Template without placeholders in
 page_not_found() view.
 }}}

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

Re: [Django] #30098: Permit using packages (directories) in custom django-admin commands.

[Django]

#30098: Permit using packages (directories) in custom django-admin commands.
-+-
 Reporter:  Andrey Volkov|Owner:  Andrey
 |  Volkov
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  2.1
  commands)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Andrey. Thanks for the suggestion and PR demonstrating it. As it stands
 I think I agree with Tim's initial comment.

 I'm not sure I see any real benefit to allowing packages here. It's
 already possible to add a package to contain any supporting files (if
 there's more than one) — either in `management` or in `commands` — so I'm
 not convinced any extra encapsulation merits the change. (I'm not sure I
 buy either the ''renaming'' or ''extra features'' points you make.)

 The restriction to modules has been there ≈forever. See
 f25b8cdbcdc99812299e9081cd3b03ddc08dcf74 for #5222, which introduced
 `find_commands()`. Just on the principle that ''There should be one-- and
 preferably only one --obvious way to do it.'' I don't think changing that
 design choice is merited.

 Also, people will be using the fact that you **can** put a package in
 `commands` and not have it detected. If we change that such packages will
 be picked up by `find_commands()` and we'll have a whole load of reports
 of `help` listing phantom commands that only lead to `AttributeError:
 module '...' has no attribute 'Command'` errors when invoked.

 So for both these reasons I'm going to opt for `wontfix` here. Possibly
 you could raise it on the DevelopersMailingList if you feel strongly on
 the issue.

 Thanks again.

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

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

Re: [Django] #22270: Explain permissions on proxy models

[Django]

#22270: Explain permissions on proxy models
-+-
 Reporter:  Gert Steyn   |Owner:  Arthur
 Type:   |  Rio
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.6
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  proxy models | Triage Stage:  Accepted
  permissions|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"181fb60159e54d442d3610f4afba6f066a6dac05" 181fb601]:
 {{{
 #!CommitTicketReference repository=""
 revision="181fb60159e54d442d3610f4afba6f066a6dac05"
 Fixed #11154, #22270 -- Made proxy model permissions use correct content
 type.

 Co-Authored-By: Simon Charette 
 Co-Authored-By: Antoine Catton 
 }}}

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

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

Re: [Django] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+-
 Reporter:  Dave Hall|Owner:  Arthur
 |  Rio
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  proxy contenttype| Triage Stage:  Accepted
  permission |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"181fb60159e54d442d3610f4afba6f066a6dac05" 181fb601]:
 {{{
 #!CommitTicketReference repository=""
 revision="181fb60159e54d442d3610f4afba6f066a6dac05"
 Fixed #11154, #22270 -- Made proxy model permissions use correct content
 type.

 Co-Authored-By: Simon Charette 
 Co-Authored-By: Antoine Catton 
 }}}

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

Re: [Django] #9475: add(), create(), etc. should be supported by intermediate ManyToMany model with extra attributes if extra fields can be calculated

[Django]

#9475: add(), create(), etc. should be supported by intermediate ManyToMany 
model
with extra attributes if extra fields can be calculated
-+-
 Reporter:  omat@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"dbcf2ffa77af24642c035c58199e6058d91d8e35" dbcf2ff]:
 {{{
 #!CommitTicketReference repository=""
 revision="dbcf2ffa77af24642c035c58199e6058d91d8e35"
 Refs #9475 -- Simplified dictionary unpacking.
 }}}

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

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

Re: [Django] #30091: Invalid HTTP_HOST header causes CsrfViewMiddleware failure

[Django]

#30091: Invalid HTTP_HOST header causes CsrfViewMiddleware failure
---+--
 Reporter:  Mark Gregson   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Hi Mark. Do you have an example project you can upload demonstrating this
 issue? Thanks!

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

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

Re: [Django] #30090: Cannot reverse MySQL DB migration when model has unique_together and one of the fields has db_index=True

[Django]

#30090: Cannot reverse MySQL DB migration when model has unique_together and 
one of
the fields has db_index=True
--+--
 Reporter:  Andy McCurdy  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 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 Carlton Gibson):

 Hi Andy. Do you have capacity to put your test case into a PR on GitHub so
 that we can see it in the CI? (I can do it if not but you've likely
 already got it bootstrapped, so that'd save a few cycles. )

 Thanks

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

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

Re: [Django] #30079: Prefetch cache should be aware of database source and .using() should not always trigger a new query

[Django]

#30079: Prefetch cache should be aware of database source and .using() should 
not
always trigger a new query
-+-
 Reporter:  Mike Lissner |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch,| Triage Stage:
  multidatabase  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * version:  2.1 => master
 * type:  Bug => Cleanup/optimization


Comment:

 Hi Mike. Thanks for the report.

 On the basis of the difference between `ln64` and `ln65` I'm inclined to
 accept this. `pizza0` came from `replica` and the `ln64` call just goes
 with that. (That seems right/expected to me...) I see your point that
 adding the `using()` shouldn't change that.

 At first glance the ''"if you didn't add a `filter()`/`exclude()`"'' idea
 seems OK too.

 Two questions though:

 1. What's the use-case for re-adding the `using()` call in `ln65`? I can't
 quite see why you'd do that...?
 2. Have you looked at all at what a patch might look like? (If it's simple
 enough, that helps...)

 Thanks.

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

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

Re: [Django] #30102: Optimize the `page_not_found` view after #30070

[Django]

#30102: Optimize the `page_not_found` view after #30070
-+-
 Reporter:  Illia Volochii   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 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:

 As per [https://github.com/django/django/pull/10841 discussion on the
 original PR], there are test cases relying on the template context being
 available on the response. Working around this ~~probably~~ isn't worth
 the effort. [https://github.com/django/django/pull/10855 Follow-up PR]
 adds a comment explaining the usage, as per Tim's suggestion.

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

Re: [Django] #30095: System check error for tuples in model field choices

[Django]

#30095: System check error for tuples in model field choices
-+-
 Reporter:  Pedro Marcondes  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  choices tuple| 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):

 * Attachment "regression_30095.py" added.

 Test cased used for bisecting change. (Saved in `postgres_tests`

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

Re: [Django] #30095: System check error for tuples in model field choices

[Django]

#30095: System check error for tuples in model field choices
-+-
 Reporter:  Pedro Marcondes  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  choices tuple| 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):

 * severity:  Release blocker => Normal


Comment:

 OK, lets downgrade this to `Normal`: the change in behaviour of the
 **system check** isn't quite a change in behaviour of the code itself.
 (The [https://docs.djangoproject.com/en/2.1/ref/settings/#silenced-system-
 checks system check can always be silenced].)

 * Implementing `RangeField._check_choices()` would be feasible.
 * Maybe raising the `is_value()` helper to class level would allow
 avoiding too much duplication.
  * We may need to separate the `is_value()` logic from the
 `is_human_readable_label()` test — currently the `is_value()` helper is
 used for both tasks.
 * Maybe a fix to #20749 addresses this too, but they don't seem quite the
 same. (I could see a fix for this without the more general problem being
 solved.)

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