Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for filtering of complex multi-value attributes in coerce method of SCIMMY.Types.SchemaDefinition #56

Merged
merged 4 commits into from
Oct 17, 2024

Conversation

sleelin
Copy link
Collaborator

@sleelin sleelin commented Oct 14, 2024

Currently, the SCIMMY.Types.Filter class does not parse comparators for complex filter expressions unless they are followed by a trailing attribute name (i.e. emails[type eq "work"].value pr as opposed to emails[type eq "work"] pr). When the trailing attribute name is missing, the comparator is ignored and the resulting filter is incomplete. This has flow on effects for the coerce method of the SCIMMY.Types.SchemaDefinition class, which is no longer instructed to include the emails attribute on the coerced value. Additional issues identified include the coerce method not evaluating all entries in a supplied filter (or even verifying the filter is an instance of the Filter class), and not omitting extension namespaces not explicitly included in a list of expected attribute inclusions.

Whilst technically defined in RFC7644§3.10 without reference to complex value filters, there is benefit in being capable of parsing and handling these expressions in the attributes parameter. Specifically, one would reasonably expect that an attributes parameter value of emails[type eq "work"] is a request to include only those emails that have a type value of work in the response.

This change adds support in the Filter class for parsing comparators of complex filter expressions not followed by trailing attribute names, updating relevant internal methods to account for this scenario. Test fixtures for the Filter class have been updated to verify correct parsing and matching of complex filter expressions not followed by trailing attribute names. Leveraging this change, the coerce method of the SchemaDefinition class has been updated to add support for filtering complex multi-value attributes, only including items that match the given expression in the attribute value (fixes #55). The coerce method has also been updated to verify the supplied filter (if any) is an instance of the Filter class, evaluate all expressions in a filter, and omit extension namespaces not explicitly included in a list of expected attribute inclusions.

@sleelin sleelin added the feature New feature or request label Oct 14, 2024
@sleelin sleelin added this to the 1.3.0 milestone Oct 14, 2024
@sleelin sleelin self-assigned this Oct 14, 2024
@sleelin sleelin linked an issue Oct 14, 2024 that may be closed by this pull request
@sleelin sleelin force-pushed the issue/55-resource-attributes-filter-expressions branch 2 times, most recently from bf9470e to 15736bb Compare October 17, 2024 05:56
@sleelin sleelin force-pushed the issue/55-resource-attributes-filter-expressions branch from 15736bb to 7266769 Compare October 17, 2024 06:11
@sleelin sleelin merged commit 06edabb into main Oct 17, 2024
2 checks passed
@sleelin sleelin deleted the issue/55-resource-attributes-filter-expressions branch October 17, 2024 06:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Development

Successfully merging this pull request may close these issues.

Filters on 'complex' attribute arrays don't seem to work
1 participant