Re: [Django] #35338: Behaviour change in URL patterns.

[Django]

#35338: Behaviour change in URL patterns.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Core (URLs) |  Version:  dev
 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
+--
Changes (by Carlton Gibson):

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

Comment:

 > IMO the fix should be made in Channels here, since it’s using private
 attributes. I have made a PR there:
 ​https://github.com/django/channels/pull/2085 .

 Agreed. That looks like the right fix. Thanks Adam.
-- 
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/0107018e88d28158-577fe572-7065-4296-8023-7b00315d006c-00%40eu-central-1.amazonses.com.

Re: [Django] #35338: Behaviour change in URL patterns.

[Django]

#35338: Behaviour change in URL patterns.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (URLs) |  Version:  dev
 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 Adam Johnson):

 >  a likely explanation of why the _route_to_regex() helper was previously
 called twice, each time discarding half the result.

 It was called twice since introduction in
 df41b5a05d4e00e80e73afe629072e37873e767a. Channels only started touching
 `_is_endpoint` two years later in
 
[https://github.com/django/channels/commit/984e9dc9cece66f7520bc9c1fd0583e9c60b1022
 984e9dc9cece66f7520bc9c1fd0583e9c60b1022].

 IMO the reason it was called twice was refactoring during development to
 support translated URLs, without consideration for keeping the fast path
 for non-translated ones.

 >  The change breaks the ability to have non-endpoint usages of path(),
 because the regex is compiled on instantiation before _is_endpoint can be
 updated.

 Well, yes, but from Django’s perspective that shouldn’t happen. `path()`
 is an endpoint, `include()` is for a non-endpoint:
 
https://github.com/django/django/blob/5f3cdf219de71021cc5b965695dbe0c881c0a4f1/django/urls/conf.py#L62-L96
 .

 > whilst also keeping the system check performance gain.

 Just to be clear, removing double execution of `_route_to_regex()` doesn’t
 affect only system checks, but every Django process that loads the URLconf
 - `runserver`, production servers, some management commands, ...

 ---

 IMO the fix should be made in Channels here, since it’s using private
 attributes. I have made a PR there:
 https://github.com/django/channels/pull/2085 .

 (Ideally, Channels should have its own `path()` / `re_path()`, because it
 does the routing itself anyway. But that boat has sailed.)

 If we don’t want that fix, the only thing I can think of is making
 `RegexPattern` and `RoutePattern` bend over backwards to support
 `_is_endpoint` changing with something like this:

 {{{
 diff --git django/urls/resolvers.py django/urls/resolvers.py
 index c667d7f268..6c5770cb61 100644
 --- django/urls/resolvers.py
 +++ django/urls/resolvers.py
 @@ -316,11 +316,19 @@ class RoutePattern(CheckURLMixin):

  def __init__(self, route, name=None, is_endpoint=False):
  self._route = route
 -self._regex, self.converters = _route_to_regex(str(route),
 is_endpoint)
  self._regex_dict = {}
  self._is_endpoint = is_endpoint
  self.name = name

 +@property
 +def _is_endpoint(self):
 +return self.__is_endpoint
 +
 +@_is_endpoint.setter
 +def _is_endpoint(self, value):
 +self.__is_endpoint = value
 +self._regex, self.converters = _route_to_regex(str(self._route),
 value)
 +
  def match(self, path):
  match = self.regex.search(path)
  if match:
 }}}
-- 
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/0107018e86fa39da-4a61b239-c3aa-4188-9911-dba31d2b157a-00%40eu-central-1.amazonses.com.

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| 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):

 Replying to [comment:14 HeejunShin]:
 > Is this ticket solved?

 No. While it has an inline tentative patch no one
 [https://docs.djangoproject.com/en/5.0/internals/contributing/writing-code
 /submitting-patches/#claiming-tickets has opened a PR on Github with the
 proposed changes] including a regression test yet.
-- 
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/0107018e86adcc12-e7b9506c-6215-4f1b-bd26-a87eacf05640-00%40eu-central-1.amazonses.com.

Re: [Django] #35338: Behaviour change in URL patterns.

[Django]

