[VitorCoelho]

What

The __in lookup of the chainable filter produced its alternatives without parentheses. Lookups are joined with and, and and binds tighter than or, so combining __in with any other lookup changed the meaning of the filter:

employees.filter(ID__in=[1, 2], NickName="Tim")
# before: $filter=ID eq 1 or ID eq 2 and NickName eq 'Tim'
#         == ID eq 1 or (ID eq 2 and NickName eq 'Tim')  -> wrong rows
# after:  $filter=(ID eq 1 or ID eq 2) and NickName eq 'Tim'

Why

The query returned entities that do not match the other lookups. This is the __in breakage mentioned in the discussion of #280. Only the output of __in itself is grouped, so other filters keep their current URLs, and __in with a single value is still a plain ID eq 1.

How it was tested

• New test test_count_with_chainable_filter_in_operator_and_other_lookup: fails on master, passes with the fix.
• New test for a single value (no parentheses).
• test_count_with_chainable_filter_in_operator now expects (ID eq 1 or ID eq 2 or ID eq 3), which has the same meaning.
• pytest: 300 passed.
• CHANGELOG updated (Unreleased / Fixed).