Not all relations are included in the Relationship Field options

[dylanmeivis]

Link to reproduction

https://github.com/dylanmeivis/payload/tree/dylanmeivis-relationbug-repro

Describe the Bug

I have a collection that references another collection with the type relationship. I have quite some entries in the collection so I want to be able to search for it and find it while creating the collection that references the relationship.

The amount of options that are listed in the select is not consistent sometimes I get 10 sometimes 37 or 67.

I would want to have all the options in the list or be able to search for every option, and not only the ones in the list that is currently loaded.

To Reproduce

Clone the reproduction, and run pnpm install and then pnpm dev _community Create a .env file and add the following secrets:

PAYLOAD_DATABASE=postgres
POSTGRES_URL={the postgres url you are working against}

open the admin url on https://localhost:3000/admin and navigate to http://localhost:3000/admin/collections/players. Try to create an new player and in the history the relationship field is labeled as issue.

The related collection has 100 entries starting at 0 all the way to 99. Try to search for one and see that not all of them are included.

update

Also when you have only one relationTo and you start with searching then after looking at the results remove the search. The fetch next page on scroll to bottom does not work it never fetches the next page.

Payload Version

2.12.1

Adapters and Plugins

dp-postgres

[dylanmeivis]

The issue of not fetching new results onMenuScrollToBottom when the search is wiped was I think caused by the lastFullyLoadedRelation that was not set properly.

It uses

relations.indexOf(relation)

which returns 0 if there is only 1 relation in the relations array, but used -1 in all other scenarios. I pushed my proposed fix to this on this branch, you can see it here.

Happy to get feedback or open a separate PR for this when needed.

In the meantime I will investigate further why not all results are returned when searching.

[dylanmeivis]

I am using a virtual field as the admin.useAsTitle which is set up in a way that it's not stored in the database.

Since the fieldToSearch is constructed like this

let fieldToSearch = collection?.defaultSort || collection?.admin?.useAsTitle || 'id'

it uses my virtual field as the fieldToSearch which will fail because that's not stored in the database, so filtering on it will always return nothing.

TLDR When you use a virtual field for admin.useAsTitle you need to specifically set the defaultSort on the collection level to a field that is actually stored in the database.

[DanRibbens]

If you need to sort by a field then don't make virtual, let that data get written and use it.

I don't think there is much we can do here. If you were expecting more validation on your config to avoid this bug in your project, I can accept that as a good feature idea, but I don't know how we would accomplish it since the only thing making a field virtual or not is your own beforeChange hook.

I'm going to close this, but feel free to @ me to have it reopened if you think I've missed anything.

[dylanmeivis]

@DanRibbens I completely agree on the sorting part, that's why I put my TLDR for anyone that would ever stumble across this case. It's good to know the sorting order.

Could you still checkout the case when you have only one relationTo and you start with searching then after looking at the results remove the search. The fetch next page on scroll to bottom does not work it never fetches the next page.

from quoting my previous comment:

The issue of not fetching new results onMenuScrollToBottom when the search is wiped was I think caused by the lastFullyLoadedRelation that was not set properly.

It uses

relations.indexOf(relation)

which returns 0 if there is only 1 relation in the relations array, but used -1 in all other scenarios. I pushed my proposed fix to this on this branch, you can see it here.

Happy to get feedback or open a separate PR for this when needed.

In the meantime I will investigate further why not all results are returned when searching.

I think that's still a bug and see attached possible fix for it. If you don't think it's a bug when can happily leave this as closed 😄

[DanRibbens]

Oh yeah, we'll look at clearing the search to make sure that behaves correctly. I think I've noticed that before myself.