Displaying relationship titles instead of IDs in collection list view
I swear I saw this at some point, if there some standard way to replace the id with the title for relationship columns in the list view?
For me, it works out of the box if I use the
admin.useAsTitleoption when defining collections
@ssyberg do you have a minimal reproduction collection you can share?
Would like to look into this!
(assuming it works in the document view itself and that you didn't forget the
admin.useAsTitleoption)
Yup
useAsTitleis working fine, in face when I click in to that record it surfaces the title just fine:
fields: [ { type: 'row', fields: [ { name: 'center', type: 'select', required: 'true', options: CENTERS }, { name: 'references', type: "relationship", relationTo: ["posts", "papers", "reports", "in-the-media",], maxDepth: 1, }, ] },
and it doesn't work in the list view?
Right! Sorry I should have clarified,
useAsTitleis working fine on the related model itself
lemmme see if I can replicate it
This might be relevant, the
useAsTitleis being set in a plugin
(I've written a plugin to enable "base collections")
Maybe! At least the code snippet you shared works perfectly fine in the list view - just tested that.
Would help a lot if you can figure out a minimal reproduction and publish that one
Fascinating
I could swear I've encountered a similar problem once where it didn't show the name in the list view - not quite sure anymore. But it really might just happen for some more complex edge cases
I'm gonna bypass the base collection and set useAsTitle directly
what exactly is a base collection?
Essentially I've added inheritance to payload
Allows you to set default fields/configs either on all collections or specify specific collections to inherit from
Here's my base collection that ALL collections extend (except those specified in a an exclude option in the plugin):
import Title from "@fields/Title"; import Slug from "@fields/Slug"; const Base = { versions: { drafts: true, }, access: { read: () => true, }, fields: [Title, Slug], }; export default Base;The plugin is written in such a way that the actual collections can also overrride these values
Interesting, looking at the network response and the title is not making its way back to the list view
oh interesting - sounds quite useful! And so, the useAsTitle is specified in one of the collections from which it inherits it, and not in the "real" collection?
Correct
Though I moved it back in to the real collection and it had no effect
Interestingly
http://localhost:3000/cms/api/posts/returns the title
But add this where clause and it disappears
http://localhost:3000/cms/api/posts?depth=0&where%5Bid%5D%5Bin%5D%5B0%5D=64273bfb93fa4750d7ff70cb&locale=en&limit=250Oh maybe it's locale related?
That's it
http://localhost:3000/cms/api/posts?locale=enand
titledisappears
Maybe try your local example again with locales enabled?
Is field-level localization enabled on the title field
Yes
Wait a minute
I don't have an
enlocale
where is that coming from haha
lolol reproduced it! Most definitely a bug
- http://localhost:3000/cms/api/posts?depth=0&where%5Bid%5D%5Bin%5D%5B0%5D=64273bfb93fa4750d7ff70cb&locale=English&limit=250
That works
"en" must be hardcoded somewhere?
hah seems so! The moment I add a translation for en, it works
doesnt even seem to be the default locale
just does it for "en"
ha
If you want to I can open a payload issue for you, since I just made a repro. Or, would you like to do it?
well seems like it'll be an easy fix!
My kids about to wake up from a nap so I probably wont get to it till tomorrow, so feel free!
Thanks for the help!
Sure thing, you're welcome! Might take a look tomorrow myself to try and figure out a fix
Could be this
https://github.com/payloadcms/payload/blob/3825041393f2f8228a77a7ca91f031138531fb11/src/admin/components/views/collections/List/RelationshipProvider/index.tsx#L53Which kinda makes sense but it assume parity across locales and i18n
@ssyberg Indeed - another issue was that the relationship Cells weren't refreshed in the first place when you change the locale
https://github.com/payloadcms/payload/pull/2438this PR should fix it ^^
Oh nice find!
I am just getting caught up on this thread. I don't know if this is a bug though.
The change you made is originally how I was treating the locale to fetch in the
relationshipsProvider. Then this issue was opened and we intentially made the provider use the admin UI i18n setting.
https://github.com/payloadcms/payload/pull/1648I'm not sure the best way forward TBH.
huh why would you prefer using i18n there instead of locale? Locale would reflect more what this relationship
actuallypoints to
Agreed, I think it needs to reflect the chosen locale
I think i18n is best to use only for things completely unrelated to the data behind it
Yea I think I fundamentally disagree with this:
Relationship labels with titles should take into account the admin user's i18n language setting.
As I've already stated, it assumes parity between i18n locales and localization locales and this parity is not otherwise documented that I'm aware of
Also if the relations
useAsTitlefield is localized, it really seems like it should return the currently selected
localeregardless of the admin users language settings
putting this link here so I can actually open it on my phone
https://discord.com/channels/967097582721572934/1049367843495481464that discord conversation is leaving me confused
it doesn't quite explain the change from locale to i18n. The author was always talking about an issue with localization and not i18n
looking at the PR it seems that originally, both the locale and i18n were completely disregarded weren't they?
Hey @ssyberg , out of curiosity, is there a trick I don't know about to get nice clean locale names like you have here (maybe even localized), or is that just the actual locales you defined in your config, ie:
localization: { locales: [ 'Arabic', 'Cyrillic', 'Hindi', 'Chinese', ], ...@tinouti that's just default Payload behavior AFAIK!
So I take it it was the latter (ie: your config file looks like what I put in that code snippet)? No secret tip on how to get nice labels for locales? 😢
I don't think so...
It would be a trivial enhancement to make locales have the same format as
optionsdo with select or radio fields. We just have to update everywhere in the code that uses locales to get the values out and then instead of
locales: ['en', 'es']you'd have
locales: [{ value: 'en', label: 'English'}, { value: 'es', label: 'español' }]. Then the UI can use the nice label.
And make it a nonbreaking change of course.
If anyone is interested in opening a PR for this, we'd be happy to take it.
If @alessiogr the PR vigilante doesn't get to it first, I might give it a try this weekend 😄 👍
Feel free hah, don't have enough time for yet another project sadly 😦
@dribbens would you have any pointers/tips on where/what I should be looking for to get started on this? I've tried poking around in the source, but I don't have a solid grasp on how Payload works under the hood yet so it's been a bit overwhelming. I'd probably start with wherever the config's getting parsed / Payload's getting initialized? 🤔
I was hoping that @jmikrut's "How Payload works" video (
https://discord.com/channels/967097582721572934/1102950643259424828/1102990277502840852👀) was gonna come out and would give me the necessary knowledge and confidence to get started, but given how busy you all are, I realize now that this might not come anytime soon. 😂
Oh shit, looks like someone might have already done it 😮
https://github.com/payloadcms/payload/commit/c86a9677ec4a03a256e55b5d68a4fab79dfe1523
Continue the discussion in Discord
Star
Discord
online
Get help straight from the Payload team with an Enterprise License.