Re: [Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

2020-05-11 Thread Django
#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 felixxm):

 Simon, I can reproduce this at 46fe506445666d8097945f0c1e8be11cfd644b28,
 also with two `annotate()` calls.

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


Re: [Django] #31568: Alias used in aggregate filtering is incorrect

2020-05-11 Thread Django
#31568: Alias used in aggregate filtering is incorrect
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (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 Simon Charette):

 * cc: Simon Charette (added)
 * owner:  nobody => Simon Charette
 * status:  new => assigned


Comment:

 Thank you for your report. Did you manage to reproduce against Django
 3.0.5 as well? If it's the case could you try reducing your model set and
 queryset interactions to a minimal that still trigger the issue. That'll
 help tremendously in reproducing the regression and ensure it gets
 addressed in a timely manner. 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.7491d86210fac84f04db9ee7aa6e18f0%40djangoproject.com.


Re: [Django] #23521: removal of concrete Model from bases doesn't remove it from ModelState bases

2020-05-11 Thread Django
#23521: removal of concrete Model from bases doesn't remove it from ModelState
bases
-+
 Reporter:  Sergey Fedoseev  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Ian Foote):

 * owner:  Ian Foote => (none)
 * status:  assigned => new


Comment:

 Deassigning because I don't think I'm likely to get to this again in the
 near future and I'd be happy for someone else to take my work and finish
 the job.

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


Re: [Django] #31569: Add support for GEOS 3.8.

2020-05-11 Thread Django
#31569: Add support for GEOS 3.8.
--+
 Reporter:  felixxm   |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  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 felixxm):

 It's probably related with https://trac.osgeo.org/geos/ticket/1001.

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


[Django] #31570: Translations of one language in different territories can override each other

2020-05-11 Thread Django
#31570: Translations of one language in different territories can override each
other
+
   Reporter:  Shai Berger   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Internationalization  |Version:  2.2
   Severity:  Release blocker   |   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The fix of #30439 created a new problem: Under some circumstances,
 translations for one language in different territories can override each
 other. In the case we've run into, users in New Zealand ({{{en-NZ}}})
 received translations for South Africa ({{{en-ZA}}}). We've seen this
 behavior on 2.2.12, and downgrading to 2.2.11 resolved it, hence marking
 this as a bug in 2.2, but I believe the same issue exists in 3.0 and
 master.

 The circumstances where this happens are not trivial to reproduce; it
 involves having applications with translations for the "bare" language
 ({{{en}}} in our case), and may depend on the order of loading of
 different translations. I will try to come up with a test later.

 The issue arises, AFAICT, when the {{{TranslationCatalog}}} installs a
 reference to the bare-language dictionary ("catalog" in gettext terms) as
 the first in the list of catalogs for a territorial variation (when an app
 has only the bare-language translation), and is then willing to update it
 with the contents of another territorial variant.

 The following diff seems to resolve the issue, but I am far from certain
 that it is the right solution.

 {{{#!diff
 diff --git a/django/utils/translation/trans_real.py
 b/django/utils/translation/trans_real.py
 index eed4705f6e..8042f6fdc4 100644
 --- a/django/utils/translation/trans_real.py
 +++ b/django/utils/translation/trans_real.py
 @@ -96,7 +96,7 @@ class TranslationCatalog:
  cat.update(trans._catalog)
  break
  else:
 -self._catalogs.insert(0, trans._catalog)
 +self._catalogs.insert(0, trans._catalog.copy())
  self._plurals.insert(0, trans.plural)

  def get(self, key, default=None):
 }}}

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

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


Re: [Django] #31569: Add support for GEOS 3.8.

2020-05-11 Thread Django
#31569: Add support for GEOS 3.8.
--+
 Reporter:  felixxm   |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by felixxm):

 * cc: Nick Pope, Sergey Fedoseev (added)
 * owner:  felixxm => (none)
 * version:  3.0 => master
 * status:  assigned => new


Old description:



New description:

 Two tests fail with GEOS 3.8.1:
 {{{
 ==
 FAIL: test_diff_intersection_union
 (gis_tests.geoapp.test_functions.GISFunctionsTests)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.6/unittest/case.py", line 59, in testPartExecutor
 yield
   File "/usr/lib/python3.6/unittest/case.py", line 605, in run
 testMethod()
   File "/repo/django/django/test/testcases.py", line 1215, in skip_wrapper
 return test_func(*args, **kwargs)
   File "/repo/django/tests/gis_tests/geoapp/test_functions.py", line 569,
 in test_diff_intersection_union
 self.assertEqual(c.mpoly.intersection(geom), c.intersection)
   File "/usr/lib/python3.6/unittest/case.py", line 829, in assertEqual
 assertion_func(first, second, msg=msg)
   File "/usr/lib/python3.6/unittest/case.py", line 822, in
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError:  != 

 ==
 FAIL: test_intersection
 (gis_tests.geoapp.test_functions.GISFunctionsTests)
 --
 Traceback (most recent call last):
   File "/usr/lib/python3.6/unittest/case.py", line 59, in testPartExecutor
 yield
   File "/usr/lib/python3.6/unittest/case.py", line 605, in run
 testMethod()
   File "/repo/django/django/test/testcases.py", line 1215, in skip_wrapper
 return test_func(*args, **kwargs)
   File "/repo/django/tests/gis_tests/geoapp/test_functions.py", line 299,
 in test_intersection
 self.assertEqual(c.inter, expected)
   File "/usr/lib/python3.6/unittest/case.py", line 829, in assertEqual
 assertion_func(first, second, msg=msg)
   File "/usr/lib/python3.6/unittest/case.py", line 822, in
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError:  != 
 }}}

--

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


[Django] #31569: Add support for GEOS 3.8.

2020-05-11 Thread Django
#31569: Add support for GEOS 3.8.
+--
   Reporter:  felixxm   |  Owner:  felixxm
   Type:  Cleanup/optimization  | Status:  assigned
  Component:  GIS   |Version:  3.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--


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

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


Re: [Django] #31543: Default output buffering on in tests

2020-05-11 Thread Django
#31543: Default output buffering on in tests
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 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
-+-
Changes (by Ahmad Abdallah):

 * stage:  Unreviewed => Accepted


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

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


Re: [Django] #31034: Add a navigation sidebar to the admin

2020-05-11 Thread Django
#31034: Add a navigation sidebar to the admin
-+-
 Reporter:  Tom Carrick  |Owner:  Tom
 |  Carrick
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 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:  1
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"d24ba1be7a53a113d19e2860c03aff9922efec24" d24ba1be]:
 {{{
 #!CommitTicketReference repository=""
 revision="d24ba1be7a53a113d19e2860c03aff9922efec24"
 Fixed #31034 -- Added a navigation sidebar to the admin.

 Co-authored-by: elky 
 Co-authored-by: Goetz 
 }}}

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


Re: [Django] #31543: Default output buffering on in tests

2020-05-11 Thread Django
#31543: Default output buffering on in tests
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  new
Component:  Testing framework|  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
-+-

Comment (by Ahmad Abdallah):

 +1 on making this change. As already pointed out, eliminating unnecessary
 output will increase the speed of running tests. The associated risk of
 not seeing debugging print statement can be easily dealt with by using the
 --no-buffer option.

 This will remove a lot of unnecessary clutter.

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


Re: [Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

2020-05-11 Thread Django
#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 Simon Charette):

 Out of curiosity, does the error happens against 3.0.6 as well and can you
 also reproduce by breaking your `.annotate` call in two: a first one for
 the `start_time=Min("datetime")` and a following one for the `Exists`?

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


Re: [Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

2020-05-11 Thread Django
#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 Simon Charette):

 * owner:  nobody => Simon Charette
 * 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.ea5fe311a4b1621d02ac97d25c31b200%40djangoproject.com.


Re: [Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

2020-05-11 Thread Django
#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
 Reporter:  Gagaro   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 Simon Charette):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 This is similar #31377, we'll want to ensure the alias is part of
 `annotation_select_mask`.

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


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2020-05-11 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
-+-
 Reporter:  Alexandre Poitevin   |Owner:  Alexandre
 |  Poitevin
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  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 Alexandre Poitevin):

 Not now, because in fact it is a separate debate.
 The reason it began, is the modification of my ticket (no grudge
 intended).

 I’m gonna work on a PR. I think the good place to put the corresponding
 unit test is `tests/modeladmin/tests_actions.py`.

-- 
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/074.896c20fced9134e60ae2488652d902d3%40djangoproject.com.


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2020-05-11 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
-+-
 Reporter:  Alexandre Poitevin   |Owner:  Alexandre
 |  Poitevin
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  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 felixxm):

 Tutorial doesn't use `fget`. Again, variables defined in properties must
 be known before creating a `property`, that's why setting variable for
 decorated property raises `AttributeError`. If you really believe that we
 should encourage users for override `fget` you can start a discussion on
 DevelopersMailingList.

-- 
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/074.dd887f61657998b0284d828be608daf2%40djangoproject.com.


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2020-05-11 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
-+-
 Reporter:  Alexandre Poitevin   |Owner:  Alexandre
 |  Poitevin
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  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 Alexandre Poitevin):

 Setting a variable function is already what you find in the tutorial…

 {{{
 class Question(models.Model):
 # ...
 def was_published_recently(self):
 now = timezone.now()
 return now - datetime.timedelta(days=1) <= self.pub_date <= now
 was_published_recently.admin_order_field = 'pub_date'
 was_published_recently.boolean = True
 was_published_recently.short_description = 'Published recently?'
 }}}

 See: https://docs.djangoproject.com/en/3.0/intro/tutorial07/#id8

 And in https://docs.djangoproject.com/en/3.0/ref/contrib/admin/ :


 > Elements of list_display can also be properties. Please note however,
 that due to the way properties work in Python, setting short_description
 or admin_order_field on a property is only possible when using the
 property() function and not with the @property decorator.
 >
 > For example:

 {{{
 class Person(models.Model):
 first_name = models.CharField(max_length=50)
 last_name = models.CharField(max_length=50)

 def my_property(self):
 return self.first_name + ' ' + self.last_name
 my_property.short_description = "Full name of the person"
 my_property.admin_order_field = 'last_name'

 full_name = property(my_property)

 class PersonAdmin(admin.ModelAdmin):
 list_display = ('full_name',)
 }}}

 End of citation.

 And this is what I was referring earlier. You can’t set the attribute on
 property, but you can set it to its `fget`. There’s no problem about using
 the decorator. We just have do update this part of the documentation.

-- 
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/074.1e50b73217c53e97530dd3dc3d6e8527%40djangoproject.com.


[Django] #31568: Alias used in aggregate filtering is incorrect

2020-05-11 Thread Django
#31568: Alias used in aggregate filtering is incorrect
-+-
   Reporter:  Gagaro |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  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  |
