No way to query with relation drafts. Relations always return published version.

[snackdex]

Original Issue:
I'm trying to query the REST API for the draft version of a collection document. This returns the draft of the top level collection that I'm querying as expected, however any relationship fields only seem to return published resources. I've tried adding things like [report._status][equals]=draft which just returns an empty array, whereas if I try [report._status][equals]=published it returns the published relations back.

Discord thread

[franciscolourenco]

Maybe fixed by #4784 ?

[DanRibbens]

No, #4784 is changing the search behavoir of the relationship field. It does not change how the documents are returned.

[franciscolourenco]

I misinterpreted the original issue, nvm.

[DanRibbens]

Relationships should be returned with the same draft query as the original doc. Are you saying a query like /api/pages?draft=true wouldn't populate category unless the page's category was already published?

[evelynhathaway]

I think this is a bug then. I do not experience related documents being queried as a draft in REST or GraphQL API.

Problem 1 - Updating an Existing Related Document

I have a Header global that allows me to select a Menu collection document as one of its fields. If I update any of the fields inside of the Menu document, toggling the draft checkbox on /admin/globals/header/api doesn't do anything.

The result in this case is that my website header cannot have a draft navigation menu even though drafts are enabled in the Header global and the Menu collection. If I were to query there Header with limited depth, and then find the Menu by ID, it would work, even though this waterfall isn't practical for GraphQL.

Not a Problem - Updating Which Document is Related

If changing the Menu currently selected, and save the Header, toggling the draft checkbox will reflect the change of the Menu, but still not the draft contents of the newly selected Menu because of the Problem 1.

Problem 2 - Relating a Document that has Never Been Published

If the Menu document in the relationship field doesn't have a published version, it may appear that like Problem 1 doesn't apply. However, the first version will appear regardless of the draft checkbox. This is an artifact of how /api/menus/[id]?draft=false returns this first revision, regardless of it it was a draft. This means that a non-draft API call to the Header or Menu can include draft content (as long as you have access to drafts, I believe), which I could see as problematic for applications where there is a server making privileged requests, and turns draft mode off for guests. Payload CMS could indirectly reveal any draft information from the first version to guests.

Additionally, this doesn't mean that Problem 1's impact is limited to updating existing documents that have been published at one point. If you update the never-before-published Menu, those changes do not appear on the Header API call with draft mode; it will still be the first version.

[evelynhathaway]

Problem 1 appears fixed alongside #4985 with one issue for GraphQL cascading.

Problem 2 appears unfixed.

[jmikrut]

on it

[jmikrut]

@evelynhathaway we looked into this and found a few things:

Because you mentioned you are on a server making privileged requests, you could set overrideAccess: false in any of your Local API calls to respect the access control that you have set on your global / collection. That would make it so that access control is respected even on the server.

We just tested this in scenarios where you do indeed have overrideAccess: false set in a payload.findGlobal or payload.findByID. We also have access control set for the global / collection in question so that un-authenticated users cannot read any documents that are _status: 'draft'.

We are correctly seeing that no matter if there is a published version or not, no documents of _status: 'draft' will be returned from the Payload APIs.

I think that this is a common misconception which I think our docs might have to do a better job of describing, but reading docs with draft=true will only send out newer drafts, if they are available. It has nothing to do with limiting if a draft or a published document is sent out. Might need to honestly rename that parameter at some point.

Preventing people from seeing drafts is a job for access control, and you can force even Payload's Local API to respect your access control with the aforementioned overrideAccess flag.

Does this make any sense? If there is indeed something that is amiss here still, we're happy to keep looking into it!

[evelynhathaway]

@jmikrut Makes total sense to me! We've actually implemented something similar where Next.js has a Payload service account with an API key that cannot access drafts, and our Next.js draft mode uses each user's active Payload session cookie during their specific draft session. We did this so we could allow granular permissions for different kinds of drafts as well as a kind of zero trust mindset for our draft mode. We're also not yet on Payload v3, so we created this behavior for GraphQL since we can't use overrideAccess: false from the local API.

I reported it in this discussion nonetheless since it seemed related to the drafts issue I was having. Since it's intentional and doesn't appear to be related (🎉), I would agree that documentation would be a good way forward.

I can imagine someone could make the mistake of reading the current warning and make the assumption that since they trust their Next.js implementation to toggle on and off drafts (e.g. server components use draft=true when using a token like Next.js suggests), they can give it access to drafts. This is what I meant by privileged; draft=false cannot be used to return only published versions without removing the permission.