Re: [Django] #31751: Add support for cx_Oracle 8

2020-06-30 Thread Django
#31751: Add support for cx_Oracle 8
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 OK, yes. Given that 3.0 is still in mainstream support we should backport
 for that.

-- 
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.0cdb2e2331f1d82cf007a5ad5e4632ac%40djangoproject.com.


Re: [Django] #28925: durations-only expressions doesn't work on SQLite and MySQL

2020-06-30 Thread Django
#28925: durations-only expressions doesn't work on SQLite and MySQL
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"dd5aa8cb5ffc0a89c4b9b8dee45c1c919d203489" dd5aa8cb]:
 {{{
 #!CommitTicketReference repository=""
 revision="dd5aa8cb5ffc0a89c4b9b8dee45c1c919d203489"
 Fixed #28925 -- Fixed durations-only expressions crash on SQLite and
 MySQL.

 This removes also unused DatabaseOperations.date_interval_sql().
 }}}

-- 
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/068.56c5a7da752b82e3ba6c3d189a68baa1%40djangoproject.com.


Re: [Django] #28925: durations-only expressions doesn't work on SQLite and MySQL

2020-06-30 Thread Django
#28925: durations-only expressions doesn't work on SQLite and MySQL
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"9d752dabe38602a71452ed8c23253e780a40a560" 9d752dab]:
 {{{
 #!CommitTicketReference repository=""
 revision="9d752dabe38602a71452ed8c23253e780a40a560"
 Refs #28925 -- Simplified CombinedExpression.as_sql() a bit.
 }}}

-- 
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/068.26c17b5ff776a81733b70cf54ff4a827%40djangoproject.com.


Re: [Django] #31747: Avoid potential admin model enumeration (was: Model enumeration)

2020-06-30 Thread Django
#31747: Avoid potential admin model enumeration
---+
 Reporter:  Daniel Maxson  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  3.0
 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 Carlton Gibson):

 * type:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 Thanks Daniel.

 Pasting here extracts from the security team discussion. This idea of
 adding a `final_catch_all_pattern` seems most likely:

 > Well, I vaguely recalled, and managed to find,
 > https://groups.google.com/d/msgid/django-
 
developers/CAHdnYzu2zHVMcrjsSRpvRrdQBMntqy%2Bh0puWB2-uB8GOU6Tf7g%40mail.gmail.com
 > where we discussed achieving similar goals using middlewares rather
 > than view or URL manipulation. I believe a middleware which translates
 > 404 exceptions in admin urls for unauthenticated users into redirects
 > to the admin login would essentially solve the problem[1], without
 > breaking existing URLConfs.
 >
 > If this solution of the issue is accepted, I'm not sure how to apply it
 > to existing projects -- adding a middleware may require them to edit
 > their settings, not just to upgrade (although the vulnerability may be
 > light enough to handle by providing the middleware and just
 > recommending its use).
 >
 > [1] Assuming we make no special effort to avoid it, this information
 > may still be leaked using a timing attack -- that is, it should take a
 > little more time to respond to a URL for a non-existing model. I'm not
 > sure protecting against that would be worthwhile.



 > > I believe a middleware which translates
 > > 404 exceptions in admin urls for unauthenticated users into redirects
 > > to the admin login would essentially solve the problem[1], without
 > > breaking existing URLConfs.
 >
 > The main issues I see with a middleware is:
 > a) how to enable it (as you also noticed)
 > b) which URLs should it apply to?
 >
 > I think the latter is rather important since we explicitly advise to not
 use /admin in the first place :) With an URLConf approach we could just
 add a catch-all pattern to the end of admin.site.urls (with all issues
 that follow from that). We might add an attribute ala
 `final_catch_all_pattern = True` to `AdminSite` to allow disabling this
 rather light issue (then it would be up to the site developer to add a
 final catch all)
 >
 > FWIW this issue also applies to authenticated model enumeration
 (basically a site which allows login but has limited staff/admin access --
 something we should consider when coming up with the patch).


 > You are correct, of course. The middleware-based approach requires
 > extra configuration -- a setting, probably; and I agree that this is a
 > little ugly (my thinking was a little influenced by the tags idea in
 > the thread I referred to, which would mostly allow overcoming this, I
 > think).
 >
 > > With an URLConf approach we
 > > could just add a catch-all pattern to the end of admin.site.urls
 > > (with all issues that follow from that). We might add an attribute
 > > ala `final_catch_all_pattern = True` to `AdminSite` to allow
 > > disabling this rather light issue (then it would be up to the site
 > > developer to add a final catch all)
 >
 > That seems good enough. I'd consider, in this case, adding the option
 > with default False in 3.0.x and making the non-backward-compatible
 > change only in 3.1.
 >
 > > FWIW this issue also applies to authenticated model enumeration
 > > (basically a site which allows login but has limited staff/admin
 > > access -- something we should consider when coming up with the patch).
 >
 > IIUC, this code[1] does it, and it is arguably incorrect in the case of
 > an authenticated user accessing a model they don't have permission for.
 > What if we just changed that to raise a 404? Wouldn't that fix both
 > cases? FWIW, that is what Github does when you try to access a private
 > repo you don't have access to.
 >
 >
 
