[Django] #30282: CSRF token invalid after DELETE request

[Django]

#30282: CSRF token invalid after DELETE request
-+-
   Reporter:  my-tien|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  CSRF   |Version:  2.1
   Severity:  Normal |   Keywords:  CSRF RESTful-API
   Triage Stage: |  DELETE
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am using a RESTful API in my django server with CSRF Middleware enabled.
 When I only use GET and POST requests, all works as expected. But when I
 send a DELETE request to a resource and afterwards perform a POST request
 – that contains a csrf cookie and csrfmiddlewaretoken in body – the latter
 is rejected with `CSRF token missing or incorrect` and I have to login
 again.

 DELETE request Headers:
 - REQUEST_METHOD: DELETE
 - CONTENT_TYPE: "application/x-www-form-urlencoded"
 - HTTP_COOKIE: sessionid=[session id], csrftoken=[csrfcookie]
 - HTTP_X_CSRFTOKEN: [csrfcookie] (I also don’t understand why DELETE needs
 this extra header with the same content as the csrftoken…)
 - HTTP_REFERER: [url]

 DELETE request Body: csrfmiddlewaretoken: [csrfcookie]

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

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

Re: [Django] #30259: Support the use of admin_order_field on properties in the admin. (was: admin_order_field not working with properties)

[Django]

#30259: Support the use of admin_order_field on properties in the admin.
-+-
 Reporter:  Tobias Wiese |Owner:  Jani
 |  Tiainen
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  2.1 => 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.ba9519dd13fa3503384d8aee7b43%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29539: Cannot use Aggregation function in Model.Meta.ordering

[Django]

#29539: Cannot use Aggregation function in Model.Meta.ordering
-+-
 Reporter:  wilhelmhb|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering, query  | Triage Stage:  Accepted
  expression, aggregation function   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * cc: Can Sarıgöl (added)
 * has_patch:  0 => 1


Comment:

 I tried to fix this. Could you review?
 [https://github.com/django/django/pull/1 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.3593e9aa3664f69107561a2385373a00%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30257: UsernameValidator allows trailing newline in usernames

[Django]

#30257: UsernameValidator allows trailing newline in usernames
---+---
 Reporter:  Robert Grosse  |Owner:  Ryan Schave
 Type:  Bug|   Status:  closed
Component:  contrib.auth   |  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:  1  |UI/UX:  0
---+---
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"cbf7e71558c94ce1c327b683768a18a25d82d197" cbf7e715]:
 {{{
 #!CommitTicketReference repository=""
 revision="cbf7e71558c94ce1c327b683768a18a25d82d197"
 Fixed #30257 -- Made UsernameValidators prohibit trailing newlines.
 }}}

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

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

Re: [Django] #30280: Model_get_FIELD_display() returns proxies in 2.2rc1 but always returned strings previously

[Django]