-+-
 With the following queryset:

 {{{
 IndicatorValue.objects
 .values("freight")
 .annotate(
 loading_time=Min("datetime",
 filter=Q(type=IndicatorValue.TYPE_FREIGHT_CREATED)) - Max("datetime",
 filter=Q(type=IndicatorValue.TYPE_FREIGHT_COMPLETED)),
 
has_top_loading=Exists(OrderItemResult.objects.order_by().filter(order_line__order__freight=OuterRef("freight"),
 loading_arm__loading_type=LoadingArm.LOADING_TYPE_TOP, ).values('pk')),
 
has_bottom_loading=Exists(OrderItemResult.objects.order_by().filter(order_line__order__freight=OuterRef("freight"),
 loading_arm__loading_type=LoadingArm.LOADING_TYPE_BOTTOM, ).values('pk'))
 )
 .aggregate(
 top_min=Min("loading_time", filter=Q(has_top_loading=True,
 has_bottom_loading=False))
 )
 }}}

 I get the following SQL generated for the aggregate (notice that both
 alias used are the same in the SQL, whereas they are not in the queryset):

 {{{
 MIN("loading_time") FILTER (WHERE ("has_top_loading" = false AND
 "has_top_loading" = true))
 }}}

 The full SQL generated is:

 {{{
 SELECT MIN("loading_time") FILTER (WHERE ("has_top_loading" = false AND
 "has_top_loading" = true)) FROM (SELECT
 "indicators_indicatorvalue"."freight_id" AS Col1,
 (MIN("indicators_indicatorvalue"."datetime") FILTER (WHERE
 "indicators_indicatorvalue"."type" = \'freight_created\') -
 MAX("indicators_indicatorvalue"."datetime") FILTER (WHERE
 "indicators_indicatorvalue"."type" = \'freight_completed\')) AS
 "loading_time", EXISTS(SELECT U0."id" FROM "orders_orderitemresult" U0
 INNER JOIN "loading_terminal_loadingarm" U1 ON (U0."loading_arm_id" =
 U1."id") INNER JOIN "orders_orderitem" U2 ON (U0."order_line_id" =
 U2."id") INNER JOIN "orders_order" U3 ON (U2."order_id" = U3."id") WHERE
 (U1."loading_type" = \'TOP\' AND U3."freight_id" =
 "indicators_indicatorvalue"."freight_id")) AS "has_top_loading",
 EXISTS(SELECT U0."id" FROM "orders_orderitemresult" U0 INNER JOIN
 "loading_terminal_loadingarm" U1 ON (U0."loading_arm_id" = U1."id") INNER
 JOIN "orders_orderitem" U2 ON (U0."order_line_id" = U2."id") INNER JOIN
 "orders_order" U3 ON (U2."order_id" = U3."id") WHERE (U1."loading_type" =
 \'BOTTOM\' AND U3."freight_id" =
 "indicators_indicatorvalue"."freight_id")) AS "has_bottom_loading" FROM
 "indicators_indicatorvalue" WHERE "indicators_indicatorvalue"."deleted" IS
 NULL GROUP BY "indicators_indicatorvalue"."freight_id", "has_top_loading",
 "has_bottom_loading") subquery
 }}}

 It works fine with Django 2.2 (which does not use alias there if I'm not
 mistaken).

-- 
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/049.85adb155076707f3207cee394f74a343%40djangoproject.com.


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2020-05-11 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
-+-
 Reporter:  Alexandre Poitevin   |Owner:  Alexandre
 |  Poitevin
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  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 felixxm):

 `fget` is a function for getting an attribute value, it's an
 implementation detail of `property()`. Setting variable on a function is
 hacky and cannot be recommended in our docs, IMO.

-- 
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/074.f6dea6642da46055e24453f52ba94d31%40djangoproject.com.


Re: [Django] #30375: Use "NO KEY" when doing select_for_update for PostgreSQL

2020-05-11 Thread Django
#30375: Use "NO KEY" when doing select_for_update for PostgreSQL
-+-
 Reporter:  Manuel Weitzman  |Owner:  Manuel
 Type:   |  Weitzman
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, lock,  | Triage Stage:  Accepted
  database, operation|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mads Jensen):

 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


Comment:

 This needs to be in the review queue :)

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


Re: [Django] #31567: Reversed coordinate order on Ubuntu 20.04. (was: Reversed coordinate order on Ubuntu 20.04)

2020-05-11 Thread Django
#31567: Reversed coordinate order on Ubuntu 20.04.
-+-
 Reporter:  stnatic  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  GIS  |  Version:  3.0
 Severity:  Normal   |   Resolution:  duplicate
 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
 * type:  Bug => Cleanup/optimization
 * resolution:   => duplicate


Comment:

 GDAL 3.0 is not supported in Django 3.0. Duplicate of #30678.

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


[Django] #31567: Reversed coordinate order on Ubuntu 20.04

2020-05-11 Thread Django
#31567: Reversed coordinate order on Ubuntu 20.04
--+
   Reporter:  stnatic |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  GIS |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   |
--+
 After saving a feature with OSMGeoAdmin, the resulting polygon has the
 following coordinates (a rough area drawn over Berlin, Germany):
 SRID=4326;POLYGON ((53.06762663713198 12.23876952954696, 53.35710874043545
 14.91943359167391, 51.78143559920171 14.94140624792098, 51.94426487379543
 11.79931640460816, 53.06762663713198 12.23876952954696))

 Coordinates follow the (latitude, longitude) convention which is reverse
 of what is expected by PostGIS.

 I've tried to run the same project on another Mac OS X environment and
 there coordinates are correctly saved as longitude/latitude.

 There's a chance that it is not a Django issue, but rather GDAL not being
 fully supported on the latest ubuntu.
 gdalinfo --version
 GDAL 3.0.4, released 2020/01/28
 django==3.0.6

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


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2020-05-11 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
-+-
 Reporter:  Alexandre Poitevin   |Owner:  Alexandre
 |  Poitevin
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  (none) => Alexandre Poitevin
 * 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/074.469e26d872cd81915edb2c77ebfa4971%40djangoproject.com.


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2020-05-11 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
+
 Reporter:  Alexandre Poitevin  |Owner:  (none)
 Type:  New feature |   Status:  new
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Hasan Ramezani):

 * cc: Hasan Ramezani (added)
 * owner:  Hasan Ramezani => (none)
 * status:  assigned => new