[1]https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L222-L232


 > > What if we just changed that to raise a 404? Wouldn't that fix both
 > > cases? FWIW, that is what Github does when you try to access a private
 > > repo you don't have access to.
 > >
 > >
 
[1]https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L222-L232
 >
 > Raising a 404 would definitely help here, but the usability of that
 > sucks imo.
 >
 > Do we think we can fix this in public and gather more input?

-- 
Ticket URL: 

Re: [Django] #12091: Support for WSGI applications within Django

2020-06-30 Thread Django
#12091: Support for WSGI applications within Django
---+-
 Reporter:  Gustavo Narea  |Owner:  Gustavo Narea
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  WSGI   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by felixxm):

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


Comment:

 After reconsideration I think we shouldn't move it forward. It's quite
 niche, can live in a 3rd party package, and not worth the additional
 complexity. Moreover there was no consensus on the mailing list. Thanks
 for you efforts!

-- 
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.1b1b2e5f281228413d6bbbad57c1f628%40djangoproject.com.


Re: [Django] #31701: Make FileDescriptor subclass DeferredAttribute.

2020-06-30 Thread Django
#31701: Make FileDescriptor subclass DeferredAttribute.
-+-
 Reporter:  Sultan   |Owner:  Sultan
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"a93425a37f4defdb31d4ca96bb3bf6da21f0b5ce" a93425a]:
 {{{
 #!CommitTicketReference repository=""
 revision="a93425a37f4defdb31d4ca96bb3bf6da21f0b5ce"
 Fixed #31701 -- Made FileDescriptor subclass DeferredAttribute.
 }}}

-- 
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.96d4379edb6b9de3cb2f5c27c482bfcd%40djangoproject.com.


Re: [Django] #31751: Add support for cx_Oracle 8