#35338: Behaviour change in URL patterns.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (URLs) |  Version:  dev
 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 Carlton Gibson):

 OK, here's the difference. The Channels `URLRouter` essentially does this.

 Before the commit:


 {{{
 >>> from django.urls import path
 >>> p = path("test/", lambda x: x)
 >>> p.pattern._is_endpoint = False
 >>> p.pattern.regex
 re.compile('^test/')
 }}}

 After the commit:


 {{{
 >>> from django.urls import path
 >>> p = path("test/", lambda x: x)
 >>> p.pattern._is_endpoint = False
 >>> p.pattern.regex
 re.compile('^test/\\Z')
 }}}


 The change breaks the ability to have non-endpoint usages of `path()`,
 because the regex is compiled on instantiation before `_is_endpoint` can
 be updated.

 That's clearly a private attribute, but Channel's ability to have nested
 URL routing depends on it, and it's a likely explanation of why the
 `_route_to_regex()` helper was previously called twice, each time
 discarding half the result.

 It would be good to find a way to defer the `_route_to_regex()[0]` call
 until needed, to not change the behaviour here, whilst also keeping the
 system check performance gain.
-- 
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/0107018e8665c784-ed1fd54d-7a50-4773-8585-bffb4f8d4d94-00%40eu-central-1.amazonses.com.

Re: [Django] #35338: Behaviour change in URL patterns.

[Django]

#35338: Behaviour change in URL patterns.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (URLs) |  Version:  dev
 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 Carlton Gibson):

 Not yet. It only showed up this afternoon and I didn’t have a chance to
 sit down with it yet.

 The `route.pattern.match()` is returning `None`, where before it was
 matching. Haven’t yet been able to look at why.
-- 
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/0107018e85c98796-19e27e66-5e58-4c35-ae0f-b7b16a3d129c-00%40eu-central-1.amazonses.com.

Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

[Django]

#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  postgres,| Triage Stage:  Accepted
  generatedfield, contains   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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

Comment:

 > Out of curiosity, why does this issue only present itself when adding a
 field? Does Django handle SQL generation differently for table creation vs
 field addition?

 I'm still laying down the details
 [https://github.com/django/django/pull/18027 in this MR] but the short
 answer is yes.

 The DBAPI `Cursor.execute` method can be used in two ways when dealing
 with parameters. Either `(sql: str, params: [])` which will delegate
 parametrization to the library or `(sql: str, params: None)` which won't
 attempt to parametrize the SQL. This is an important difference and
 requires special care when dealing with `%` literals in parameters as it's
 the symbol use for parametrization placeholders by most libraries.

 Well some backend simply don't support parametrization in some DDL
 statements such as `GENERATED` columns declaration, in other words you
 can't do

 {{{#!python
 cursor.execute(
 "ALTER TABLE invoice ADD COLUMN discount_display text GENERATED ALWAYS
 discount || %s;",
 ["%"]
 )
 }}}

 So you must do

 {{{#!python
 cursor.execute(
 "ALTER TABLE invoice ADD COLUMN discount_display text GENERATED ALWAYS
 AS discount || '%';", None
 )
 }}}

 Well in the case of `SchemaEditor.create_model` we liberally do one or the
 other and in your case, because you don't have any other field with a
 `db_default` assuming your use Postgres, it does the right thing.

 In the case of `SchemaEditor.add_field` however we always do `params:
 list`, which forces parametrization, and thus

 {{{#!python
 cursor.execute(
 "ALTER TABLE testmodel ADD COLUMN contains_heck text GENERATED ALWAYS
 AS UPPER(description) LIKE '%HECK%';", []
 )
 }}}

 Crashes as there is an attempt to interpolate the two `%` while `params`
 is empty.

 The schema migration has historically use parametrizable DDL in the past
 when possible but this has become increasingly complex as more and more
 features were added (indexes, constraints, `db_default`, `GeneratedField`)
 to a point where I don't think we can continue doing so but the tricky
 part is that we can't make such a change in a bug fix release without
 risking to introduce further problems. This is made even worst by the fact
 that objects as `Index` and `Constraint` subclasses return already
 interpolated SQL (their `as_sql` methods return `"CHECK UPPER(description)
 LIKE '%HECK%'"` instead of `("CHECK UPPER(description) LIKE %s",
 "%HECK%")` so even if we wanted to use it entirely to the backend until
 the last minute by using `quote_value` ourselves we can't as by that point
 we have a mixture of interpolated and non-interpolated SQL.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e85bd49fd-1ec7c223-0d2b-42a0-b93a-b156e26d2245-00%40eu-central-1.amazonses.com.

Re: [Django] #35338: Behaviour change in URL patterns.

[Django]

#35338: Behaviour change in URL patterns.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (URLs) |  Version:  dev
 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 Natalia Bidart):

 Hello Carlton! Thank you for the report and details.

 Would you have a failing regression test for the Django test suite?
 Otherwise I'll try to come up with one :-)
-- 
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/0107018e859ff02d-60a70090-a4c4-474d-8e3e-3ac40706175c-00%40eu-central-1.amazonses.com.

Re: [Django] #35340: Why does Django add 1 second to the lifetime of a cookie?

[Django]

#35340: Why does Django add 1 second to the lifetime of a cookie?
---+--
 Reporter:  Leonid |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  HTTP handling  |  Version:  5.0
 Severity:  Normal |   Resolution:  invalid
 Keywords:  cookies| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by David Sanders):

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

