Entry Title dropdown in Edit View doesn't list fields with relation type

[flaki]

Only normal component fields are offered in the "Configure the view" interface for providing the Entry Title, it is not possible to select relation fields which often contain the descriptive information to distinguish components, and so the editor falls back to the very non-descript "id" attribute of the component.

Looks like this issue has come up before but I don't see any solutions/workarounds shared and while there seem to be attempts to fix this for list views, I haven't found any efforts to improve on the editing experience.

Steps to reproduce the behavior

1. Create a new content type
2. Add a new repeatable component
3. The component should have a relation to another content type (one-way or 1:1 relation to exactly one item)
4. In the content type editor, click "Customize the View"
5. On the Customize screen select "Set the component's layout" under the component with the relation field
6. the "Entry Title" dropdown doesn't offer the relation view (or any fields on the other side of the relation)

Expected behavior
At least normal string fields on the other end of the relation should be selectable (e.g. a person relation should expose person.name as an Entry Title for a component with a person relation).

Screenshots

Only the strapi-generated unique id and the role (string) field can be selected as "Entry Title", but those are not useful, a person.name on the other end of the relation is a descriptive field of the component, the ID is opaque, while role can be the same across instances of the component (or, in this case, even empty for "default" roles).

The people-involved component type:

Code snippets

The people-involved model descriptor:

{
  "collectionName": "components_people_people_involveds",
  "info": {
    "name": "people involved",
    "icon": "user-friends"
  },
  "options": {},
  "attributes": {
    "person": {
      "model": "people"
    },
    "role": {
      "type": "string"
    }
  }
}

The people collection type on the other end of the relation:

{
  "kind": "collectionType",
  "collectionName": "people",
  "info": {
    "name": "People"
  },
  "options": {
    "increments": true,
    "timestamps": true
  },
  "attributes": {
    "name": {
      "type": "string"
    },
    "email": {
      "type": "email"
    },
    "bio": {
      "type": "text"
    },
    "photo": {
      "model": "file",
      "via": "related",
      "allowedTypes": [
        "images",
        "files",
        "videos"
      ],
      "plugin": "upload",
      "required": false
    },
    "identities": {
      "type": "component",
      "repeatable": true,
      "component": "people.identity"
    }
  }
}

System

• Node.js version: v12.18.4
• NPM version: v12.18.4
• Strapi version: 3.1.4
• Database: postgres
• Operating system: Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-26-generic x86_64)

[soupette]

cc/ @sam-pires @maevalienard

[derrickmehaffy]

Tagging as a feature request as the option doesn't exist currently.

[sam-pires]

Hello @flaki
Thanks for the suggestion, it would be a good improvement to Strapi for sure.

We have recently been working on the possibility to display relational fields in the list view (will be released later this year). While working on it we had many discussions regarding relational fields in the list view and in the edit view and what you suggest is definitely where we want to go.
Doing so would mean go a level deeper into relations, which is really powerful and offer so many possibilities to better manage the content.
Currently, implementing it would have a strong negative impact on the performance of the Admin (we have to think of ways to make sure the Admin doesn't get to slow while we request all the fields in components at that depth), and the edit views and list views wouldn't scale well (we want to avoid making navigating through several depths in the content a mess and a long funnel of modals or dropdowns).

This is going to be at the heart of the upcoming works on the publication workflow and content management.
For the moment I'll let the issue here as a feature request, and make sure to check it and contact you when we start working on this area 🙂

[sam-pires]

Of course, anyone is welcome to share ideas and feedback in this thread 👇

[dpickett]

if it helps anyone else that stumbles on this, I was able to find a passable workaround. I effectively cache the value of the related record's "title" in a CachedTitle attribute

Mongoose model customization below:

"use strict";

/**
 * Read the documentation (https://strapi.io/documentation/v3.x/concepts/models.html#lifecycle-hooks)
 * to customize this model
 */

const cacheTitle = async (data, params) => {
  if (data.Category && data.Title) {
    const category = await strapi.query("category").findOne({ id: data.Category });
    const cachedTitle = `${data.Title} (${category.Title})`;
    if (params) {
      params.values.CachedTitle = cachedTitle;
    } else {
      data.CachedTitle = cachedTitle;
    }
  }
};

module.exports = {
  lifecycles: {
    beforeCreate: cacheTitle,
    beforeUpdate: (params, data) => {
      cacheTitle(data, params);
    },
  },
};

You can then Customize the View to render the CachedTitle property in the relationship list.

It's not great because it duplicates the data and violates normalization but it worked for our use case.

[jinqiangg]

Hello @flaki
Thanks for the suggestion, it would be a good improvement to Strapi for sure.

We have recently been working on the possibility to display relational fields in the list view (will be released later this year). While working on it we had many discussions regarding relational fields in the list view and in the edit view and what you suggest is definitely where we want to go.
Doing so would mean go a level deeper into relations, which is really powerful and offer so many possibilities to better manage the content.
Currently, implementing it would have a strong negative impact on the performance of the Admin (we have to think of ways to make sure the Admin doesn't get to slow while we request all the fields in components at that depth), and the edit views and list views wouldn't scale well (we want to avoid making navigating through several depths in the content a mess and a long funnel of modals or dropdowns).

This is going to be at the heart of the upcoming works on the publication workflow and content management.
For the moment I'll let the issue here as a feature request, and make sure to check it and contact you when we start working on this area 🙂

+1, In need of this feature. Will help if we could have some admin panel customization to use the populate method to allow deep child for certain fields.

[aktjerry]

Is this feature available in version v3.5.4?

[carl-st]

Am I missing something or #8733 hasn't really fixed the issue?

[derrickmehaffy]

Is this feature available in version v3.5.4?

Am I missing something or #8733 hasn't really fixed the issue?

That feature is only in the list view, not the edit view.

[derrickmehaffy]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/display-combined-customised-values-of-relationship-type-in-a-dropdown/8685/1

[Irian]

This solves the issue for now until the feature is available natively in strapi: https://forum.strapi.io/t/using-a-relationships-entry-title-as-a-repeatable-components-entry-title/6186

[hungtcs]

This solves the issue for now until the feature is available natively in strapi: https://forum.strapi.io/t/using-a-relationships-entry-title-as-a-repeatable-components-entry-title/6186

Inspired I made some improvements:

1. define mainField in component json file

   {
     "collectionName": "components_common_xxxx",
     "info": {
       "name": "Some Component",
       "icon": "blender-phone"
     },
     "options": {
       "mainField": "user.displayName" // <---- 
     },
     "attributes": {
       "user": {
         "model": "user"
       }
     }
   }    

2. extensions/content-manager/admin/src/components/RepeatableComponent/DraggedItem/utils/select.js

   import { useMemo } from 'react';
   import { get, toString } from 'lodash';
   import { useContentManagerEditViewDataManager } from 'strapi-helper-plugin';
   
   function useSelect({ schema, componentFieldName }) {
     const {
       checkFormErrors,
       modifiedData,
       moveComponentField,
       removeRepeatableField,
       triggerFormValidation,
     } = useContentManagerEditViewDataManager();
   
     // update 1
     // read options.mainField and then fallback settings.mainField
     const mainField = useMemo(
       () => {
         return get(schema, ['options', 'mainField']) || get(schema, ['settings', 'mainField'], 'id');
       },
       [schema]
     );
   
     // update 2
     // mainField need split
     const displayedValue = toString(
       get(modifiedData, [...componentFieldName.split('.'), ...mainField.split('.')], '')
     );
   
     return {
       displayedValue,
       mainField,
       checkFormErrors,
       moveComponentField,
       removeRepeatableField,
       schema,
       triggerFormValidation,
     };
   }
   
   export default useSelect;