2020-06-30 Thread Django
#31751: Add support for cx_Oracle 8
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"615e32162ff646db3456b90fb4eaaecc33dd3e4e" 615e3216]:
 {{{
 #!CommitTicketReference repository=""
 revision="615e32162ff646db3456b90fb4eaaecc33dd3e4e"
 Fixed #31751 -- Fixed database introspection with cx_Oracle 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.0258d56f58332a6b910c96c20ba6f6c8%40djangoproject.com.


Re: [Django] #31751: Add support for cx_Oracle 8

2020-06-30 Thread Django
#31751: Add support for cx_Oracle 8
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"fc2a3682f64e735321c5db85535a84207060e3da" fc2a3682]:
 {{{
 #!CommitTicketReference repository=""
 revision="fc2a3682f64e735321c5db85535a84207060e3da"
 [2.2.x] Refs #31751 -- Doc'd that cx_Oracle < 8 is required.
 }}}

-- 
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.70e9678630a42f92d70e0b2b0289e5a4%40djangoproject.com.


Re: [Django] #31752: Intermittent test failure on Windows with PostgreSQL

2020-06-30 Thread Django
#31752: Intermittent test failure on Windows with PostgreSQL
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Tests, Windows   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"b5371539a9d871758d639a85d1f2fd648c1f633d" b5371539]:
 {{{
 #!CommitTicketReference repository=""
 revision="b5371539a9d871758d639a85d1f2fd648c1f633d"
 Fixed #31752 -- Fixed intermittent
 test_order_by_relational_field_through_model failure.

 Set explicit datetime for M2M ordering test.

 Thanks to Mariusz Felisiak for the 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.75a57cd3beec8ef803bfa3b653cd4460%40djangoproject.com.


Re: [Django] #31751: Add support for cx_Oracle 8

2020-06-30 Thread Django
#31751: Add support for cx_Oracle 8
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle   | Triage Stage:  Accepted
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:"3b5e307bbc5eb8a88af6204b40aa224516260196" 3b5e307b]:
 {{{
 #!CommitTicketReference repository=""
 revision="3b5e307bbc5eb8a88af6204b40aa224516260196"
 [3.1.x] Fixed #31751 -- Fixed database introspection with cx_Oracle 8.

 Backport of 615e32162ff646db3456b90fb4eaaecc33dd3e4e from master
 }}}

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

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


Re: [Django] #31752: Intermittent test failure on Windows with PostgreSQL

2020-06-30 Thread Django
#31752: Intermittent test failure on Windows with PostgreSQL
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Tests, Windows   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * owner:  nobody => Carlton Gibson
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13126 PR] -- see if that works...

-- 
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.d84e952706f8c693a65f755c6cc14fa1%40djangoproject.com.


Re: [Django] #31752: Intermittent test failure on Windows with PostgreSQL

2020-06-30 Thread Django
#31752: Intermittent test failure on Windows with PostgreSQL
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Tests, Windows   | Triage Stage:  Accepted
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:"84640f5ae38b65fc2832e51db37d2b8be3c509c6" 84640f5a]:
 {{{
 #!CommitTicketReference repository=""
 revision="84640f5ae38b65fc2832e51db37d2b8be3c509c6"
 [3.1.x] Fixed #31752 -- Fixed intermittent
 test_order_by_relational_field_through_model failure.

 Set explicit datetime for M2M ordering test.

 Thanks to Mariusz Felisiak for the suggestion.
 Backport of b5371539a9d871758d639a85d1f2fd648c1f633d from master
 }}}

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

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


Re: [Django] #26001: Make ModelAdmin.search_fields do an integer lookup for IntegerFields

2020-06-30 Thread Django
#26001: Make ModelAdmin.search_fields do an integer lookup for IntegerFields
-+-
 Reporter:  Tim Graham   |Owner:  Nick
 Type:   |  Sandford
  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:  0
-+-

Comment (by Niclas Olofsson):

 Replying to [comment:5 Tim Graham]:
 > As far as I tested, you can now use something like  `search_fields =
 ['votes__exact']` to do the appropriate query, however, if a non-integer
 search term is entered, the page crashes with `ValueError invalid literal
 for int() with base 10: 'abc'` from `IntegerField.get_prep_value()`.
 Probably that exception should be caught in
 `ModelAdmin.get_search_results()` and no results returned.

 We have to consider that there might be multiple search fields of mixed
 types though, i.e. `search_fields = ['votes__exact', 'title',
 'text__contains']`, just so the matches for other fields does not get
 discarded just because one of the fields threw an error.

-- 
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.4b7c0dc15a3ca44aa1ea25c2156a7d4e%40djangoproject.com.


Re: [Django] #31751: Add support for cx_Oracle 8

2020-06-30 Thread Django
#31751: Add support for cx_Oracle 8
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle   | Triage Stage:  Accepted
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:"21e8f9f7c96c97e42a301e53acbfd6cb6f1a7227" 21e8f9f7]:
 {{{
 #!CommitTicketReference repository=""
 revision="21e8f9f7c96c97e42a301e53acbfd6cb6f1a7227"
 [3.0.x] Fixed #31751 -- Fixed database introspection with cx_Oracle 8.

 Backport of 615e32162ff646db3456b90fb4eaaecc33dd3e4e from master
 }}}

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

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


Re: [Django] #31744: Pydoc support/helper

2020-06-30 Thread Django
#31744: Pydoc support/helper
-+-
 Reporter:  Sardorbek Imomaliev  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 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 felixxm):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Documentation => Core (Other)
 * type:  Uncategorized => Cleanup/optimization