Comment:

 Issue trackers are for reporting bugs, please don't seek assistance here.
 You can get help from friendly community members on Discord or the forum
 👍 https://www.djangoproject.com/community/
-- 
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/0107018e85781997-0cf43a29-8c00-47c0-8975-27ad742125e3-00%40eu-central-1.amazonses.com.

[Django] #35340: Why does Django add 1 second to the lifetime of a cookie?

[Django]

#35340: Why does Django add 1 second to the lifetime of a cookie?
-+-
   Reporter:  john-psina |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  HTTP handling  |Version:  5.0
   Severity:  Normal |   Keywords:  cookies
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm trying to implement JWT authentication using django-graphql-jwt on the
 backend, and nuxt3 for the frontend. My token and refresh_token are stored
 in cookies, and I wrapped the GraphQLView in a jwt_cookie decorator that
 automatically checks for the existence of the jwt token in the cookie, as
 well as its validity.
 In general, everything works great. When I send an authorization request,
 the backend returns me the "Set-Cookie" headers for JWT and
 JWT_REFRESH_TOKEN with an expiration date that automatically deletes them
 as soon as they become invalid, which saves me a lot of code/logic on the
 frontend.

 However, there is one very unpleasant thing - Django adds 1 second to the
 cookie lifetime for some reason in the set_cookie function, and it ruins
 everything. Here is the Django code:

 {{{
 def set_cookie(
 self,
 key,
 value="",
 max_age=None,
 expires=None,
 path="/",
 domain=None,
 secure=False,
 httponly=False,
 samesite=None,
 ):
 self.cookies[key] = value
 if expires is not None:
 if isinstance(expires, datetime.datetime):
 if timezone.is_naive(expires):
 expires = timezone.make_aware(expires,
 datetime.timezone.utc)
 delta = expires -
 datetime.datetime.now(tz=datetime.timezone.utc)
 # Add one second so the date matches exactly (a fraction
 of
 # time gets lost between converting to a timedelta and
 # then the date string).

 # Here's what I mean ↓↓↓
 delta += datetime.timedelta(seconds=1)


 # Just set max_age - the max_age logic will set expires.
 expires = None
 if max_age is not None:
 raise ValueError("'expires' and 'max_age' can't be
 used together.")
 max_age = max(0, delta.days * 86400 + delta.seconds)
 else:
 self.cookies[key]["expires"] = expires
 else:
 ...

 }}}

 I see the comment from Django, but I still don't understand what it means.

 This may not be a critical issue, but I just can't understand why they did
 it. The result of this behavior is that within 1 second after the token
 has expired, it is still in the user's cookies, and that doesn't seem
 right to me.
 I can fix this problem by subtracting 1 second when creating cookies, but
 I would like to avoid unpredictable errors that may arise due to this
 innovation.

 I would appreciate your answers and explanations :)
-- 
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/0107018e8565d723-f183b1d6-85a6-4eb0-aad1-c61688f97554-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

[Django]

#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
---+--
 Reporter:  dz |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  5.0
 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
---+--
Changes (by Natalia Bidart):

 * keywords:  facets change view =>
 * resolution:   => invalid
 * status:  new => closed

