Wrong placeholder on related search
Link to reproduction
No response
Describe the Bug
Wrong placeholder on related search
Expected placeholder:
Serach by
Name,TypeOrFile Name
To Reproduce
Create two collections and run:
export const DocumentsTypes: CollectionConfig = {
slug: 'documents-types',
admin: {
useAsTitle: 'name',
},
access: {
read: () => true,
},
fields: [
{
name: 'name',
type: 'text',
required: true,
},
],
}
export const Documents: CollectionConfig = {
slug: 'documents',
admin: {
useAsTitle: 'name',
listSearchableFields: ['filename', 'name', 'type.name'],
},
upload: {
staticDir: path.resolve(__dirname, '../../../../documents'),
mimeTypes: ['application/pdf'],
},
access: {
read: () => true,
},
fields: [
{
name: 'type',
type: 'relationship',
relationTo: 'documents-types',
required: true,
},
{
name: 'name',
type: 'text',
required: true,
},
],
}
Payload Version
2.8.2
Adapters and Plugins
No response
I think Payload is not provide searching field value in related document.
However, you cannot query on any field values within the related document. Since we are referencing multiple collections, the field you are querying on may not exist and break the query.
https://payloadcms.com/docs/fields/relationship#querying-and-filtering-polymorphic-relationships
that placeholder is correct because related field value is not provided, so skip presenting.
I think Payload is not provide searching field value in related document.
However, you cannot query on any field values within the related document. Since we are referencing multiple collections, the field you are querying on may not exist and break the query. https://payloadcms.com/docs/fields/relationship#querying-and-filtering-polymorphic-relationships
that placeholder is correct because related field value is not provided, so skip presenting.
provided as well by mongodb
Sorry, I got it wrong. It is working beacause querying on non-polymorphic relationship is working.
But It must be work like new feature.
In the case of polymorphic and nested field in relocation field, there may be a lot of errors, and I think there should be a discussion on how to handle the label.
What is there to think? the table(document/collecction) has a type (eg. type.name, type.anything.field) field, it is indicated in the listSearchableFields, it should be displayed in the placeholder, the errors you mention should be taken care of by the developer.
-- Just take first split by '.' not the last one, or print TypeName
- It can produce a lot of bug because there is many edge cases. This is just working because relationship field in
whereis working. So I think it is not just developing problem.- nested value in relationship field.
- Access denied field in relationship field.
- relationship field in relationship field.
- How about i18n?
- I think it is better to use filter option. I think searching on field in relationship field must be disabled on
listSearchableFields. And if you want to relationship field inlistSearchableFields, It will be New Feature.
Everything you described is of course the case... but still it seems to me that this applies to relational databases as well, however we are discussing a simple thing - this is the value in the placeholder, no matter what the base is, it will be the same in all cases , for example: field.name -> FieldName
As for "i18n", it still does not work correctly or requires additional configuration of the search fields.
I think this request should be categorized as New Feature as we need "additional configuration". The reason I listed the cases is that I need additional configuration for such edge cases.
If this is a bug, I think it is a bug that does not cause errors when the field (ex. type.name ) is put in listSearchableFields.
This issue was automatically closed due to lack of activity. If this issue is still relevant against the latest codebase, please create a new issue.
This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.