-- 
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/074.d0461de85f04606e17dd80b1f0a27b67%40djangoproject.com.


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2020-05-11 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
-+-
 Reporter:  Alexandre Poitevin   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  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 Alexandre Poitevin):

 Thanks for accept my ticket.
 I was hoping to contribute and make the pull request myself, but I’m a new
 to Django, so…

 Anyway I would like to say just 2 things:

 1. I don’t understand what is the difference between the decorator and
 calling explicitly `property`.
 I saw a similar statement in the documentation. But in fact, the effect is
 the same:

 {{{
 >>> class C:
 ... def m(self): ...
 ... m.attr = 42
 ... m = property(m)
 ...
 >>> C.m.attr
 Traceback (most recent call last):
  ...
 AttributeError: 'property' object has no attribute 'attr'
 >>> C.m.fget.attr
 42
 >>> class C:
 ... @property
 ... def m(self): ...
 ... m.fget.attr = 42
 ...
 >>> C.m.attr
 Traceback (most recent call last):
  ...
 AttributeError: 'property' object has no attribute 'attr'
 >>> C.m.fget.attr
 42
 }}}
 So the original method is stored as a `fget` attribute of the property,
 with or without the decorator, so I don’t see why this feature couldn’t be
 achieve with the decorator.

 2. After navigating in the source code and made a little work of
 debugging, I found two functions that may the ones requiring modification
 to enable this feature:

 `contrib.admin.templatetags.items_for_result`
 `contrib.admin.utils.lookup_fields`

 In the second:


 {{{
 # For non-field values, the value is either a method, property or
 # returned via a callable.
 if callable(name):
 attr = name
 value = attr(obj)
 }}}



 And in the first :


 {{{
 try:
 f, attr, value = lookup_field(field_name, result,
 cl.model_admin)
 except ObjectDoesNotExist:
 result_repr = empty_value_display
 else:
 empty_value_display = getattr(attr, 'empty_value_display',
 empty_value_display)
 if f is None or f.auto_created:
 if field_name == 'action_checkbox':
 row_classes = ['action-checkbox']
 boolean = getattr(attr, 'boolean', False)  # <= HERE !
 result_repr = display_for_value(value,
 empty_value_display, boolean)
 }}}

 By the way, this one (`items_for_result`) has no unit tests, or at least I
 didn’t see anyone (`grep -nr "items_for_result" 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.115aee04d51dda563537f2f571be8fcf%40djangoproject.com.


[Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

2020-05-11 Thread Django
#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
   Reporter:  Gagaro |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  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  |
-+-
 With the following queryset:

 {{{
 IndicatorValue.objects
 .values("freight")
 .annotate(
 
has_top_loading=Exists(OrderItemResult.objects.order_by().filter(order_line__order__freight=OuterRef("freight"),
 loading_arm__loading_type=LoadingArm.LOADING_TYPE_TOP,).values('pk')),
 start_time=Min("datetime")
 )
 .values('start_time')
 }}}

 I have the following error:

 {{{
 ProgrammingError: column "has_top_loading" does not exist
 LINE 1: ...ROUP BY "indicators_indicatorvalue"."freight_id", "has_top_l...
 }}}

 The generated SQL is:

 {{{
 SELECT MIN("indicators_indicatorvalue"."datetime") AS "start_time"
 FROM "indicators_indicatorvalue"
 GROUP BY "indicators_indicatorvalue"."freight_id", "has_top_loading"
 }}}

 `has_top_loading` is only mentioned in the `GROUP_BY` and not in the
 `SELECT`.

 On Django 2.2, the same queryset generates the following SQL:

 {{{
 SELECT MIN("indicators_indicatorvalue"."datetime") AS "start_time"
 FROM "indicators_indicatorvalue"
 GROUP BY "indicators_indicatorvalue"."freight_id", (EXISTS(SELECT U0."id"
 FROM "orders_orderitemresult" U0 INNER JOIN "loading_terminal_loadingarm"
 U1 ON (U0."loading_arm_id" = U1."id") INNER JOIN "orders_orderitem" U2 ON
 (U0."order_line_id" = U2."id") INNER JOIN "orders_order" U3 ON
 (U2."order_id" = U3."id") WHERE (U1."loading_type" = TOP AND
 U3."freight_id" = ("indicators_indicatorvalue"."freight_id"
 }}}

-- 
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/049.cea36085df6a71d048082f095b509560%40djangoproject.com.


Re: [Django] #31565: Support GENERATED ALWAYS columns for MySQL and PostgreSQL

2020-05-11 Thread Django
#31565: Support GENERATED ALWAYS columns for MySQL and PostgreSQL
-+-
 Reporter:  Louise Grandjonc |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Duplicate of #31300.

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

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


Re: [Django] #31565: Support GENERATED ALWAYS columns for MySQL and PostgreSQL

2020-05-11 Thread Django
#31565: Support GENERATED ALWAYS columns for MySQL and PostgreSQL
-+-
 Reporter:  Louise Grandjonc |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * stage:  Unreviewed => Accepted


Comment:

 This would be nice. I'd imagine tweaking your proposed API to look a bit
 more like the following:

 {{{#!python
 class Persistence(enum.Enum):
 STORED = 'STORED'
 VIRTUAL = 'VIRTUAL'

 class People(models.Model):
 height_cm = models.FloatField()
 height_in = models.FloatField(generated=F('height_cm') / 2.54,
 persistence=Persistence.STORED)
 }}}

 - `always_generated` seems a bit long and it is ''always'' `GENERATED
 ALWAYS AS`.
 - It would be nice to build expressions using the ORM with `F()`, etc.
 - Specifying the "persistence" (is that the best name) keyword with an
 enum would allow reuse of that elsewhere.

 There are a number of complex issues that need to be addressed:
 - The new value needs to be returned on `INSERT` or `UPDATE`. (Support for
 `INSERT` via `RETURNING` was added in Django 3.0)
 - Any column with `generated` needs to be excluded from `INSERT` or
 `UPDATE` queries.
 - We'd need to use a feature flag to specify which "persistence" keywords
 are supported, i.e. PostgreSQL only supports `STORED`.

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

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


Re: [Django] #31560: Circular imports raise AppRegistryNotReady.

2020-05-11 Thread Django
#31560: Circular imports raise AppRegistryNotReady.
--+--
 Reporter:  ExTexan   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  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
--+--

Comment (by ExTexan):

 In one of my cases, it was a model imported in a signals.py and the
 signals.py imported by the same model it imported.  Then anything that
 tried to import the model would encounter the circular imports.  As a
 quick test, I just went back to the signals.py file and put the model
 import back in.  I got ImportError, as you did.  There were a slew of
 changes I made when I fixed the "Apps aren't loaded yet" issue, so now I
 can't be sure what actually caused it in the first place.

 I'll need to revert that entire commit and take it one step at a time to
 see if I can zero in on the cause.  I'll see if I can make time to do
 this, but workload is heavy atm, so I can't really say when I'll get to
 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6c7761eaefcb1dfd79f3949bce523f55%40djangoproject.com.


Re: [Django] #31536: Disabled clearable file field widget is not disabling the checkbox

2020-05-11 Thread Django
#31536: Disabled clearable file field widget is not disabling the checkbox
-+-
 Reporter:  Carles Pina Estany   |Owner:  Carles
 Type:   |  Pina Estany
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, filefield, | Triage Stage:  Accepted
  clearable_file_input   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-

Comment (by Carles Pina Estany):

 Adding PR link to find it easier:
 https://github.com/django/django/pull/12864

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


Re: [Django] #31554: Tutorial 01: mysite/urls.py location confusion

2020-05-11 Thread Django
#31554: Tutorial 01: mysite/urls.py location confusion
-+-
 Reporter:  Paweł Brodacki   |Owner:  Desmond
 Type:   |  Nyamador
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * resolution:   => invalid
 * stage:  Accepted => Unreviewed


Comment:

 Desmond, please don't reopen invalid tickets.

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

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


Re: [Django] #31554: Tutorial 01: mysite/urls.py location confusion

2020-05-11 Thread Django
#31554: Tutorial 01: mysite/urls.py location confusion
-+-
 Reporter:  Paweł Brodacki   |Owner:  Desmond
 Type:   |  Nyamador
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Desmond Nyamador):

 * stage:  Unreviewed => Accepted


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

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


Re: [Django] #31554: Tutorial 01: mysite/urls.py location confusion

2020-05-11 Thread Django
#31554: Tutorial 01: mysite/urls.py location confusion
-+-
 Reporter:  Paweł Brodacki   |Owner:  Desmond
 Type:   |  Nyamador
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Desmond Nyamador):

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


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

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


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2020-05-11 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
-+-
 Reporter:  Alexandre Poitevin   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * 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/074.4e23d606cebdbfb956d342c5629e86a3%40djangoproject.com.


[Django] #31565: Support GENERATED ALWAYS columns for MySQL and PostgreSQL

2020-05-11 Thread Django
#31565: Support GENERATED ALWAYS columns for MySQL and PostgreSQL
-+-
   Reporter:  Louise |  Owner:  nobody
  Grandjonc  |
   Type:  New| Status:  new
  feature|
  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  |
-+-
 Hi,

 in Postgres 12, generated columns have been added:
 https://www.postgresql.org/docs/12/ddl-generated-columns.html

 The value of a generated column is computed from other columns. A
 generated column can be either stored (in which case it takes up space,
 and is written/updated like any other column) or virtual.

 Here is the example in the postgres docs to create such columns:


 {{{
 CREATE TABLE people (
 ...,
 height_cm numeric,
 height_in numeric GENERATED ALWAYS AS (height_cm / 2.54) STORED
 );
 }}}

 I would love to contribute and add this feature. And I'd like to know a
 bit what other think in terms of design:
 Maybe the expression could be a string:

 {{{
 class People(models.Model):
 height_cm = models.FloatField()
 height_in = models.FloatField(always_generated='height_cm / 2.54',
 stored=True)
 }}}

 Best,
 Louise

-- 
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/058.4d337b2710f1a5dfc50a82b1c0e86b5b%40djangoproject.com.


Re: [Django] #30116: Drop support for Python 3.5

2020-05-11 Thread Django
#30116: Drop support for Python 3.5
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d6aff369ad33457ae2355b5b210faf1c4890ff35" d6aff369]:
 {{{
 #!CommitTicketReference repository=""
 revision="d6aff369ad33457ae2355b5b210faf1c4890ff35"
 Refs #30116 -- Simplified regex match group access with
 Match.__getitem__().

 The method has been available since Python 3.6. The shorter syntax is
 also marginally faster.
 }}}

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


Re: [Django] #25236: Remove ifequal from the template language.

2020-05-11 Thread Django
#25236: Remove ifequal from the template language.
-+-
 Reporter:  Daniel Greenfeld |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  closed
Component:  Template system  |  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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"72a170b4c3c4c2db8192bb1a6424bcc8eb533973" 72a170b]:
 {{{
 #!CommitTicketReference repository=""
 revision="72a170b4c3c4c2db8192bb1a6424bcc8eb533973"
 Fixed #25236 -- Deprecated {% ifequal %} and {% ifnotequal %} template
 tags.

 The {% if %} tag provides all features of these tags.

 Since Django 1.2 (May 17, 2010), the docs have hinted that
 {% ifequal %} and {% ifnotequal %} will be deprecated in a future
 Django version. Time to make it official.
 }}}

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


Re: [Django] #25236: Remove ifequal from the template language.

2020-05-11 Thread Django
#25236: Remove ifequal from the template language.
-+-
 Reporter:  Daniel Greenfeld |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  master
 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 felixxm):

 * stage:  Someday/Maybe => Accepted


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

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