Re: [Django] #34032: Base authentication Backend should raise NotImplemented on needed methods

[Django]

#34032: Base authentication Backend should raise NotImplemented on needed 
methods
+--
 Reporter:  Dotrar  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  contrib.auth|  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  authentication  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--
Description changed by Dotrar:

Old description:

> Hi all,
>
> Recently I've been trying my hand at creating alternative sign on methods
> for a django system and I've found the whole process fairly clean.
>
> However I did reach bit of a time waste when my "code that should work,
> doesn't" -- in my login view, I would `authenticate()` and `login()`
> properly, but with a redirect response I would be an `AnonymousUser`
> immediately after.
>
> After two days of debugging and re-reading docs, I found that I missed
> out a fairly critical sentence: "Authentication backends implements two
> required methods". -- my authentication backend (of which I was replacing
> the default) - did not implement `get_user()` so we would use the default
> `BaseBackend.get_user()` which is to `return None`.
>
> To me, it wasn't quite obvious why the authentication system needs to
> implement get_user ( as i'd want to just get the user by pk like any
> other) so this was a little bit of time wasting that I feel could be made
> a bit more obvious. but I'm happy for other considerations.
>
> Some ideas I had for changing this that might've saved time in the
> future:
> * `BaseBackend` to implement a simple `get_user_model().objects.get(
> _meta.pk=pk)` - seeming this is the default for most cases (as far as I
> know?)
> * `BaseBackend` to raise `NotImplemented` to force implementors to define
> ''these two required methods'' as that is what is mentioned in the docs
> (https://docs.djangoproject.com/en/4.1/topics/auth/customizing/#:~:text=implements%20two%20required%20methods)
> * anyone requiring the failthrough approach so that one can auth and
> get_user on different backends can just `pass` it
> * something else
>

> Happy for some thoughts /feedback / pushback. I just know that this was a
> painpoint for me and it wasn't obvious where the `AnonymousUser` was
> coming from. Perhaps it's just a documentation change.

New description:

 Hi all,

 Recently I've been trying my hand at creating alternative sign on methods
 for a django system and I've found the whole process fairly clean.

 However I did reach bit of a time waste when my "code that should work,
 doesn't" -- in my login view, I would `authenticate()` and `login()`
 properly, but with a redirect response I would be an `AnonymousUser`
 immediately after.

 After two days of debugging and re-reading docs, I found that I missed out
 a fairly critical sentence: "Authentication backends implements two
 required methods". -- my authentication backend (of which I was replacing
 the default) - did not implement `get_user()` so we would use the default
 `BaseBackend.get_user()` which is to `return None`.

 To me, it wasn't quite obvious why the authentication system needs to
 implement get_user ( as i'd want to just get the user by pk like any
 other) so this was a little bit of time wasting that I feel could be made
 a bit more obvious.

 Some ideas:
 * `BaseBackend` to implement a simple `get_user_model().objects.get(
 _meta.pk=pk)` - seeming this is the default for most cases (as far as I
 know?)
 * `BaseBackend` to raise `NotImplemented` to force implementors to define
 ''these two required methods'' as that is what is mentioned in the docs
 
(https://docs.djangoproject.com/en/4.1/topics/auth/customizing/#:~:text=implements%20two%20required%20methods)
 * anyone requiring the failthrough approach so that one can auth and
 get_user on different backends can just `pass` it
 * something else.


 Happy for some thoughts/feedback/pushback. This was just a painpoint for
 me while developing.

 Perhaps it needs to be highlighted in 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/01070183684781be-2bc64ca9-eb92-4d53-924a-44963de05d50-00%40eu-central-1.amazonses.com.

[Django] #34032: Base authentication Backend should raise NotImplemented on needed methods

[Django]

#34032: Base authentication Backend should raise NotImplemented on needed 
methods
-+
   Reporter:  Dre Westcook   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.auth   |Version:  4.0
   Severity:  Normal |   Keywords:  authentication
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Hi all,

 Recently I've been trying my hand at creating alternative sign on methods
 for a django system and I've found the whole process fairly clean.

 However I did reach bit of a time waste when my "code that should work,
 doesn't" -- in my login view, I would `authenticate()` and `login()`
 properly, but with a redirect response I would be an `AnonymousUser`
 immediately after.

 After two days of debugging and re-reading docs, I found that I missed out
 a fairly critical sentence: "Authentication backends implements two
 required methods". -- my authentication backend (of which I was replacing
 the default) - did not implement `get_user()` so we would use the default
 `BaseBackend.get_user()` which is to `return None`.

 To me, it wasn't quite obvious why the authentication system needs to
 implement get_user ( as i'd want to just get the user by pk like any
 other) so this was a little bit of time wasting that I feel could be made
 a bit more obvious. but I'm happy for other considerations.

 Some ideas I had for changing this that might've saved time in the future:
 * `BaseBackend` to implement a simple `get_user_model().objects.get(
 _meta.pk=pk)` - seeming this is the default for most cases (as far as I
 know?)
 * `BaseBackend` to raise `NotImplemented` to force implementors to define
 ''these two required methods'' as that is what is mentioned in the docs
 