Comment:

 Yes, that's true. `pydoc` just like `sphinx.ext.viewcode` (see #29942)
 imports modules, that's why it will crash when required packages are
 missing or if settings are not configured. Setting
 `DJANGO_SETTINGS_MODULE` fixes this issue in most cases. I don't see a
 clear path to solve this in Django. I'm against adding a new management
 command for [https://docs.python.org/3/library/pydoc.html pydoc] and
 adding multiple `if __name__ == ...` seems clunky and decrease code
 readability.

 Maybe a discussion on DevelopersMailingList will bring some ideas, but I
 don't think it's feasible without side-effects.

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


Re: [Django] #31750: Abstract model field should not be equal across models

2020-06-30 Thread Django
#31750: Abstract model field should not be equal across models
-+-
 Reporter:  Ryan Hiebert |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (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 Carlton Gibson):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 OK, happy to look at a patch — assuming nothing breaks...

 It'd be a change in behaviour, so would need calling out in the release
 notes.

-- 
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/069.6bba220f46e1bc1b928649096a50c6a4%40djangoproject.com.


[Django] #31752: Intermittent test failure on Windows with PostgreSQL

2020-06-30 Thread Django
#31752: Intermittent test failure on Windows with PostgreSQL
-+-
   Reporter:  Carlton|  Owner:  nobody
  Gibson |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  Tests, Windows
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 [https://forum.djangoproject.com/t/gsoc-2020-parallel-test-runner/2528/17
 Reported by Ahmad on the forum], there's an intermittent test failure with
 Windows+Postgres.

 {{{
 (django) PS C:\Users\carlt\src\django\tests> python .\runtests.py
 --settings=test_postgres m2m_through.tests.M2mThroughTests
 Testing against Django installed in 'c:\users\carlt\src\django\django'
 Creating test database for alias 'default'...
 System check identified no issues (0 silenced).
 .F...
 ==
 FAIL: test_order_by_relational_field_through_model
 (m2m_through.tests.M2mThroughTests)
 --
 Traceback (most recent call last):
   File "C:\Users\carlt\src\django\tests\m2m_through\tests.py", line 247,
 in test_order_by_relational_field_through_model
 [self.jim, self.bob]
 AssertionError: Sequences differ: ,
 ]> != [, ]

 First differing element 0:
 
 

 - , ]>
 ? -- ^^   -

 + [, ]
 ?  ^^


 --
 Ran 41 tests in 0.264s

 FAILED (failures=1)
 Destroying test database for alias 'default'...
 }}}

 Looks like a non-deterministic ordering problem.

 Reproduced at 615e32162ff646db3456b90fb4eaaecc33dd3e4e.

-- 
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.8b3c04f03239aa04d7e2c449bea3a8d4%40djangoproject.com.


Re: [Django] #29049: Add slicing notation to F expressions

2020-06-30 Thread Django
#29049: Add slicing notation to F expressions
-+-
 Reporter:  Matthew Pava |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  slice F  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Niclas Olofsson):

 * owner:  Niclas Olofsson => (none)
 * status:  assigned => new


Comment:

 Since feedback on the review came 10 months after I submitted the patch,
 and it now has been more than a year since it was submitted, it would be
 too much of an effort for me to put my mind into this again and get it
 into a mergable state.

-- 
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.677082920cb9767ee28a3ae0bde7dc9d%40djangoproject.com.


[Django] #31753: SpatialReference srid -> proj4 -> srid returns wrong SRID

