Deep filtering not working with Many to Any relationships

[leon-marzahn]

Describe the Bug

Below query is not working in the directus sdk, usually if the query isn't possible it throws an error, but this doesn't throw an error at all and just doesn't do the filter. The underlying properties are all correctly named, i verified it with individual queries to those collections.

To Reproduce

deep: {
  links_right: {
    // Filter only published links_right
    _filter: {
      item__navigation_links: {
        status: { _eq: 'published' }
      }
    },

    // Filter translations of navigation_links by language (NOT WORKING)
    item__navigation_links: {
      translations: {
        _filter: {
          languages_code: { _icontains: language }
        }
      }
    }
  }
}

Directus Version

v10.10.7

Hosting Strategy

Self-Hosted (Docker Image)

[hanneskuettner]

Did I presume correctly that this is GraphQL related?

Can you please share your full query, because afaik there are some intricacies when using queries and filters with M2A relations in GraphQL.

[leon-marzahn]

Hey, no this is actually via the Javascript sdk. The config I have provided is what I pass to the readItem/readItems functions.

[hanneskuettner]

Ah, you see, I was initially talking about GraphQL, because the item__<collection> syntax is exclusively for GraphQL, as documented here, and for REST queries you should use the item:<collection>.

So in your case, the query that should work, look like

deep: {
  links_right: {
    // Filter only published links_right
    _filter: {
      'item:navigation_links': {
        status: { _eq: 'published' }
      }
    },

    // Filter translations of navigation_links by language
    'item:navigation_links': {
      translations: {
        _filter: {
          languages_code: { _icontains: language }
        }
      }
    }
  }
}

But it seems like there is some undocumented behavior happening here, as filter queries apparently do get converted internally to the colon notation, if they contain __, which is why your first filter happened to work. I will open up a follow up issue to investigate that, but will close this issue for now, as it is not a bug, but rather wrong querying syntax.

Let me know, if that fixes it for you!