Comment:

 I did some extra debugging and noticed that you are overriding
 `change_view` in an incorrect manner. See
 
[https://docs.djangoproject.com/en/5.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.change_view
 the change_view docs]:

 {{{
  ModelAdmin.change_view(request, object_id, form_url='',
 extra_context=None)
 }}}

 your `change_view` is not correctly accepting the `form_url` kwarg and is
 not passing it along, so it ends up being None.

 Since the goal of this issue tracker is to track issues about Django
 itself, and your issue is located in your custom code, I'll be closing
 this ticket as invalid following the
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#closing-tickets ticket triaging process]. If you have further
 questions about how to use Django, please use any of the user support
 channels from [https://docs.djangoproject.com/en/dev/faq/help/#how-
 do-i-do-x-why-doesn-t-y-work-where-can-i-go-to-get-help this link].

 Cheers! Natalia.
-- 
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/0107018e85636c94-0a62628f-ae60-4114-b25c-a9e401bbb807-00%40eu-central-1.amazonses.com.

[Django] #35339: Ordering and filtering a Postgres ArrayAgg with parameters inverts SQL param order

[Django]

#35339: Ordering and filtering a Postgres ArrayAgg with parameters inverts SQL
param order
-+-
   Reporter:  Chris M|  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  5.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  |
-+-
 When trying to build an ArrayAgg annotation that has a `filter` with
 parameters and a `ordering` with parameters, the SQL that is built will
 invert the parameters, putting the filter parameters before the ordering
 parameters. I was not able to find an existing ticket for this issue.

 I have verified this against the current dev branch as well as version
 3.2.

 I was able to reproduce this in a test in the test_aggregates.py file.

 {{{#!python
 def test_array_agg_filter_and_ordering_params(self):
 values = AggregateTestModel.objects.aggregate(
 arrayagg=ArrayAgg(
 "char_field",
 filter=Q(json_field__has_key="lang"),
 ordering=LPad(Cast("integer_field", CharField()), 2,
 Value("0")),
 )
 )
 self.assertEqual(values, {"arrayagg": ["Foo2", "Foo4"]})
 }}}

 The resulting error is something like

 {{{
 Traceback (most recent call last):
   File "/Users/camuthig/projects/oss/django/django/db/backends/utils.py",
 line 105, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UndefinedFunction: function lpad(character varying,
 integer, integer) does not exist
 LINE 1: ...s_tests_aggregatetestmodel"."char_field" ORDER BY LPAD(("pos...
  ^
 HINT:  No function matches the given name and argument types. You might
 need to add explicit type casts.
 }}}

 The issue is that the result of the `OrderableAggMixin.as_sql` function is

 SQL:
 {{{
 ARRAY_AGG("postgres_tests_aggregatetestmodel"."char_field" ORDER BY
 LPAD(("postgres_tests_aggregatetestmodel"."integer_field")::varchar, %s,
 %s)) FILTER (WHERE "postgres_tests_aggregatetestmodel"."json_field" ? %s)
 }}}

 Parameters
 {{{
 [ "lang", 2, "0"]
 }}}

 So we are trying to use "lang" and 2 as the values for the ordering
 function, and "0" as the parameter for the filtering function. This is
 made a bit more confusing if the expression you are aggregating also has a
 parameter, because that should be before the ordering parameters. It
 should be

 1. Expression parameters
 2. Ordering parameters
 3. Filtering parameters

 This happens because both the expression and filtering parameters come
 from the standard Aggregate parent class, and are then put in front of the
 ordering parameters in the Postgres-specific orderable mixin.

 I have been able to resolve this issue locally by altering the
 `OrderableAggMixin.as_sql` function to retrieve the parameters from the
 parent and then split them manually.


 {{{#!python
 class OrderableAggMixin:
 # ... other functions

 def as_sql(self, compiler, connection):
 if self.order_by is not None:
 order_by_sql, order_by_params =
 compiler.compile(self.order_by)
 else:
 order_by_sql, order_by_params = "", ()

 sql, expression_params = super().as_sql(compiler, connection,
 ordering=order_by_sql)

 filter_params = ()
 if self.filter:
 try:
 _, filter_params = self.filter.as_sql(compiler,
 connection)
 expression_params =
 expression_params[:-len(filter_params)]
 except FullResultSet:
 pass

 return sql, (*expression_params, *order_by_params, *filter_params)
 }}}


 This solution technically works, but it feels a bit clunky, so I am open
 to suggestions on how to improve it. I can also create a pull request with
 the change if you would like to see it, though my changes are all captured
 here already.