#30280: Model_get_FIELD_display() returns proxies in 2.2rc1 but always returned
strings previously
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"a86ffb3e0fd8a37ff1b9affc177e81ef9298ec36" a86ffb3e]:
 {{{
 #!CommitTicketReference repository=""
 revision="a86ffb3e0fd8a37ff1b9affc177e81ef9298ec36"
 [2.2.x] Fixed #30280 -- Restored Model.get_FIELD_display()'s coercion of
 lazy strings.

 Reverted cc79c7ee637e65c8da27e56d746c87903d5ec901.

 Backport of ea071870f943c23a8eaf36dfcdf382afd6478fd1 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.87e7a4e465f5937e7bec5df2a335ea7a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30280: Model_get_FIELD_display() returns proxies in 2.2rc1 but always returned strings previously

[Django]

#30280: Model_get_FIELD_display() returns proxies in 2.2rc1 but always returned
strings previously
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"ea071870f943c23a8eaf36dfcdf382afd6478fd1" ea071870]:
 {{{
 #!CommitTicketReference repository=""
 revision="ea071870f943c23a8eaf36dfcdf382afd6478fd1"
 Fixed #30280 -- Restored Model.get_FIELD_display()'s coercion of lazy
 strings.

 Reverted cc79c7ee637e65c8da27e56d746c87903d5ec901.
 }}}

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

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

Re: [Django] #30129: Allow creating models with fields values as a Subquery() with F() expressions

[Django]

#30129: Allow creating models with fields values as a Subquery() with F()
expressions
-+-
 Reporter:  Charlie McBride  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Subquery, F, Query   | Triage Stage:  Accepted
  Expressions|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by birthdaysgift):

 * owner:  birthdaysgift => (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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.50a1db6456b9d4c00ef107bcf4a00881%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #10060: Multiple table annotation failure

[Django]

#10060: Multiple table annotation failure
-+-
 Reporter:  svsharma@…   |Owner:  (none)
 Type:  Bug  |   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
-+-

Comment (by wilhelmhb):

 Replying to [comment:57 powderflask]:
 A huge thanks to powderflask: for the ones knowledgeable enough with SQL,
 this is the way to go =)

 I also tried the solution described here:
 [https://stackoverflow.com/questions/48598245/multiple-annotate-with-sum-
 and-display-data-in-admin-django/48607830#48607830], alas without
 success...

 > Replying to [comment:9 bendavis78]:
 > In [comment:16 comment16] bendavis78 recommends this query to solve the
 issue:
 > >  {{{
 > > #!sql
 > > SELECT
 > >   u.email,
 > >   (SELECT SUM(points) FROM point_earning WHERE user_id=u.id) AS
 points_earned,
 > >   (SELECT SUM(points) FROM point_expense WHERE user_id=u.id) AS
 points_spent
 > > FROM
 > >   "user" u
 > > }}}
 >
 > For others who might arrive here looking for a reasonable way to work
 around this issue, the following worked well for me.  I added a custom
 Queryset method to the Manager class, and used a
 [https://docs.djangoproject.com/en/1.9/ref/models/expressions/#raw-sql-
 expressions RawSQL()] expression to create the annotations.   This at
 least encapsulates the SQL code and allows the annotation to be integrated
 with a normal django queryset.  Here's a sample for the example given
 above:
 >
 > {{{
 > #!python
 > def annotate_sum_for_user(user_related_modelClass, field_name,
 annotation_name):
 > raw_query = """
 >   SELECT SUM({field}) FROM {model} AS model
 >   WHERE model.user_id = user.id
 > """.format(
 > field = field_name,
 > model = user_related_modelClass._meta.db_table,
 > )
 >
 > annotation = {annotation_name: RawSQL(raw_query, [])}
 > return self.annotate(**annotation)
 > }}}
 >
 > Usage for above query on presumed User model:
 > {{{
 > #!python
 > users = models.User.objects\
 > .annotate_sum_for_user(PointEarning, 'points', 'points_earned')\
 > .annotate_sum_for_user(PointExpense, 'points', 'points_spent')
 > }}}
 >
 > Hope someone finds this useful, and a word of HUGE thanks to those who
 worked to get a statement of this issue and a link to this thread into the
 django documentation -- probably saved me hours.

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

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

Re: [Django] #30259: admin_order_field not working with properties

[Django]

#30259: admin_order_field not working with properties
-+-
 Reporter:  Tobias Wiese |Owner:  Jani
 |  Tiainen
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 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 Tobias Wiese):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #30281: Model.refresh_from_db() does not refresh related objects

[Django]

#30281: Model.refresh_from_db() does not refresh related objects
-+-
 Reporter:  Aleksander Zamojski  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  refresh_from_db  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Django 2.0 is end-of-life April 2019 and only receives security and data
 loss fixes until then (but most likely there won't be another release).

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

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

[Django] #30281: Model.refresh_from_db() does not refresh related objects

[Django]

#30281: Model.refresh_from_db() does not refresh related objects
-+-
   Reporter:  Alek96 |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  refresh_from_db
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 After testing my application with Django 2.0.13 I noticed few of my test
 started failing (they were working on Django 2.1). After further
 investigation, I figured out the problem was coming from
 **refresh_from_db** method.

 Here is a test that show the problem:

 {{{
 def test_error_on_refresh_from_db(self):
 def add_one(id):
 task_model = FakeTask.objects.get(id=id)
 task_model.task_group.finished_tasks_number =
 F('finished_tasks_number') + 1
 task_model.task_group.save()
 task_model.task_group.refresh_from_db()
 task_model.save()
 self.assertEqual(task_model.task_group.finished_tasks_number, 1)

 task_group_model = FakeTaskGroup.objects.create()
 task_model = FakeTask.objects.create(task_group=task_group_model)
 add_one(task_model.id)
 task_model.refresh_from_db()
 self.assertEqual(task_model.task_group.finished_tasks_number, 1)
 }}}

 Here you can find the definition (light version) of the this models:

 {{{
 class FakeTaskGroup(models.Model):
finished_tasks_number = models.PositiveIntegerField(default=0)

 class FakeTask(models.Model):
 task_group = models.ForeignKey(FakeTaskGroup,
 on_delete=models.CASCADE)
 }}}

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

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

Re: [Django] #30280: Model_get_FIELD_display() returns proxies in 2.2rc1 but always returned strings previously

[Django]

#30280: Model_get_FIELD_display() returns proxies in 2.2rc1 but always returned
strings previously
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (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 Matthias Kestenholz):

 You're right, thanks. I could have explained it better.

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

 The code which failed was:

 {{{
 class Project(Model):
 ACQUISITION = "acquisition"

 TYPE_CHOICES = [
 (ACQUISITION, _("Acquisition")),
 ...
 ]

 type = models.CharField(_("type"), choices=TYPE_CHOICES,
 max_length=20)
 closed_on = models.DateField(_("closed on"), blank=True, null=True)

 def pretty_status(self):
 parts = [self.get_type_display()]
 if self.closed_on:
 parts.append(
 gettext("closed on %s") %
 local_date_format(self.closed_on, "d.m.Y")
 )
 return ", ".join(parts)
 }}}

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

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

Re: [Django] #30271: Add support for the Sign database function.

[Django]

#30271: Add support for the Sign database function.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sign, database,  | Triage Stage:  Ready for
  function   |  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:"d26b2424437dabeeca94d7900b37d2df4410da0c" d26b242]:
 {{{
 #!CommitTicketReference repository=""
 revision="d26b2424437dabeeca94d7900b37d2df4410da0c"
 Fixed #30271 -- Added the Sign database function.
 }}}

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

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

Re: [Django] #30280: Model_get_FIELD_display() returns proxies in 2.2rc1 but always returned strings previously (was: _get_FIELD_display returns proxies in 2.2rc1 but always returned strings previousl

[Django]

#30280: Model_get_FIELD_display() returns proxies in 2.2rc1 but always returned
strings previously
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (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 Tim Graham):

 * stage:  Unreviewed => Accepted


Old description:

> I'm not sure whether that was wanted but
> https://github.com/django/django/commit/cc79c7ee637e65c8da27e56d746c87903d5ec901
> (see https://code.djangoproject.com/ticket/27795 ) introduced a change
> where code which calls `get_*_display` got a string previously and now
> gets a proxy under some circumstances.
>
> If this isn't wanted (and I cannot find anything in the release notes
> saying that it is) then that's a regression which should be fixed before
> releasing Django 2.2.

New description:

 I'm not sure whether that was wanted but
 cc79c7ee637e65c8da27e56d746c87903d5ec901 (#27795) introduced a change
 where code which calls `get_*_display` got a string previously and now
 gets a proxy under some circumstances.

 If this isn't wanted (and I cannot find anything in the release notes
 saying that it is) then that's a regression which should be fixed before
 releasing Django 2.2.

--

Comment:

 Probably `str()` could be used where `force_text()` was used previously.
 By the way, you should explain how to reproduce the issue, i.e. what
 "under some circumstances" means.

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

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

Re: [Django] #30280: _get_FIELD_display returns proxies in 2.2rc1 but always returned strings previously

[Django]

#30280: _get_FIELD_display returns proxies in 2.2rc1 but always returned strings
previously
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Matthias Kestenholz):

 ... thinking about this some more, maybe it makes sense to return lazy
 strings when using lazy strings inside `choices`.

 If that's the case this would certainly warrant a mention in the release
 notes (or maybe I haven't found it?)

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

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

[Django] #30280: _get_FIELD_display returns proxies in 2.2rc1 but always returned strings previously

[Django]

#30280: _get_FIELD_display returns proxies in 2.2rc1 but always returned strings
previously
-+-
   Reporter:  Matthias   |  Owner:  nobody
  Kestenholz |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm not sure whether that was wanted but
 
https://github.com/django/django/commit/cc79c7ee637e65c8da27e56d746c87903d5ec901
 (see https://code.djangoproject.com/ticket/27795 ) introduced a change
 where code which calls `get_*_display` got a string previously and now
 gets a proxy under some circumstances.

 If this isn't wanted (and I cannot find anything in the release notes
 saying that it is) then that's a regression which should be fixed before
 releasing Django 2.2.

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

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

Re: [Django] #30272: get_language_from_path not respecting i18n_patterns prefix_default_language=False

[Django]

#30272: get_language_from_path not respecting i18n_patterns
prefix_default_language=False
-+-
 Reporter:  Stefan Wehrmeyer |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Stefan.

 I think this is intended behaviour: doing clever things, like falling back
 to the default `LANGUAGE_CODE` is out of scope for this function. It's job
 it just (literally) to get the language code from the path. If it's not
 there then `None` is the desired response.

 The more sophisticated `get_language_from_request()` will do the ''right
 thing'' here and, ultimately, return `settings.LANGUAGE_CODE` if nothing
 else preempts it.

 (Was there an incorrect behaviour you observed here, beyond this?)

 Thanks.

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

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

Re: [Django] #30278: Using del on uncalled cached_property throws exception.

[Django]

#30278: Using del on uncalled cached_property throws exception.
---+--
 Reporter:  Matthew Schinckel  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 Keywords:  cached_property| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Great discussion. Thank you both!

 Just before this disappears over the horizon, is it worth adjusting the
 `del` example in the docs here do we think?

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

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

Re: [Django] #28344: Add for_update parameter to Model.refresh_from_db()

[Django]

#28344: Add for_update parameter to Model.refresh_from_db()
-+-
 Reporter:  Patryk Zawadzki  |Owner:  (none)
 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 Semyon Pupkov):

 * cc: Semyon Pupkov (added)


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

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

Re: [Django] #30271: Add support for the Sign database function.

[Django]

#30271: Add support for the Sign database function.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sign, database,  | Triage Stage:  Ready for
  function   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #30279: PASSWORD_RESET_TIMEOUT_DAYS why i cant set it in no of hours.

[Django]

#30279: PASSWORD_RESET_TIMEOUT_DAYS why i cant set it in no of hours.
---+--
 Reporter:  Gouri Javed|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.auth   |  Version:  master
 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
 * version:  1.11 => master
 * resolution:   => duplicate
 * severity:  Release blocker => Normal


Comment:

 Duplicate of https://code.djangoproject.com/ticket/28622.

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

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

[Django] #30279: PASSWORD_RESET_TIMEOUT_DAYS why i cant set it in no of hours.

[Django]

#30279: PASSWORD_RESET_TIMEOUT_DAYS why i cant set it in no of hours.
---+
   Reporter:  Javedgouri   |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  contrib.auth |Version:  1.11
   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|
---+
 I have a requirement that I have to expiry the token after 3 hours, but
 not found anything how I can do this because PASSWORD_RESET_TIMEOUT_DAYS
 allow me to set in days. Suggest me some workaround.

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

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