Support filters in `SearchQuery` and `PatchOp`

[azmeuk]

scim2-models should support path filters described in RFC7644 §3.4.2.2 for search and patch requests.

Related project: https://scim2-filter-parser.readthedocs.io/en/stable/

[azmeuk]

After giving some thoughts I can think of several places where filters are involved:

• GET requests on resources endpoints, in a filter query parameter that can be used to restrict the results.
• POST requests on /.search, in the filter parameter of SearchRequest that can be used to restrict the results.
• PATCH requests on resources, in the path parameter of PatchOperation that can be used to precisely spot which object to edit in a list.

GET & POST requests involves performing requests on all the objects of the server, where PATCH requests are limited to one single object. I guess for PATCH requests it would be easy to browse all items and select those which are matching the filters. So maybe a light custom implementation is doable here?

However for performance reasons it cannot be done for GET & POST requests. I guess this is why scim2-filter-parser is useful.

@ccoors you mention this issue in the following LOC. Do you have any advice on using scim2-filter-parser as a dependency of scim2-models for filter management?

https://github.com/python-scim/scim2-server/blob/916b3bb30e70ccdf3ad30bd2c355b2d8dc49980e/scim2_server/filter.py#L20-L23

What are the limitations of your implementation? What could help if implemented here?

[ccoors]

Looking back now I can honestly say I don't know how that code works - that's a pretty major limitation :D I remember using the debugger a lot and trying to get the necessary information out of that scim2ast structure. Getting the field annotations for some of the attributes referenced in the filter was particularly tricky. There's a comment in line 57 # FIXME: Best guesses since there is no way to know for sure by this point so that was definitely an issue. Having the entire filter structure validated by Pydantic would also be nice, that could eliminate the check_comparable_value function.

On the other hand it has proven to be a robust enough implementation, that piece of code hasn't caused any issues for us yet - probably because in production you only ever see very simple filter queries if any.

[azmeuk]

Thinking about this again, I think it might worth overhauling the Path object by using lark to implement the ABNF for attributes described in RFC7643 section 2.1 and the ABNF for filters described in RFC6744 section 3.4.2.2