[UmutAlisoglu]

Mixing an ORM __in lookup or a Q expression containing or with other filters can select rows that fail the other conditions. For example, ID__in=[2, 3], NameLast='Smith' currently allows ID 2 regardless of its name.

This implements the opt-in group=True approach suggested in #280. It groups individual conditions, Q arguments and the preceding filter on chained calls. Grouping stays disabled by default, and all existing query serialization tests pass. The new option reserves group on .filter(); an entity property with that name remains accessible through Q(group=value).

The 14 new cases cover mixed keyword/Q conditions, __in inside Q, compound OR, AND, chained calls, string replacement, empty input, unchanged legacy output and Unicode encoding. Parameterized cases assert explicit filter strings and fully encoded URLs from mocked HTTP requests, alongside evaluating the selected rows with Python's independent AST parser.

Documentation and the Unreleased changelog are updated. Thanks to @developer992 for reporting the problem and @phanak-sap for the opt-in design. Addresses #280; follows up on the closed default-changing proposals #283 and #321.

Validation on Windows / Python 3.11.9:

• Full suite after rebasing onto current master: 314 passed, 93% overall coverage.
• Required Pylint 2.15.0: 10.00/10; required Flake8 3.8.4 passes.
• Sphinx generates HTML, but -W fails on the same five pre-existing configuration/vendor-page warnings on both original and patched documentation.
• git diff --check passes.

AI-assisted with OpenAI Codex, including investigation, implementation and verification.

[cla-assistant]

All committers have signed the CLA.

[phanak-sap]

matching a hardcoded URL

Hi @UmutAlisoglu thx for the PR (and explicit note about AI usage). This looks like solid enhancement (yeah, "opt-in" not backward breaking, as envisioned in #280).

I understand your/agent logic for ast module in test. Yeah, makes sense and will stay. But for readability reasons and perhaps even possible encoding problems, the parameterized tests could actually also have the hardcoded expected URLs - not as "rather than only" but as "addition to ast".

[UmutAlisoglu]

Thanks. I kept the AST checks and added explicit expected filter strings and full encoded URLs to each parameterized case. The tests also execute mocked requests and check the actual URL, including a Unicode case. All 312 tests pass locally.

[phanak-sap]

Thanks. I kept the AST checks and added explicit expected filter strings and full encoded URLs to each parameterized case. The tests also execute mocked requests and check the actual URL, including a Unicode case. All 312 tests pass locally.

thx. pls resolve the conflict around changelog from different PR merged. funny, around similar area.
I will go trough review approval but looking really good.

[phanak-sap]

Jumping between PRs that appeared past two days I have read through this several time. I do not see any apparent problem, I like that the default is False so no breaking changes for current users, docs and test are OK.

Checked with AI tools as well.

[phanak-sap]

I have a itch/gut feeling that more complex test cases for multiple AND/OR/Parenthesis could be added, but that can be safely part of separate PR anyway, due hiding essentially behind a feature flag.

[UmutAlisoglu]

Rebased onto current master and kept both changelog entries. All 314 tests and the required Pylint/Flake8 checks pass locally. The conflict is resolved.