-- 
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/0107018e855e5e26-a8034f57-cc14-4365-92a7-186c14ea8ddb-00%40eu-central-1.amazonses.com.

Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

[Django]

#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  postgres,| Triage Stage:  Accepted
  generatedfield, contains   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Adrian Garcia):

 Thanks for looking into this, I'm glad to know that it's a bug and not me
 doing something incorrectly. I'll use `iregex` as a workaround until
 5.0.4.

 Out of curiosity, why does this issue only present itself when adding a
 field? Does Django handle SQL generation differently for table creation vs
 field addition?
-- 
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/0107018e855bb148-a86a2fd7-3d28-4690-b685-e139d3fa77cd-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

[Django]

#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Comment (by dz):

 Full versions have been attached.
-- 
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/0107018e855b6178-f4bb881e-f598-4cfa-bf2d-24f967600a2c-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

[Django]

#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by dz):

 * Attachment "app_files.zip" 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e85563bc3-f7410a1b-8674-4606-a7ce-75947c0830ab-00%40eu-central-1.amazonses.com.

Re: [Django] #35338: Behaviour change in URL patterns.

[Django]

#35338: Behaviour change in URL patterns.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (URLs) |  Version:  dev
 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
+--
Description changed by Carlton Gibson:

Old description:

> There's a behaviour change on `main` pre-5.1 in
> 5dfcf343cd414d3f7a33dabb763b4478fa081d72 for #35250.
>
> {{{
>
> commit 5dfcf343cd414d3f7a33dabb763b4478fa081d72
> Author: Adam Johnson 
> Date:   Sat Feb 24 19:14:22 2024 +
>
> Refs #35250 -- Avoided double conversion in RoutePattern.
>
>  django/urls/resolvers.py | 58
> ++--
>  1 file changed, 36 insertions(+), 22 deletions(-)
>
> }}}
>
> Since this commit, there are two failures in the Channels test suite.
>
> {{{
> $ pytest -k test_routing.py
>
> ...
>
> === short test summary info
> 
> FAILED tests/test_routing.py::test_url_router_nesting_path - ValueError:
> No r...
> FAILED tests/test_routing.py::test_path_remaining - ValueError: No route
> foun...
> == 2 failed, 6 passed, 55 deselected in 0.07s
> ==
> }}}
>
> See CI run here:
> https://github.com/django/channels/actions/runs/8467612542/job/23198786518#step:5:342

New description:

 There's a behaviour change on `main` pre-5.1 in
 5dfcf343cd414d3f7a33dabb763b4478fa081d72 for #35250.

 {{{

 commit 5dfcf343cd414d3f7a33dabb763b4478fa081d72
 Author: Adam Johnson 
 Date:   Sat Feb 24 19:14:22 2024 +

 Refs #35250 -- Avoided double conversion in RoutePattern.

  django/urls/resolvers.py | 58
 ++--
  1 file changed, 36 insertions(+), 22 deletions(-)

 }}}

 Since this commit, there are two failures in the Channels test suite.

 {{{
 $ pytest -k test_routing.py

 ...

 === short test summary info
 
 FAILED tests/test_routing.py::test_url_router_nesting_path - ValueError:
 No r...
 FAILED tests/test_routing.py::test_path_remaining - ValueError: No route
 foun...
 == 2 failed, 6 passed, 55 deselected in 0.07s
 ==
 }}}

 See CI run here:
 
https://github.com/django/channels/actions/runs/8467612542/job/23198786518#step:5:342


 Tracking issue on django/channels:
 https://github.com/django/channels/issues/2084

--
-- 
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/0107018e85535b37-265f6c91-ce97-4c18-b3e2-211787b2d118-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

[Django]

#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Comment (by Natalia Bidart):

 Hello, thank you for attaching your `models.py`. I see that the file is
 quite big and it depends on other modules/helpers that are not provided.
 Could you please provide, instead, a minimal `models.py` and a minimal
 `admin.py` to reproduce? That will be of great help for us and it will
 allow us to triage this ticket more effectively.
-- 
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/0107018e854effe5-fb5149dd-2b95-449b-87ea-af45f56d2fe9-00%40eu-central-1.amazonses.com.

[Django] #35338: Behaviour change in URL patterns.

[Django]

#35338: Behaviour change in URL patterns.
--+
   Reporter:  Carlton Gibson  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Core (URLs) |Version:  dev
   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   |
--+
 There's a behaviour change on `main` pre-5.1 in
 5dfcf343cd414d3f7a33dabb763b4478fa081d72 for #35250.

 {{{

 commit 5dfcf343cd414d3f7a33dabb763b4478fa081d72
 Author: Adam Johnson 
 Date:   Sat Feb 24 19:14:22 2024 +

 Refs #35250 -- Avoided double conversion in RoutePattern.

  django/urls/resolvers.py | 58
 ++--
  1 file changed, 36 insertions(+), 22 deletions(-)

 }}}

 Since this commit, there are two failures in the Channels test suite.

 {{{
 $ pytest -k test_routing.py

 ...

 === short test summary info
 
 FAILED tests/test_routing.py::test_url_router_nesting_path - ValueError:
 No r...
 FAILED tests/test_routing.py::test_path_remaining - ValueError: No route
 foun...
 == 2 failed, 6 passed, 55 deselected in 0.07s
 ==
 }}}

 See CI run here:
 
https://github.com/django/channels/actions/runs/8467612542/job/23198786518#step:5:342
-- 
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/0107018e854a8dab-8f6c8745-34e0-47d3-9d3e-156559a1863e-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

[Django]

#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Comment (by dz):

 Hi,
 I have attached a file with relevant models for the Bug.
 Regards
-- 
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/0107018e85387711-5d9c0a50-2eef-414b-b8aa-c3171b2ebfa9-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

[Django]

#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by dz):

 * Attachment "models.py" 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e85375fa1-b00eff02-2778-4a6a-96c1-962634909a6e-00%40eu-central-1.amazonses.com.

Re: [Django] #35331: Adding a new related entry using the "+" sign from M2M field doesn't update lists.

[Django]

#35331: Adding a new related entry using the "+" sign from M2M field doesn't 
update
lists.
---+--
 Reporter:  devin13cox |Owner:  devin13cox
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  5.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by Natalia Bidart):

 * needs_better_patch:  0 => 1