2020-06-30 Thread Django
#31753: SpatialReference srid -> proj4 -> srid returns wrong SRID
-+-
   Reporter:  Riccardo   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  GIS|Version:  master
   Severity:  Normal |   Keywords:  SRID;
   Triage Stage: |  SpatialReference; GDAL
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 A SpatialReference object with a specific SRID (e.g. 32630 -
 https://epsg.io/32630) can be instantiated and then transformed into a
 proj or proj4 string (method .proj/.proj4). If that string is then used to
 instantiate a new SpatialReference object, that object will have a
 different SRID, encoding a different type of projection (e.g. 6326 -
 https://epsg.io/6326).

 For example:
 {{{
 >>> from django.contrib.gis.gdal import SpatialReference
 >>> srid = 32630
 >>> p4 = SpatialReference(srid).proj4
 >>> new_sr = SpatialReference(p4)
 >>> new_sr.srid == srid
 False
 >>>  new_sr.srid
 6326
 }}}

-- 
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.c93e375f99bbea58de9ea50f913f985b%40djangoproject.com.


Re: [Django] #31685: Support updating conflicts with QuerySet.bulk_create().

2020-06-30 Thread Django
#31685: Support updating conflicts with QuerySet.bulk_create().
-+-
 Reporter:  Vitor Pereira|Owner:  Chih Sean
 |  Hsu
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk insert update   | Triage Stage:  Accepted
  upsert |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chih Sean Hsu):

 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * 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/062.3f0c7d223dfb551c0afec7703966992e%40djangoproject.com.


[Django] #31754: preserve_filters doesn't work

2020-06-30 Thread Django
#31754: preserve_filters doesn't work
-+
   Reporter:  zbynekdrlik|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  3.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I have 3.0.7 version of django. After save change view my old filters and
 search fraze has been lost.

-- 
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/054.2b6d5310cf0edda456046a155e48%40djangoproject.com.


[Django] #31755: make temporal subtraction work without ExpressionWrapper

2020-06-30 Thread Django
#31755: make temporal subtraction work without ExpressionWrapper
-+-
   Reporter:  Sergey |  Owner:  nobody
  Fedoseev   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 {{{
 class Experiment(models.Model):
 start = models.DateTimeField()
 end = models.DateTimeField()

 Experiment.objects.annotate(
 delta=F('end') - F('start') + Value(datetime.timedelta(),
 output_field=DurationField())
 )
 }}}
 This gives:
 {{{
 django.core.exceptions.FieldError: Expression contains mixed types:
 DateTimeField, DurationField. You must set output_field.
 }}}

-- 
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/053.b98a1e9883390e717f8f1f3594611dd6%40djangoproject.com.


Re: [Django] #29049: Add slicing notation to F expressions

2020-06-30 Thread Django
#29049: Add slicing notation to F expressions
-+-
 Reporter:  Matthew Pava |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  slice F  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * owner:  (none) => Sergey Fedoseev
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.dd98a34114da6d04d97897eeaadcd634%40djangoproject.com.


Re: [Django] #25287: Multiplying and dividing connectors for datetime expressions are not supported by sqlite backed.

2020-06-30 Thread Django
#25287: Multiplying and dividing connectors for datetime expressions are not
supported by sqlite backed.
-+-
 Reporter:  Ahmet DAL|Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, | Triage Stage:  Accepted
  combine_duration_expression, F |
  expressions,   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * owner:  nobody => Sergey Fedoseev
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.778754698079cf83c3ea3048e4f80005%40djangoproject.com.


Re: [Django] #31753: SpatialReference srid -> proj4 -> srid returns wrong SRID

2020-06-30 Thread Django
#31753: SpatialReference srid -> proj4 -> srid returns wrong SRID
-+-
 Reporter:  Riccardo |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  SRID;| Triage Stage:
  SpatialReference; GDAL |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

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


Comment:

 I'm afraid Django cannot do anything here, it is probably a GDAL "issue"
 (Django is simply getting the `SetFromUserInput` GDAL API result).
 In any case, I would discourage using a Proj string to create a
 SpatialReference.

-- 
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.2dd35a82cbe762140e55e2f4df80407b%40djangoproject.com.


Re: [Django] #31750: Abstract model field should not be equal across models

2020-06-30 Thread Django
#31750: Abstract model field should not be equal across models
-+-
 Reporter:  Ryan Hiebert |Owner:  Ryan
 |  Hiebert
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (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 Ryan Hiebert):

 * cc: Ryan Hiebert (added)
 * owner:  nobody => Ryan Hiebert
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 [https://github.com/django/django/pull/13124 PR]

 Should this get backported? It feels like an (admittedly esoteric) bug fix
 to me. It affects ordering, though I've minimized that effect to only
 places where the ordering is currently undefined, as they are currently
 considered equal.

-- 
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/069.6cb961b9a35326c94962ae3dad051882%40djangoproject.com.


Re: [Django] #31755: make temporal subtraction work without ExpressionWrapper

2020-06-30 Thread Django
#31755: make temporal subtraction work without ExpressionWrapper
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Uncategorized|   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Sergey Fedoseev):

 * owner:  nobody => Sergey Fedoseev
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.8fbf96994de090d99d1e0a4de8fcfe2e%40djangoproject.com.


Re: [Django] #30415: Refactor runtests.py to allow using other test runners.

2020-06-30 Thread Django
#30415: Refactor runtests.py to allow using other test runners.
---+
 Reporter:  Daniel Hahler  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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 David Smith):

 All,

 It will need someone much more experienced than myself to properly
 articulate this, and to be credible on the topic. Carlton - I may be
 reading too much into this but your comments sounded interested / positive
 on this?

 I think the benefits are subjective given current test runner works so any
 benefits above that are about user experience. So may be hard to make a
 good technical reason for the change. A few of my thoughts are:

 Pros
 #22449 - Pytest outputs have colour so would not need to fix this ticket
 - Better output - get % progress, more information on failed tests.
 - Integration with IDEs (e.g. can use pytest add-in for VSCode?)
 - ability to use other pytest and pytest-addins functionality. e.g.
 `pytest --durations=50` outputs the 50 slowest tests.
 - Would pytest-xdist help speed up the tests?. (currently GSOC project on
 this topic)
 - ''IF'' project went full pytest then could use plain asserts.

 Cons
 - Some complications with implementation  (e.g. subtests and some tests
 may need to be re-written)
 - If we went full pytest then it would be a dependency (Django tends to
 avoid doing this)
 - Current test runner may be better understood than getting pytest to work
 (not sure how much expertise we have on the current test runner?)

 Ideally I'd see this as a two step changes. 1) get it working with pytest
 and the current test runner, 2) consider moving to pytest fully, this may
 be after 1 has been working for a period of time.

 Appreciate thoughts on next steps (is this a topic for the mailing list?)