(https://docs.djangoproject.com/en/4.1/topics/auth/customizing/#:~:text=implements%20two%20required%20methods)
 * anyone requiring the failthrough approach so that one can auth and
 get_user on different backends can just `pass` it
 * something else


 Happy for some thoughts /feedback / pushback. I just know that this was a
 painpoint for me and it wasn't obvious where the `AnonymousUser` was
 coming from. Perhaps it's just a documentation 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/0107018368293537-e07cb271-efac-4955-9843-81bfdc7173b3-00%40eu-central-1.amazonses.com.

Re: [Django] #29564: Executing createsuperuser with non-default database.

[Django]

#29564: Executing createsuperuser with non-default database.
-+-
 Reporter:  Oleg Żero|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  multiple database| Triage Stage:
  router createsuperuser |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 What's the bug? `createsuperuser --database` is
 [https://docs.djangoproject.com/en/dev/ref/django-admin/#cmdoption-
 createsuperuser-database documented].

-- 
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/0107018367f76915-f00d9e73-5219-422c-8ec9-9ad24d424e8a-00%40eu-central-1.amazonses.com.

Re: [Django] #29564: Executing createsuperuser with non-default database.

[Django]

#29564: Executing createsuperuser with non-default database.
-+-
 Reporter:  Oleg Żero|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  multiple database| Triage Stage:
  router createsuperuser |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by David A):

 I know I'm going to upset someone for posting on a 4yr old topic.  but
 this is more a documentation bug, but I've long since learned that django
 docs are lacking...

-- 
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/0107018367cca01f-36c78e1e-1bf0-44f5-8137-c39b40c2d7df-00%40eu-central-1.amazonses.com.

Re: [Django] #34025: Bug on autocomplete field when two fields from same reference model are added in same page

[Django]

#34025: Bug on autocomplete field when two fields from same reference model are
added in same page
-+-
 Reporter:  Alexandre da Silva   |Owner:  David
 |  Sanders
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  admin, autocomplete  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Alexandre da Silva):

 ''While I could reproduce the described issue for creates, I couldn't do
 so for edits. In the edit screen only the field for which I clicked "+"
 was updated.''

 To reproduce on edit, the steps are:
1. create a new record for order
2. select an existing supplier on select combobox, then click on edit.
3. save the supplier record, customer select also gets updated



 Applied patch and tested locally, so the issue semms to be resolved for
 both cases, add and edit.

-- 
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/0107018367312f98-59aa480a-bb77-4167-b74e-1bb17913bf40-00%40eu-central-1.amazonses.com.

[Django] #34031: Option to remove "all" option in admin SimpleListFilter

[Django]

#34031: Option to remove "all" option in admin SimpleListFilter
-+-
   Reporter: |  Owner:  nobody
  dunderr|
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  4.0
  contrib.admin  |   Keywords:  list_filter,
   Severity:  Normal |  choices, simplelistfilter
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 In order to remove the "All" option from admin list filters you have to
 override the `choices` function. There should be an easier way to do this.

 More details can be found in this stackoverflow thread. It seems like this
 is a requested feature.
 https://stackoverflow.com/questions/53821727/django-admin-list-filter-
 remove-all-option

-- 
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/0107018367019def-b02f280f-acb1-4503-9dc5-84f8808d5a87-00%40eu-central-1.amazonses.com.

[Django] #34030: add SystemCheckError for LocaleMiddleware

[Django]

#34030: add SystemCheckError for LocaleMiddleware
-+-
   Reporter:  Maxim  |  Owner:  nobody
  Danilov|
   Type:  New| Status:  new
  feature|
  Component:  Core   |Version:  4.0
  (Management commands)  |
   Severity:  Normal |   Keywords:  i18n, SystemCheck
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 From documentation:
 To use LocaleMiddleware, add 'django.middleware.locale.LocaleMiddleware'
 to your MIDDLEWARE setting.
 It should come after SessionMiddleware. And it should come before
 CommonMiddleware

 for AuthenticationMiddleware we have already this systemCheck admin.E410:

 ERRORS: (admin.E410)
 'django.contrib.sessions.middleware.SessionMiddleware' must be in
 MIDDLEWARE in order to use the admin application.
 HINT: Insert
 'django.contrib.sessions.middleware.SessionMiddleware' before
 'django.contrib.auth.middleware.AuthenticationMiddleware'.

 But we don't have those check for LocaleMiddleware

-- 
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/01070183668c16a0-809a427d-8351-4f94-b5ca-aba5aa4b5215-00%40eu-central-1.amazonses.com.

Re: [Django] #32263: squashmigrations produces incorrect result with a RenameModel on a ForeignKey target.

[Django]

#32263: squashmigrations produces incorrect result with a RenameModel on a
ForeignKey target.
-+-
 Reporter:  InvalidInterrupt |Owner:  Anvesh
 |  Mishra
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.1
 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 Anvesh Mishra):

 * owner:  (none) => Anvesh Mishra


-- 
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/01070183665e1985-5b4a150e-71e1-49fd-9c95-e59fb9e2bb35-00%40eu-central-1.amazonses.com.

Re: [Django] #33100: Add a DateInput widget that provides a date picker via the HTML element

[Django]

#33100: Add a DateInput widget that provides a date picker via the HTML  element
-+--
 Reporter:  dvg  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  3.2
 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
-+--

Comment (by Steven Mapes):

 It should be noted that just changing the type attribute is **not** all
 you need to do in order to use the date and time  inputs correctly within
 Django. Whilst doing that will render the HTML input it will not pickup
 the initial values correctly as you need to format them into the right
 input format, normally by using isoformat() on either the initial or
 instance value depending on whether you are using a standard form or model
 form.

 The "datetime-local" input will work okay without any other changes.

 For the sake of anyone coming back to this ticket in the future here's one
 way of subclassing the DateInput and TimeInput widgets with the updated
 render method that will mean you can then use these as you would standard
 widgets and won't hit the issues described above

 {{{
 class DateInputPicker(DateInput):
 input_type = "date"

 def render(self, name, value, attrs=None, renderer=None):
 """Render the widget as an HTML string."""
 value = value.isoformat() if value and isinstance(value, date)
 else value
 context = self.get_context(name, value, attrs)
 return self._render(self.template_name, context, renderer)


 class TimeInputPicker(TimeInput):
 input_type = "time"

 def render(self, name, value, attrs=None, renderer=None):
 """Render the widget as an HTML string."""
 value = value.isoformat() if value and isinstance(value, date)
 else value
 context = self.get_context(name, value, attrs)
 return self._render(self.template_name, context, renderer)
 }}}

-- 
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/010701836647d09a-4f21235a-f7af-4918-87a6-e152de6e24c5-00%40eu-central-1.amazonses.com.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  Clouds
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Clouds):

 Hello, the main work of CompoisteField has been done and I'm now working
 on `primary_together`/`PrimaryKeyConstraint`.
 While I've got several questions:

 1. How to write test for migration? (or witch existing test as example)
a. test if the model generating correct models.State
b. test if from OldModel to NewModel would success migrated
 2. Shall we have PrimaryKeyConstraint and CompositeField in one PR?
a. primary (without multicolumn) first, then composite
b. composite (cannot set as PK) first, then primary

 The main blocker split it into 2 PR might be hard to add meaningful tests
 in first PR.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018364d84469-b3955cf4-9498-4583-a141-bfd8801c21c0-00%40eu-central-1.amazonses.com.

Re: [Django] #34012: QuerySet.order_by() silently skips non-existing fields on related fields with Meta.ordering.

[Django]

