Re: [Django] #32597: generic inline formsets: object has no attribute 'fk'

[Django]

#32597: generic inline formsets: object has no attribute 'fk'
-+-
 Reporter:  etanter  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  generic field,   | Triage Stage:
  inline formset |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Hi, you should provide a minimal example to reproduce the problem and
 confirm that the issue still exists on the master branch.

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

Re: [Django] #32597: generic inline formsets: object has no attribute 'fk'

[Django]

#32597: generic inline formsets: object has no attribute 'fk'
-+-
 Reporter:  etanter  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  generic field,   | Triage Stage:
  inline formset |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by etanter:

Old description:

> Hi,
>
> I think I'm facing a zombie-bug reminiscent of ticket #9498:
> https://code.djangoproject.com/ticket/9498
> From 12 years ago and marked as solved.
>

> The setting is simple: I have a model with a generic field (with non-
> standard names). The corresponding inline class declares the `ct_field`
> and `ct_fk_field` as required.
>
> If I don't try to customize the formset, then all works fine. However, as
> soon as I declare a formset attribute for the inline (even if I use
> `formset=BaseInlineFormSet`), it crashes with an error:
>
> `type object 'DocumentFormSet' has no attribute 'fk'`
>
> With the debugger I traced the problem down to the execution of this
> method in BaseInlineFormSet (during the initialization process of the
> formsets):
>
>   {{{#!python
> @classmethod
> def get_default_prefix(cls):
>return
> cls.fk.remote_field.get_accessor_name(model=cls.model).replace('+', '')
>   }}}
>
> Problem is: `cls` has no field `fk` (it has `ct_fk_field` and `ct_field`
> properly set, though).
>
> In fact, the instance of `BaseInlineFormSet` has a field `fk`, used in
> many instance methods, but the class itself does not :-(
>
> I've done the following "fix":
>
> 1. redefine the get_default_prefix method to use `ct_field` instead of
> `fk`
>
>   {{{#!python
> @classmethod
> def get_default_prefix(cls):
> return
> cls.ct_field.remote_field.get_accessor_name(model=cls.model).replace('+',
> '')
>   }}}
>

> 2. at the instance methods level, I then had the same errors (`no
> attribute 'fk'`), so I defined:
>
>   {{{#!python
> @property
> def fk(self):
> return self.ct_field
> }}}
> And it works (I tried defining an `empty_form` property to set an initial
> value of my inlines, and it behaves as expected.
>
> Is that a known bug of 2.2? is it fixed upstream? Or am I missing
> something and there's some documentation somewhere explaining what to do
> in that case? (my fix is clearly not intended for users to do, I
> believe).
>
> Thanks
>
> Éric

New description:

 Hi,

 I think I'm facing a zombie-bug reminiscent of ticket #9498:
 https://code.djangoproject.com/ticket/9498
 From 12 years ago and marked as solved.


 The setting is simple: I have a model with a generic field (with non-
 standard names). The corresponding inline class declares the `ct_field`
 and `ct_fk_field` as required.

 If I don't try to customize the formset, then all works fine. However, as
 soon as I declare a formset attribute for the inline (even if I use
 `formset=BaseInlineFormSet`), it crashes with an error:

 `type object 'DocumentFormSet' has no attribute 'fk'`

 With the debugger I traced the problem down to the execution of this
 method in BaseInlineFormSet (during the initialization process of the
 formsets):

   {{{#!python
 @classmethod
 def get_default_prefix(cls):
return
 cls.fk.remote_field.get_accessor_name(model=cls.model).replace('+', '')
   }}}

 Problem is: `cls` has no field `fk` (it has `ct_fk_field` and `ct_field`
 properly set, though).



 I've done the following "fix":

 1. redefine the get_default_prefix method to use `ct_field` instead of
 `fk`

   {{{#!python
 @classmethod
 def get_default_prefix(cls):
 return
 cls.ct_field.remote_field.get_accessor_name(model=cls.model).replace('+',
 '')
   }}}


 2. at the instance methods level, I then had the same errors (`no
 attribute 'fk'`), so I defined:

   {{{#!python
 @property
 def fk(self):
 return self.ct_field
 }}}
 And it works (I tried defining an `empty_form` property to set an initial
 value of my inlines, and it behaves as expected.

 Is that a known bug of 2.2? is it fixed upstream? Or am I missing
 something and there's some documentation somewhere explaining what to do
 in that case? (my fix is clearly not intended for users to do, I believe).

 Thanks

 Éric

--

-- 
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.

[Django] #32597: generic inline formsets: object has no attribute 'fk'

[Django]

#32597: generic inline formsets: object has no attribute 'fk'
-+-
   Reporter:  etanter|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  2.2
   Severity:  Normal |   Keywords:  generic field,
   Triage Stage: |  inline formset
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,

 I think I'm facing a zombie-bug reminiscent of ticket #9498:
 https://code.djangoproject.com/ticket/9498
 From 12 years ago and marked as solved.


 The setting is simple: I have a model with a generic field (with non-
 standard names). The corresponding inline class declares the `ct_field`
 and `ct_fk_field` as required.

 If I don't try to customize the formset, then all works fine. However, as
 soon as I declare a formset attribute for the inline (even if I use
 `formset=BaseInlineFormSet`), it crashes with an error:

 `type object 'DocumentFormSet' has no attribute 'fk'`

 With the debugger I traced the problem down to the execution of this
 method in BaseInlineFormSet (during the initialization process of the
 formsets):

   {{{#!python
 @classmethod
 def get_default_prefix(cls):
return
 cls.fk.remote_field.get_accessor_name(model=cls.model).replace('+', '')
   }}}

 Problem is: `cls` has no field `fk` (it has `ct_fk_field` and `ct_field`
 properly set, though).

 In fact, the instance of `BaseInlineFormSet` has a field `fk`, used in
 many instance methods, but the class itself does not :-(

 I've done the following "fix":

 1. redefine the get_default_prefix method to use `ct_field` instead of
 `fk`

   {{{#!python
 @classmethod
 def get_default_prefix(cls):
 return
 cls.ct_field.remote_field.get_accessor_name(model=cls.model).replace('+',
 '')
   }}}


 2. at the instance methods level, I then had the same errors (`no
 attribute 'fk'`), so I defined:

   {{{#!python
 @property
 def fk(self):
 return self.ct_field
 }}}
 And it works (I tried defining an `empty_form` property to set an initial
 value of my inlines, and it behaves as expected.

 Is that a known bug of 2.2? is it fixed upstream? Or am I missing
 something and there's some documentation somewhere explaining what to do
 in that case? (my fix is clearly not intended for users to do, I believe).

 Thanks

 Éric

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

Re: [Django] #32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.

[Django]

#32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  __repr__ | 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:  new => assigned
 * stage:  Unreviewed => Accepted


Comment:

 Improving `__repr__()` sounds good to me.

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

Re: [Django] #32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings

[Django]

#32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings
-+-
 Reporter:  Ryan Siemens |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 Ryan Siemens):

 Thanks, Mariusz. I went ahead and opened
 https://github.com/PyMySQL/mysqlclient/issues/489

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

Re: [Django] #32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.

[Django]

#32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  __repr__ | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

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


Old description:

> When a partial function is passed as the view, the `__repr__` shows the
> `func` argument as `functools.partial` which isn't very helpful,
> especially as it doesn't reveal the underlying function or arguments
> provided.
>
> Because a partial function also has arguments provided up front, we need
> to handle those specially so that they are accessible in `__repr__`.
>
> ISTM that we can simply unwrap `functools.partial` objects in
> `ResolverMatch.__init__()`.

New description:

 When a partial function is passed as the view, the `__repr__` shows the
 `func` argument as `functools.partial` which isn't very helpful,
 especially as it doesn't reveal the underlying function or arguments
 provided.

 Because a partial function also has arguments provided up front, we need
 to handle those specially so that they are accessible in `__repr__`.

 ~~ISTM that we can simply unwrap `functools.partial` objects in
 `ResolverMatch.__init__()`.~~

--

Comment:

 Reopening with a different approach based on my
 [https://github.com/django/django/pull/14155#discussion_r602380807
 comment].

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

Re: [Django] #32204: Quick Filter for the Admin Sidebar

[Django]

#32204: Quick Filter for the Admin Sidebar
-+
 Reporter:  Maxim Milovanov  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  dev
 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:  1
-+
Changes (by Maxim Milovanov):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #32591: Change DiscoverRunner always to run _FailedTest "tests" first

[Django]

#32591: Change DiscoverRunner always to run _FailedTest "tests" first
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,_FailedTest |
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:"dcb06c2c6889d04506b48f025622357e2926c709" dcb06c2c]:
 {{{
 #!CommitTicketReference repository=""
 revision="dcb06c2c6889d04506b48f025622357e2926c709"
 Fixed #32591 -- Made DiscoverRunner order _FailedTest objects first.

 Failures detected when loading tests are ordered before all of the
 above for quicker feedback. This includes things like test modules that
 couldn't be found or that couldn't be loaded due to syntax errors.
 }}}

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

Re: [Django] #32355: Drop support for Python 3.6 & 3.7.

[Django]

#32355: Drop support for Python 3.6 & 3.7.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  4.0
 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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"cecdec91cf08fa8ad70a22d2a03bec3e86692350" cecdec91]:
 {{{
 #!CommitTicketReference repository=""
 revision="cecdec91cf08fa8ad70a22d2a03bec3e86692350"
 Refs #32355 -- Corrected comments about Python's _NamespacePath.

 _NamespacePath supports indexing in Python 3.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.08258c35da19029b6b3454451597382c%40djangoproject.com.

Re: [Django] #29127: Running tagged tests hides any with syntax errors

[Django]

#29127: Running tagged tests hides any with syntax errors
-+-
 Reporter:  Kryštof Řeháček  |Owner:  Chris
 |  Jerdonek
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  tests, tagged-   | Triage Stage:  Accepted
  tests, SyntaxError |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * owner:  (none) => Chris Jerdonek
 * 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/067.1bcaae0978d896a306bc844f08f7b278%40djangoproject.com.

Re: [Django] #32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.

[Django]

#32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  __repr__ | Triage Stage:
 |  Unreviewed
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
 * type:  Bug => Cleanup/optimization
 * resolution:   => wontfix


Comment:

 Nick, thanks for this proposition. However I agree with
 [https://github.com/django/django/pull/14155/files#r598304014 Tim's
 comment], the improvement is not worth the breaking change.

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

Re: [Django] #13659: Make the request accessible in callables used in ModelAdmin.list_display

[Django]

#13659: Make the request accessible in callables used in ModelAdmin.list_display
-+
 Reporter:  Sebastian Noack  |Owner:  Paulo
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Dominik Bartenstein):

 Replying to [comment:14 Tim Graham]:
 > No, storing state on the `ModelAdmin` class isn't thread-safe.

 Thanks a lot for the quick answer, Tim!

 What approach do you recommend when the request object is to be considered
 in a callable used with list_display?
 There is middleware such as https://github.com/jedie/django-
 tools/blob/master/django_tools/middlewares/ThreadLocal.py

 Use case:
 In the callable used with list_display the user’s permissions for each
 object have to be checked. Thus we need access to request.user.

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

Re: [Django] #31487: Add support for precision argument to Round

[Django]

#31487: Add support for precision argument to Round
-+-
 Reporter:  Baptiste Mispelon|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database function,   | Triage Stage:  Accepted
  round, precision, decimal places   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  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/067.bf2b23e0c2cd7a5f1c008e1dfd51d70d%40djangoproject.com.

Re: [Django] #32591: Change DiscoverRunner always to run _FailedTest "tests" first

[Django]

#32591: Change DiscoverRunner always to run _FailedTest "tests" first
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,_FailedTest |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14191

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

Re: [Django] #32580: Document that HttpRequest.get_host() can raise DisallowedHost

[Django]

#32580: Document that HttpRequest.get_host() can raise DisallowedHost
-+-
 Reporter:  Chris Jerdonek   |Owner:  SREEHARI
 Type:   |  K.V
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  HttpRequest  | 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:"5ebb8e65dfddc70b0e91add0232fcb074006f571" 5ebb8e6]:
 {{{
 #!CommitTicketReference repository=""
 revision="5ebb8e65dfddc70b0e91add0232fcb074006f571"
 [3.2.x] Fixed #32580 -- Doc'd that HttpRequest.get_host() may raise
 DisallowedHost.

 Backport of 0860db225a4a7059c0884c87c0a7aa0035fd0d36 from main
 }}}

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

Re: [Django] #32580: Document that HttpRequest.get_host() can raise DisallowedHost

[Django]

#32580: Document that HttpRequest.get_host() can raise DisallowedHost
-+-
 Reporter:  Chris Jerdonek   |Owner:  SREEHARI
 Type:   |  K.V
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  HttpRequest  | 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:"0860db225a4a7059c0884c87c0a7aa0035fd0d36" 0860db22]:
 {{{
 #!CommitTicketReference repository=""
 revision="0860db225a4a7059c0884c87c0a7aa0035fd0d36"
 Fixed #32580 -- Doc'd that HttpRequest.get_host() may raise
 DisallowedHost.
 }}}

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

Re: [Django] #32596: Add a method to CsrfViewMiddleware to encapsulate its referer logic

[Django]

#32596: Add a method to CsrfViewMiddleware to encapsulate its referer logic
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  CsrfViewMiddleware,referer |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek
 * 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/067.5eb17a1a9288179bcacd530d3c5c%40djangoproject.com.