[Access] Paths cannot be queried

[KomlevDm]

Link to reproduction

https://github.com/KomlevDm/payload/tree/access-query-issue

To Reproduce

1. go to test/_community/collections/Media/index.ts
2. add query to MediaCollection.access.read (test/_community/collections/Media/prod.ts and test/_community/collections/Media/published.ts)
3. start dev server
4. open http://localhost:3000/admin/collections/media
5. page is broken
6. get error The following paths cannot be queried: _prod, _prod, _status, _status

link in test repo

Describe the Bug

Our team has migrated from 1.6.32 to 1.7.4 version. And now we get a global problem (400 Bad Request) in admin panel: The following paths cannot be queried. We think it's related to feat: refactors buildQuery to rely on fields instead of mongoose (d187b809d) in 1.7.0 release. Something very similar was here, but unfortunately it doesn’t fix current issue.

Payload Version

1.7.4

[jmikrut]

Hey @KomlevDm — I can shine some light here for you.

Basically, we have implemented query validation, among other things. Your reproduction repo attempts to query on fields that do not exist in your schema.

I assume you are injecting fields with Mongoose directly or similar, but those fields are not reflected in your Payload collection config(s).

To fix this, you need to make sure that you have fields that reflect anything that you query on. If you don't want them to show up in the admin UI, but you want them to be available to query on, you can set these fields to admin.disabled to hide them entirely from admin UI, but then your queries will once again work.

Regarding the _status field, same thing there - your Media collection does not have versions.drafts: true, so you have no _status field, and thus can't query on that field.

I will convert this to a discussion because everything is functioning as-intended, but I am happy to continue helping!

[KomlevDm]

We implemented the addition of this field through the plugin and hooks, and apparently the payload does not know about it, as I understood from the answer above.

[jmikrut]

Any fields you add with a plugin are completely respected with our query validation. But the problem is, is that field is hidden. Change it to disabled instead of hidden and you will then be able to query on it!

The reason why we are now restricting hidden fields from being queried on is because that could actually pose as a security vulnerability. More info here:

GHSA-35jj-vqcf-f2jf

[DanRibbens]

Hold up, admin.hidden is not the same as hidden on the field.

@jmikrut the code example is using admin.hidden and that shouldn't make any difference for querying.

[KomlevDm]

Thank you for explaining the reason for creating a validation - here I agree and will look towards disabled.

But about question on the _status for work with drafts.
That is, now there is no way to check any document when requesting for the presence of a field (_status) if the collection does not have versioning. It's just that our media collection does not have versioning and there are some other collections that do not need buttons (Save Draft and Publish changes) that come with versioning. Can we somehow check all this at one point in the plugin (as in version 1.6.32 before validation)?

[KomlevDm]

Guys, I re-read everything you wrote and what I could find in the Issues, PRs etc (1, 2, 3, 4). Here is the result:

1. Use hidden property for group field (based on the docs and PR, that will still be saved to the database, but will not appear in any API or the Admin panel)
   
   

2. Explicitly add the configuration of this group field to all collections in the plugin (due to the appearance of validation from version 1.7.0)

3. I have not yet been able to solve the issue with the _status field, I continue to believe that the current implementation through versioning is not exactly elegant. For example, media or other collections that do not need versioning in the app should simply be able to allow access based on the absence of _status field. As I see that in order for the old logic (which, by the way, was in the docs) to work, the _status field will also need to be explicitly set for all collection configurations. And it would be great to be able to do it easier, because the payload can work with versioning out of box and it seems redundant to add a separate field (e.g isPublic, etc.).
   

But I still have to add afterRead hook to remove the field object completely, because it still leaks, even though hidden:

The same problem now appears in the case of a document that did not need a field before, but now it has it in the configuration and it gets into the db as a vestige of an empty object:

But for an access query, this is solved strangely, but probably logically:

    {
      _preProd: {
        equals: {},
      },
    }

[thgh]

I had the same issue, it turned out to be related to a relationship field that had a read access function that returned an invalid query.

The error details are quite limited though.

[ccssmnn]

Thank you @thgh ! Your hint to the access function pointed me to the right direction.

I had the same issue. In my case, the access function returned a filter that included a condition on the user field. But the collection did not have a user field.

[17:09:46] ERROR (payload): QueryError: The following path cannot be queried: user
    at validateQueryPaths (/myproject/node_modules/payload/src/database/queryValidation/validateQueryPaths.ts:91:13)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async find (/myproject/node_modules/payload/src/collections/operations/find.ts:138:7)
    at async getEntityDoc (/myproject/node_modules/payload/src/utilities/getEntityPolicies.ts:58:32)
    at async createAccessPromise (/myproject/node_modules/payload/src/utilities/getEntityPolicies.ts:119:40)
    at async /myproject/node_modules/payload/src/utilities/getEntityPolicies.ts:245:5
    at async /myproject/node_modules/payload/src/utilities/getEntityPolicies.ts:228:5
    at async /myproject/node_modules/payload/src/utilities/getEntityPolicies.ts:228:5
    at async getEntityPolicies (/myproject/node_modules/payload/src/utilities/getEntityPolicies.ts:227:3)
    at async docAccess (/myproject/node_modules/payload/src/collections/operations/docAccess.ts:43:20)