Fallback Locale is not taken into account when querying documents

[gycsabesz]

Link to reproduction

https://github.com/gycsabesz/payload-fallback-locale-find-issue

To Reproduce

Clone the test repository and execute integration tests using the below commands.

yarn install
yarn test:int _community

You will see that fallback-locale is not taken into account upon querying document by localized fields.

Describe the Bug

When querying a payload collection by localized field via Local API or REST API, as below, specified fallback locale is not taken into account if the field is not populated in the requested locale.

Given a document with localized field slug, but populated only in the default language (e.g.: hu in our case).

{
  ...
  slug: {
    hu: 'slug-hu',
  }
  ...
}

Current Behaviour: Querying the document by the field in a different (not populated) locale, won't provide any result.

payload.find({
        collection: aCollection,
        locale: 'en',
        fallbackLocale: 'hu',
        where: {
          slug: {
            equals: 'slug-hu',
          }
        }
      })

Expected Behavour: Shouldn't Payload Querying API use the fallback locale in these scenarios?

See the _Community Tests implemented in the linked repository for more details.

Payload Version

1.15.4

[DanRibbens]

Expected Behavour: Shouldn't Payload Querying API use the fallback locale in these scenarios?

Well, no, I'm not sure that this would be expected. If we do something with this it will be a new feature because this isn't a bug as the current way querying was implemented was not made to work the way you're asking.

It may help for me to explain that internal to Payload, querying is done against the database and the result is going to match your conditions without adding fallback locale conditions on your behalf. The way the fallback locale option works is simply a way to populate missing data after a document is found and this is nothing more than a helper.

If we were to attempt to make querying work with fallback locales there would be significant complexity to overcome in how building queries is done in the database adapters.

This change could also have implications on projects that return access control in the form of where queries.

I've converted this to a feature idea instead of an issue for us to better track demand for such a change.

Thank you for reporting, hope this explanation adds clarity into how the API works and maybe we can revisit this in the future.