Add a way to specify a different field for relationships other than the useAsTitle property

[DanRibbens]

The relationship field selector relies on the admin.useAsTitle property to specify which field value to use in the label of the options shown in the dropdown menu.

In some cases you might want a different value to be used in the selector than what is used for the title on the edit view. Currently there is no way to control this.

Proposed Solution

Add a new collection property called admin.useAsRelationshipTitle which works similarly to admin.useAsTitle but is used only in the relationship select options. The fallback logic for this should be use useAsRelationshipTitle, then useAsTitle, and finally fallback to the document id.

This property would also need to be used in the where query used to search for relationships to add.

[spencerxl]

Could this be solved more flexibly by specifying which fields are returned in the relationship field selector - i.e. adding "fields" and "label" options to the relationship field selector itself, rather than defining useAsRelationshipTitle on the collection?

This could:

1. give the option to make the additional returned fields available in siblingData (for more powerful conditional rendering, or dynamic Group headings, for example),
2. keep the relationTo logic encapsulated in the relationship field, and
3. allow flexibility of use (e.g. having two relationship fields pointing to the same collection, but with different labels and/or data returned)

[DanRibbens]

I can get on board with that @spencerxl!

I considered this while writing the discussion. If I understand correctly, what you're suggesting is a way to set the property for each relationTo defined in a relationship field. The part I'm unsure of here is that it makes this somewhat more complicated to define in the config and our current types for relationTo doesn't allow you to specify properties for each collection. The trick here is that polymorphic relationships work very differently than single relationships and we need to continue to logically separate the two while still allowing extra properties to be added.

Is this what you're suggesting?

relationTo: string | string[] // current
// Alternative 1: 
  | Record<string, { useAsLabel, /* other properties in the future */ }>
// Alternative 2:
  | { slug: string, useAsLabel: string }

We have a similar pattern in the definition of filterOptions on a relationTo that is polymorphic, but because that is a function we were able to just pass the relationTo dynamically so the function can be written to switch on the property for collection specifics.

[franciscolourenco]

@DanRibbens A function that receives the document and returns the title would work equally well in our case and be even more flexible.

[foxted]

I've have faced this use case today.

Use Case

I have three collections: Modules, Chapters and Pages, with the following relationships:

• Modules can have many Chapters
• Chapters can have multiple Pages
• A Chapter belongs to one and only one Module
• A Page belongs to one and only one Chapter

Chapter titles are unique within the same Module, Page titles are unique within the same Chapter.

