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

A Sub-Attribute after a Value Path causes an 'unexpected token' error #96

Closed
mastermatt opened this issue Sep 24, 2022 · 1 comment · Fixed by #99
Closed

A Sub-Attribute after a Value Path causes an 'unexpected token' error #96

mastermatt opened this issue Sep 24, 2022 · 1 comment · Fixed by #99

Comments

@mastermatt
Copy link
Contributor

emails[type eq "work" and value eq "[email protected]"]
emails[type eq "work"] and emails.value eq "[email protected]"
emails[type eq "work"].value eq "[email protected]"

The three above filters are all functionally identical, however, the last one throws:
Error: unexpected token .value eq "[email protected]"

I'll note that the syntax throwing the error is not explicitly listed in the examples of section 3.4.2.2 and the wording of that section leaves this syntax up in the air. However, section 3.5.2 (Modifying with PATCH) does include this syntax in its examples and callouts section 3.4.2.2 as the definition.
More importantly for my personal use case, Azure AD seems to use this syntax to query users (docs).

... a GET to /Users with a filter must allow for both userName eq "[email protected]" and emails[type eq "work"].value eq "[email protected]" queries.


I started working on a PR for this, but decided I should open an issue first and confirm what the expected result should be.
I presumed the desired output would an implicit and operation at the top level. e.g.

{
  "op": "and",
  "filters": [
    {
      "op": "[]",
      "attrPath": "emails",
      "valFilter": {
        "op": "eq",
        "attrPath": "type",
        "compValue": "work"
      }
    },
    {
      "op": "eq",
      "attrPath": "emails.value",
      "compValue": "[email protected]"
    }
  ]
}
@thomaspoignant
Copy link
Owner

Hello @mastermatt I was reading your issue and I think you are right, something is missing here.
If you can work on the PR it would be awesome 🙏.

mastermatt added a commit to mastermatt/scim2-parse-filter that referenced this issue Oct 2, 2022
Allow comparison operations on sub-attributes following value paths.
e.g. `emails[type eq "work"].value eq "[email protected]"`

The tokenizer regex was updated to allow for a trailing dot (.) after a closing square bracket (]) when searching for "Bracket" tokens.
`readValFilter` was then updated to look for any dot after the closing bracket and a following "Word" token. When this happens an implicit `and` op is returned.

One issue with this approach is that any `and` ops before or after this syntax will result in nested `and` ops instead of a single op with more than two filters. Check the last test added to `parse.test.ts` for an example. However, I couldn't figure out a neat way to flattening that use case without a much more disruptive changeset.

fixes: thomaspoignant#96
thomaspoignant pushed a commit that referenced this issue Oct 3, 2022
Allow comparison operations on sub-attributes following value paths.
e.g. `emails[type eq "work"].value eq "[email protected]"`

The tokenizer regex was updated to allow for a trailing dot (.) after a closing square bracket (]) when searching for "Bracket" tokens.
`readValFilter` was then updated to look for any dot after the closing bracket and a following "Word" token. When this happens an implicit `and` op is returned.

One issue with this approach is that any `and` ops before or after this syntax will result in nested `and` ops instead of a single op with more than two filters. Check the last test added to `parse.test.ts` for an example. However, I couldn't figure out a neat way to flattening that use case without a much more disruptive changeset.

fixes: #96
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants