Request — Display relational field in the list view

[Aurelsicoko]

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

Link to the roadmap

Motivations

The list view of the Content Manager doesn't display the relational fields. It only displays simple fields (text, number, boolean, etc) and media.

For instance, when you look for all the blog posts written by a specific user you can't. You have to go to the details page to know the author of the blog post.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Don't forget to solve the issue whatever the kind of relationships.
  In other words, the list view must handle one-way, one-to-one, one-to-many, many-to-one, and many-to-many relationships.
• Maintain high visibility and readability. It means as we did with the media field, we might have to only display information using the hover behavior.

[derrickmehaffy]

Linked to: #8

[alexey-yunoshev]

I am willing to try and co-develop this feature. If it’s okay, here are a couple of thoughts and questions:

1. I suppose it is only going to work for relations that have One on at least one of the sides. Also, this field can be displayed only if the related entity is on the One side. For example, say, one school has many students, and many students belong to one school. Then if we look at the schools table, we can’t have students column (the Many side), but if look at students table, then we can have school column (the One side). Does it make sense?
2. I believe the display value should be computed, so we should be able to specify a function somewhere that will accept an entity with all its properties and return an arbitrary string. What do you think and would it make sense to add getDisplayValue function to entity service?
3. Any general advice and directions on how this feature should be designed and implemented?

[derrickmehaffy]

@Aurelsicoko @sam-pires @JabStrapi 😃

[khalidzamer]

being able to introduce relations into the filter like other displayable columns will be awesome

[siepmannj]

... Then if we look at the schools table, we can’t have students column (the Many side), but if look at students table, then we can have school column (the One side). Does it make sense?...

I think a link there to the corresponding 'students' of a school, aka students filtered by school to view and edit would be awesome.

2. I believe the display value should be computed, so we should be able to specify a function somewhere that will accept an entity with all its properties and return an arbitrary string. What do you think and would it make sense to add getDisplayValue function to entity service?

Do you mean something like str methods in django models?

3. Any general advice and directions on how this feature should be designed and implemented?

[alexey-yunoshev]

@siepmannj

I think a link there to the corresponding 'students' of a school, aka students filtered by school to view and edit would be awesome.

I like the idea

Do you mean something like str methods in django models?

I'm not sure. I haven't used django. What I ended up doing is storing methods in the global strapi object in browser. So I actually have done this thing, as well as filtering, but I had very little time so the code is quite a mess and it doesn't work for every use case. Here's what it looks like though https://youtu.be/wjgQtfbMncg

[zgualberto]

Here's my work around on this limitation

I got the same problem displaying category type on list view of my article collection.

I created a read-only field on article collection then when the user selects a category, I will then save the name of category to the read-only field.

Finally, you can display that read-only field on the list view.

Hope it helps.

This solution is inspired by this link

*Sorry for my bad english.

[alterx]

@alexey-yunoshev do you happen to have the code you implemented publicly available? I could definitely use the filtering part

[mryechkin]

@alexey-yunoshev I would love to see the code for that as well, if possible!

[sam-pires]

Hello everyone

We have been working on this feature with the team and I wanted to let you know what we plan.

For those I haven’t met yet, I am Samuel, product manager at Strapi. I joined the team a couple of months ago.

Before giving you an overview of the feature, I just would like to let you know that for the next features we all want to better collaborate with contributors and members of the community.

Even if we haven’t discussed this feature with you here in this RFC, your feedback and input have been really valuable and helped us work on it.

We’ll also communicate more broadly on features development to explain our choices, our constraints, and our vision. The goal is always the same, making Strapi always better and share as much info as possible with the community to help you implement it the best way possible, work with it, and contribute to it.

It is a bit long and heavy, feel free if you have any question or want me to clarify a point 🙂

[sam-pires]

Here we go!

We have started working on the display of relational fields after the Draft&Published feature’s development began.
Relational Fields (RF) is a widely expected feature, we started with some inputs from this RFC, from frequent feedback on Slack and different channels, and with almost 300 feedback shared on our roadmap.
I have to say it is so great to have so much material to start working on a topic! So thank you all for the info and ideas you shared!

With Maeva, product designer, we still needed to understand what admin panel users are trying to achieve through list views in general (not only through the display of RF), why do they need to have more info there, which info, which actions, etc.
It might seem trivial, people want to have more info to better understand, identify, and manage their content from the list views, but which information do they really need? and why? is it to save time? To be able to create custom list views for specific roles? etc. i
So many questions it is important to ask to make the right choices for the long run. But in the end, it is always worth spending time on it.

We conducted several user interviews and could test some early-solutions prototypes.

I’ll share more info later in a blog post about what we learned during this research but here is a quick overview of the feature so you know what to expect, and we can discuss it.

Here is what we decided to implement in this first version of the feature:
The possibility to display relational fields (RF) in the list view
The way we display them will vary depending on the type of relationship (x-to-one vs x-to-many)
Filtering and sorting by RF

As you said here in this RFC, we can’t manage x-to-many relations values the same way we do for x-to-one values. The tables wouldn’t scale well if you have 30 values in a cell. So we are going to manage them differently.
For x-to-one, we have 0 or 1 value, thus will display the value as it is today.
For x-to-many, we have between 0 and 100+ values, so we will display a counter with the total number of values. We also add a tooltip that will display a preview of a limited number of values (limited to 10 values for performance reasons, or less if the tooltip’s max-height is reached)

It will be possible to display one field by relation.

The users will be able to select the relations they want to display in the list views but the corresponding relational field will be automatically synced with the one set as « Entry title » in the Edit view settings.
A user will see the same relational fields in the List view and Edit view.

Even though this choice can limit customization in the List view, our research showed that List views and Edit views go together and need to have coherence. That is the choice we made: coherence of the information on both views > customization of the List view.

As we sync with the field selection with the Edit view, the same restrictions automatically apply: it won’t be possible for the moment to display components, dynamic zones, and polymorph fields

Displaying relational fields means adding more columns to the tables, with Draft&Published and later Internationalization (18n), more and more columns will be added too, which means a higher probability of having narrow columns and cropped cells. So until we adapt our tables to scale, we decided to add tooltips to cells where the content is cropped. This will allow the users to view the content of a cell even when cropped.

Now about sorting, searching, and filtering.
For the moment, sorting will be available on x-to-one relations. We are still not sure it would be useful to sort on the counters of x-to-many relations, we’ll see if we make it available later.

Searching on relations would be too harmful to performance, so we decided to not make it available for the moment. One solution we have in mind for later would be to create an integration with dedicated search tools (Algolia, Elastic, etc.) to make the search in the Admin works well at this level, though we won’t be working on it soon.

About filtering, we use deep filtering on relations, though we decided to limit it to the “Entry title” field of each relation. To make deep filtering available for all fields of a relational requires us to improve the filter UI/UX to accept one more input (relation and field and not only field).
It won’t be possible to filter by components, dynamic zones, and polymorph fields (such as media).

We’ll keep improving this feature regularly, and we identified several areas and features we’ll have to improve in the near future regarding relations and views 💪

Let us know what you think!

[alexey-yunoshev]

@alterx @mryechkin The code I wrote is a part of a private repo, and it would take a lot of time to extract it, which I unfortunately don't have right now. But from the messages above, the official solution is coming, so I wouldn't bother building anything custom that is so deeply integrated, because in the future it might make it more difficult to update to a new version of Strapi.

[jankallewulf]

Hi @sam-pires do you already have any feelings on when you might release this?

[sam-pires]

Hello @jankallewulf,
The development will be done by the end of the month and a release will make it available in December.
I will keep you posted here about the progress 🙂

[mryechkin]

@sam-pires thanks for the details and keeping us up to date! Looking forward to having this feature available :)

[jerodfritz]

looking forward to this. thank you @sam-pires and team

[sam-pires]

Hello everyone,