#34012: QuerySet.order_by() silently skips non-existing fields on related fields
with Meta.ordering.
-+-
 Reporter:  Klaas van Schelven   |Owner:  David
 Type:   |  Sanders
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"37a13cc92d51d5a57b42240b9a5dd250648efa24" 37a13cc9]:
 {{{
 #!CommitTicketReference repository=""
 revision="37a13cc92d51d5a57b42240b9a5dd250648efa24"
 Refs #34012 -- Added test for ordering by transform of related fields.
 }}}

-- 
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/0107018364d717ff-34e7ddc4-1214-4e64-8c72-02811269-00%40eu-central-1.amazonses.com.

Re: [Django] #34026: WKBReader.read() crashes on strings.

[Django]

#34026: WKBReader.read() crashes on strings.
--+
 Reporter:  Benoît Vinot  |Owner:  Leo Tom
 Type:  Bug   |   Status:  assigned
Component:  GIS   |  Version:  4.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham):

 * needs_tests:  0 => 1


Comment:

 Please uncheck "Needs tests" when you add one to the PR.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018364c08c94-629e750a-44e4-44b6-b5b7-0806276f2e64-00%40eu-central-1.amazonses.com.

Re: [Django] #33586: Cannot delete object (A) referenced by another object (B) if said object (A) has a foreign key to a custom user.

[Django]

#33586: Cannot delete object (A) referenced by another object (B) if said object
(A) has a foreign key to a custom user.
---+
 Reporter:  Jeremy Poulin  |Owner:  Bhuvnesh
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Bhuvnesh):

 you were right, the problem was inside {{{RunPython.state_forwards}}} as
 it is not mutating any state . but it looks like like we need to reload
 apps cache before running backwards migration after forward migration.
 {{{
 def state_forwards(self, app_label, state):
 # RunPython objects have no state effect. To add some, combine
 this
 # with SeparateDatabaseAndState.
 pass
 }}}

 one thing we can do is re-creating the apps inside
 {{{database_backwards}}} for RunPython Operation. This should also not
 affect the performance much.
 {{{ #!patch
 diff --git a/django/db/migrations/operations/special.py
 b/django/db/migrations/operations/special.py
 index 94a6ec72de..835f2c7017 100644
 --- a/django/db/migrations/operations/special.py
 +++ b/django/db/migrations/operations/special.py
 @@ -193,6 +193,7 @@ class RunPython(Operation):
  self.code(from_state.apps, schema_editor)

  def database_backwards(self, app_label, schema_editor, from_state,
 to_state):
 +from_state.__dict__.pop('apps', None)
  if self.reverse_code is None:
  raise NotImplementedError("You cannot reverse this
 operation")
  if router.allow_migrate(
 }}}
 we could've done the same thing inside {{{RunPython.state_forwards}}} but
 since reloading apps is not required for forward migrations, we can save
 some time there.

 Ps: Passing all 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/0107018364b8323f-215bf009-c303-4bad-8b17-f27d731ea6a5-00%40eu-central-1.amazonses.com.

Re: [Django] #34029: Use case that require QuerySet.extra

[Django]

#34029: Use case that require QuerySet.extra
-+-
 Reporter:  Fath |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 You can use the `Case()` expression.

 If you're having trouble understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help. Trac is not
 a support channel.

-- 
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/01070183645a7ec2-4866b0c7-07e8-431b-a0ac-2c52f8f87437-00%40eu-central-1.amazonses.com.

Re: [Django] #34026: WKBReader.read() crashes on strings.

[Django]

#34026: WKBReader.read() crashes on strings.
--+
 Reporter:  Benoît Vinot  |Owner:  Leo Tom
 Type:  Bug   |   Status:  assigned
Component:  GIS   |  Version:  4.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Leo Tom):

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

-- 
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/0107018363de6826-c5eb4ac6-1c1a-4ad8-b4f9-64d31b49c78f-00%40eu-central-1.amazonses.com.

Re: [Django] #34026: WKBReader.read() crashes on strings.

[Django]

#34026: WKBReader.read() crashes on strings.
--+
 Reporter:  Benoît Vinot  |Owner:  Leo Tom
 Type:  Bug   |   Status:  assigned
Component:  GIS   |  Version:  4.1
 Severity:  Normal|   Resolution:
 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 Leo Tom):

 * has_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/0107018363de14e1-d94d0203-25fc-47d7-8ec2-efa8e2f59966-00%40eu-central-1.amazonses.com.