When selecting the Chapter while editing a Page, only the Chapter title is shown, which makes it hard for users to pick the right chapter (for example, each Module has an "Introduction", so they don't know which one to pick.

Current Solution

I managed to create a field on my Chapter collection, called optionTitle, with the following config:

{
      type: 'text',
      name: 'optionTitle',
      label: 'Option Title',
      required: false,
      hooks: {
        beforeChange: [() => null],
        afterRead: [
          async ({ data, req: { payload }, ...rest }) => {
            const mod = await payload.findByID({
              collection: ModulesSlug,
              id: data?.module,
              depth: 0,
            });

            if (mod) {
              return `${data?.title} - Module: ${mod?.title}`;
            }

            return data?.title;
          },
        ],
      },
      admin: {
        position: 'sidebar',
        readOnly: true,
        hidden: true,
        disableListColumn: true,
        disableListFilter: true,
      },
    },

Which would return a title like so: Introduction - Module X. I can now use useAsTitle: 'optionTitle', but now when editing my Chapters, the title is also Introduction - Module X.

Ideal Solution

The ability to set a custom title for the Relationship dropdown, would solve my issue, so I could display dropdown options like this:

Chapters
   Introduction - Module 1
   Introduction - Module 2

A groupBy config would also be nice, to be able to display the options like this:

Chapters
   Module 1
      Introduction
   Module 2
     Introduction

Possible Implementations

useAsTitle on relationship field

For custom titles, we could allow setting useAsTitle directly on the relationship field, like this:

{
      name: 'chapter',
      label: 'Chapter',
      type: 'relationship',
      relationTo: ChaptersSlug,
      hasMany: false,
      required: true,
      admin: {
        useAsTitle: 'optionTitle'
      },
    },

Which could also be a function that would receive the doc and the context, so we could potentially customize it further/dynamically:

{
      name: 'chapter',
      label: 'Chapter',
      type: 'relationship',
      relationTo: ChaptersSlug,
      hasMany: false,
      required: true,
      admin: {
           useAsTitle({ data }) {
               // Fetch module from Payload API
               const mod = await payload.findById({
                   collection: 'modules',
                   id: data.module
               })
               return `${data.optionTitle} - ${mod.title}`
           }
      },
    },

Group by option

For the extra ability to groupBy a field on the relationship, we could allow something like this:

{
      name: 'chapter',
      label: 'Chapter',
      type: 'relationship',
      relationTo: ChaptersSlug,
      hasMany: false,
      required: true,
      admin: {
           groupBy: 'module.title'
      },
    },

Benefits

• Easy to setup and use
• No need to reach for a custom component
• Allow the use of useAsTitle for the display title of the collection in the UI, while providing a better option label when the items are displayed in a relationship dropdown
• No extra field in the database that would remain empty (which is currently the case with the implementation using the afterRead hook, since virtual fields cannot be used with useAsTitle unless they refer to a relationship field.
• Better UX when interacting with relationship dropdowns

[rilrom]

Would love to see this one worked on soon.

Does anyone know of any current workarounds to handle this in the meantime?

[Madibaworld2024]

News Powered By Market .Your Super Powered Domain Marketplace.Reach our team of domain and website experts available 24/7.DNS Hosting with Dynamic DNS .Managed DNS with anycast DNS,DDoS Protected DNS and GeoDNS . Buy Domain Names with Special Price Reach Out Contact https://wa.me/p/23951598601159917/237681533766

…

On Wed, May 14, 2025, 12:06 PM Valentin Prugnaud ***@***.***> wrote: I've have faced this use case today. Use Case I have three collections: Modules, Chapters and Pages, with the following relationships: - Modules can have many Chapters - Chapters can have multiple Pages - A Chapter belongs to one and only one Module - A Page belongs to one and only one Chapter Chapter titles are unique within the same Module, Page titles are unique within the same Chapter. When selecting the Chapter while editing a Page, only the Chapter title is shown, which makes it hard for users to pick the right chapter (for example, each Module has an "Introduction", so they don't know which one to pick. Current Solution I managed to create a field on my Chapter collection, called optionTitle, with the following config: { type: 'text', name: 'optionTitle', label: 'Option Title', required: false, hooks: { beforeChange: [() => null], afterRead: [ async ({ data, req: { payload }, ...rest }) => { const mod = await payload.findByID({ collection: ModulesSlug, id: data?.module, depth: 0, }); if (mod) { return `${data?.title} - Module: ${mod?.title}`; } return data?.title; }, ], }, admin: { position: 'sidebar', readOnly: true, hidden: true, disableListColumn: true, disableListFilter: true, }, }, Which would return a title like so: Introduction - Module X. I can now use useAsTitle: 'optionTitle', but now when editing my Chapters, the title is also Introduction - Module X. Ideal Solution The ability to set a custom title for the Relationship dropdown, would solve my issue, so I could display dropdown options like this: Chapters Introduction - Module 1 Introduction - Module 2 A groupBy config would also be nice, to be able to display the options like this: Chapters Module 1 Introduction Module 2 Introduction Possible Implementations useAsTitle on relationship field For custom titles, we could allow setting useAsTitle directly on the relationship field, like this: { name: 'chapter', label: 'Chapter', type: 'relationship', relationTo: ChaptersSlug, hasMany: false, required: true, admin: { useAsTitle: 'optionTitle' }, }, Which could also be a function that would receive the doc and the context, so we could potentially customize it further/dynamically: { name: 'chapter', label: 'Chapter', type: 'relationship', relationTo: ChaptersSlug, hasMany: false, required: true, admin: { useAsTitle({ data }) { // Fetch module from Payload API const mod = await payload.findById({ collection: 'modules', id: data.module }) return `${data.optionTitle} - ${mod.title}` } }, }, Group by option For the extra ability to groupBy a field on the relationship, we could allow something like this: { name: 'chapter', label: 'Chapter', type: 'relationship', relationTo: ChaptersSlug, hasMany: false, required: true, admin: { groupBy: 'module.title' }, }, Benefits - Easy to setup and use - No need to reach for a custom component - Allow the use of useAsTitle for the display title of the collection in the UI, while providing a better option label when the items are displayed in a relationship dropdown - No extra field in the database that would remain empty (which is currently the case with the implementation using the afterRead hook, since virtual fields cannot be used with useAsTitle unless they refer to a relationship field. - Better UX when interacting with relationship dropdowns — Reply to this email directly, view it on GitHub <#4956 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BNXK3UDSTBNT5RGLDT5DGPT26MPTXAVCNFSM6AAAAAB5DBM3SSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMJUGM2TQMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>