-- 
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.480e0c30504a2254b926344b3ea98d76%40djangoproject.com.


Re: [Django] #31735: Migration crash when adding inline foreign key to different schema on PostgreSQL.

2020-06-30 Thread Django
#31735: Migration crash when adding inline foreign key to different schema on
PostgreSQL.
-+-
 Reporter:  Rodrigo Estevao  |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  many-to- | Triage Stage:  Ready for
  many;relationship;intermediate;table;through|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Rodrigo Estevao):

 Replying to [comment:8 Mariusz Felisiak ]:
 > In [changeset:"453a5bf3024ed385f95f2f9a5378d8fc03baffc2" 453a5bf3]:
 > {{{
 > #!CommitTicketReference repository=""
 revision="453a5bf3024ed385f95f2f9a5378d8fc03baffc2"
 > [3.0.x] Fixed #31735 -- Fixed migrations crash on namespaced inline FK
 addition on PostgreSQL.
 >
 > The namespace of the constraint must be included when making the
 > constraint immediate.
 >
 > Regression in 22ce5d0031bd795ade081394043833e82046016c.
 >
 > Thanks Rodrigo Estevao for the report.
 >
 > Backport of 2e8941b6f90e65ffad3f07083b8de59e8ed29767 from master
 > }}}

 Thank you guys for your help with that!

 Cheers,
 Rodrigo

-- 
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/072.2086b00054e6d3d7c2eadb0b74adbb35%40djangoproject.com.


Re: [Django] #31754: preserve_filters doesn't work

2020-06-30 Thread Django
#31754: preserve_filters doesn't work
---+--
 Reporter:  Zbynek Drlik   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.0
 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 felixxm):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Uncategorized => contrib.admin


Comment:

 I cannot reproduce your issue. Preserving filters works for me. Please
 provide a sample project to reproduce this 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/069.b7396fe981b03efd0e0c9ae74a13e435%40djangoproject.com.


Re: [Django] #24816: Clarify docs about preventing duplicate signals

2020-06-30 Thread Django
#24816: Clarify docs about preventing duplicate signals
-+-
 Reporter:  Timothy Makobu   |Owner:  Jason
 Type:   |  Held
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  signals  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jason Held):

 * owner:  nobody => Jason Held
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.bd8e7d5f6220fd411e61a7a92381f6c9%40djangoproject.com.


Re: [Django] #24816: Clarify docs about preventing duplicate signals

2020-06-30 Thread Django
#24816: Clarify docs about preventing duplicate signals
-+-
 Reporter:  Timothy Makobu   |Owner:  Jason
 Type:   |  Held
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  signals  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13131 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.f20b44e67bc3209b09fbf94528948493%40djangoproject.com.