Comment:

 [https://github.com/django/django/pull/18026#issuecomment-2025084882 Per
 PR 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/0107018e851125d7-e705d0b0-2233-47c8-972d-703fc2f9ade3-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

[Django]

#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Natalia Bidart):

 * type:  Uncategorized => Bug


Old description:

> Hello,
>
> {{{
> Django==5.0.3
> }}}
>
> {{{
> @admin.register(LicitacionItem)
> class LicitacionItemAdmin(admin.ModelAdmin):
>
> list_select_related = ('licitacion', 'categoria',
>'proveedor', 'producto', 'licitacion_detalle')
>
> raw_id_fields = ('licitacion', 'categoria',
>  'proveedor', 'producto', 'licitacion_detalle')
>
> search_fields = ["CodigoExterno", 'search']
>
> show_facets = admin.ShowFacets.ALLOW
>
> list_filter = [
> ('licitacion__date', admin.DateFieldListFilter),
> ('licitacion__FechaCierre', admin.DateFieldListFilter),
> 'licitacion__CodigoEstado',
> 'active',
> 'licitacion_detalle__CodigoTipo',
> 'licitacion_detalle__Tipo',
> 'licitacion_detalle__TipoConvocatoria',
> 'licitacion_detalle__CodigoTipo']
>
> def change_view(self, request, object_id, extra_context=None):
> self.exclude = ('active', 'analizado', 'touch', 'search')
> return super(LicitacionItemAdmin, self).change_view(request,
> object_id, extra_context)
> }}}
>
> when clicking on an item (enter change view), without activating show
> facets: there are no errors.
>
> when clicking on an item (enter change view), with show facets activated:
> argument of type 'NoneType' is not iterable (see attached file with the
> trace)
>
> By completely removing the change_view function, the error does not occur
> (even if show facets is activated).
>
> Regards
>

> {{{
>
> }}}

New description:

 Hello,

 {{{
 Django==5.0.3
 }}}

 {{{
 @admin.register(LicitacionItem)
 class LicitacionItemAdmin(admin.ModelAdmin):

 list_select_related = ('licitacion', 'categoria',
'proveedor', 'producto', 'licitacion_detalle')

 raw_id_fields = ('licitacion', 'categoria',
  'proveedor', 'producto', 'licitacion_detalle')

 search_fields = ["CodigoExterno", 'search']

 show_facets = admin.ShowFacets.ALLOW

 list_filter = [
 ('licitacion__date', admin.DateFieldListFilter),
 ('licitacion__FechaCierre', admin.DateFieldListFilter),
 'licitacion__CodigoEstado',
 'active',
 'licitacion_detalle__CodigoTipo',
 'licitacion_detalle__Tipo',
 'licitacion_detalle__TipoConvocatoria',
 'licitacion_detalle__CodigoTipo']

 def change_view(self, request, object_id, extra_context=None):
 self.exclude = ('active', 'analizado', 'touch', 'search')
 return super(LicitacionItemAdmin, self).change_view(request,
 object_id, extra_context)
 }}}

 when clicking on an item (enter change view), without activating show
 facets: there are no errors.

 when clicking on an item (enter change view), with show facets activated:
 argument of type 'NoneType' is not iterable (see attached file with the
 trace)

 By completely removing the change_view function, the error does not occur
 (even if show facets is activated).

 Regards


 {{{
 1   Environment:
 2
 3
 4   Request Method: GET
 5   Request URL:
 
http://192.168.101.60/admin/mpublico/licitacionitem/54719/change/?_changelist_filters=_facets%3DTrue
 6
 7   Django Version: 5.0.3
 8   Python Version: 3.10.12
 9   Installed Applications:
 10  ['django.contrib.admin',
 11   'django.contrib.auth',
 12   'django.contrib.contenttypes',
 13   'django.contrib.sessions',
 14   'django.contrib.messages',
 15   'django.contrib.staticfiles',
 16   'localflavor',
 17   'mpublico',
 18   'rest_framework',
 19   'rest_framework.authtoken',
 20   'django_celery_results',
 21   'debug_toolbar',
 22   'import_export']
 23  Installed Middleware:
 24  ['debug_toolbar.middleware.DebugToolbarMiddleware',
 25   'django.middleware.security.SecurityMiddleware',
 26   'django.contrib.sessions.middleware.SessionMiddleware',
 27   'django.middleware.common.CommonMiddleware',
 28   'django.middleware.csrf.CsrfViewMiddleware',
 29   'django.contrib.auth.middleware.AuthenticationMiddleware'

Re: [Django] #34624: RelatedFieldWidgetWrapper links toggling isn’t working for radio widgets

[Django]

#34624: RelatedFieldWidgetWrapper links toggling isn’t working for radio widgets
---+
 Reporter:  Thibaud Colas  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  dev
 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:  1
---+
Comment (by Natalia Bidart):

 Replying to [comment:8 Anirudh Prabhakaran]:
 > Hello! What is the status of this ticket?
 >
 > I am planning to apply for GSoC, and so I think that trying to solve a
 ticket would give me a chance to get my hands dirty with the codebase. If
 this is not assigned to anyone, can I take a look?

 Hello Anirudh, this ticket is free to be worked on. You can use the
 existing PR as a starting point. Thanks for wanting to contribute to
 Django!
-- 
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/0107018e85050807-44c2b99f-c942-4dd5-aa88-671d797e715c-00%40eu-central-1.amazonses.com.

Re: [Django] #35319: Move the link to add a related object inside the .selector-available column for FilteredSelectMultiple.

[Django]

#35319: Move the link to add a related object inside the .selector-available 
column
for FilteredSelectMultiple.
-+-
 Reporter:  Hrushikesh Vaidya|Owner:
 Type:   |  Hrushikesh Vaidya
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Natalia Bidart):

 * needs_better_patch:  0 => 1
 * needs_docs:  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/0107018e84d064da-23cfc61a-45d5-4279-b229-761605a36635-00%40eu-central-1.amazonses.com.