Quick update as promised, we are still aligned with the previous message 🙂
Development in progress, the feature will be available in December.
Quick note, we did some refactoring on the Content Manager to be able to implement the feature as we wanted.

Have a good morning/day/evening!

[jerodfritz]

Do you envision bringing this type of relational field display for component interfaces as well?

For example this component has a relational field and it would nice to be able to list the Property title in this view as it is now we just use the ID in the UI which is not very helpful without expanding the element:

[sam-pires]

humm 🤔
@centogram I DM'ed you on Slack to discuss that and not spam this thread. I am curious to know how you ended up with IDs there!

[sam-pires]

So after we discussed that, I can confirm that we don't improve that behavior in the upcoming feature, but we'll definitely have a look at it!

[adamrhunter]

Do you envision bringing this type of relational field display for component interfaces as well?

For example this component has a relational field and it would nice to be able to list the Property title in this view as it is now we just use the ID in the UI which is not very helpful without expanding the element:

@centogram - What approach did you use to show the the list of related ids in the center panel?

[jerodfritz]

Do you envision bringing this type of relational field display for component interfaces as well?
For example this component has a relational field and it would nice to be able to list the Property title in this view as it is now we just use the ID in the UI which is not very helpful without expanding the element:

@centogram - What approach did you use to show the the list of related ids in the center panel?

[jankallewulf]

Hi @sam-pires, hope you are doing well! As the feature is still in development and not yet in testing, would it be a fair assumption that the feature will come more like a Christmas present and a release within the first half of December is unlikely?

[derrickmehaffy]

Hi @sam-pires, hope you are doing well! As the feature is still in development and not yet in testing, would it be a fair assumption that the feature will come more like a Christmas present and a release within the first half of December is unlikely?

👀 🎁 I'll let Sam answer 😉

[sam-pires]

Hello @jankallewulf,

I'm doing well, thanks 👍 , hope you too!

Indeed expect the stable version of the next release around Dec 15th.

The "exact" schedule we have in mind is:

• releasing an "experimental" version of the feature early next week to start testing it, with Strapi team members (at large) and community members (that would be awesome if you all in this RFC could participate!! I'll share it with you here when released)
• A beta a couple of days later
• During week of Dec 14th release the stable version

[sam-pires]

Hello Hello 🔥

Good news everyone we released the beta for Strapi 3.4 which includes Relational Fields!
(we decided to skip the experimental and go directly to a beta 🙂 )

You'll find more info on the forum https://forum.strapi.io/t/new-beta-release-strapi-v3-4-0

Please test it in your conditions with your usual workflow and data if possible (⚠️ but never in production ⚠️) and let us know how it goes.

The doc and detailed changelog will be available later, so it's gonna be a bit of a discovery haha. I listed some features in the post on the Forum though, that should help.

Give us as much feedback as possible, if it's good, bad, not-intuitive, buggy, the best experience of a software you ever had... share it on the forum or here or through Github issues so we can take them into account and improve it for the stable 💪

Thanks everyone, I hope you'll like it!

[jankallewulf]

Hi @sam-pires, just downloaded and tested it. Works perfectly. For the next release I would prefer to have also a visual representation (like suggested here: strapi/strapi#6329) to make it easier to immediately see the connection between the content items. Nevertheless, great work and I'm extremely looking forward to updating to the stable release hopefully soon

[derrickmehaffy]

Hi all

Strapi v3.4.0 was released today:
https://github.com/strapi/strapi/releases/tag/v3.4.0
https://strapi.io/documentation/developer-docs/latest/migration-guide/migration-guide-3.3.x-to-3.4.0.html

@alexandrebodin / @sam-pires I'll let you guys close out the issue.

[alexandrebodin]

Closing this RFC as the first version was implemented. You can now go to the forum to give us your feedback 🎉 https://forum.strapi.io/t/new-release-strapi-v3-4-0-with-relational-fields-in-list-view/1689

[sam-pires]

Thanks everyone for your involvement in this feature! 👍 It is great to have such an active community and to be able to interact with you directly!

I am looking forward the next RFC we'll work into a feature.