@LakmaliRD 

Hi  @tofuse,

Looks like a defect for me - what are your thoughts?

It seems that you have not specify what it is you do with the list and what it is that you mean with “does not work”

Short answer

The absence of the datasource attribute on groups is not a defect. A group can not be populated with an array (multiple records). It has to be bound to either a selector, singleton or list that provides only one record. 

Long answer

Basically, there are some main usages for a Custom Entity (Custom LU)

Stand Alone

A customer wants to collect and store information about something that is unrelated to other application data. Let say this is a list of office equipment. A custom entity is created together with a custom page. With this the customer can use the page to enter equipment.

Reference

A custom entity may hold information that you want to connect to another entity as a reference. From above we assume that the customer wants to connect a person in the application to a specific item from the office equipment entity. To do this a custom attribute is added to the standard person entity. This attribute is of type reference and references the custom entity. This custom attribute is then placed on the person page from the person entity.

In this case the equipment must be created elsewhere. The reference attribute can’t be used to create an equipment record when creating or editing a person.

Association

In the situation where you want a parent - detail relationship 1-n, then you create an association between entities. In this case the equipment entity needs a key to associate against. Let’s add a person_id to the equipment LU above.

1. Then we create a projection configuration for the person projection.

2. Add the equipment entity to the projection

3. Add an association between the person and equipment entities

4. Add a key mapping to map person_id between the two.

Here is the answer to your question. An association results in a 1-n relation and is typically only supported by a selector, list or singleton.

A list can be used to display the data either bound or unbound to the parent.

Unbound

1. Add a list to a page configuration for the equipment entity.

2. Add a reference to the list from the person page content

3. Set list reference data source attribute to point to your equipment entity set.

This list is now unbound and will populate all equipment records into the list regardless of which person is displayed. I.e., all existing equipment is shown for all persons. If the equipment entity is added to the person projection with full CRUD support. This list can be used to add, edit, and remove equipment.

Bound

1. Create a list same as above.

2. Instead of adding a data source, create a binding

3. In the binding expand optional attributes

4. For bind name select the main selector “personSelector” used on the page.

5. For property select your person-equipment association

This list is bound to the person on the page. Only equipment that is created for a specific person will be shown on that person.

Groups

A group is a single record object and can only be bound to something that provides a single record. Selector, List, Singleton. So, if you want to show equipment on the person page as a group of fields you need to decide if it is a 1-1 or a 1-n relation that you’re after.

In a 1-n relation the associated custom entity equipment is the right way to go but the group must be fronted with a single record provider as the group can only show data for one record at a time. Page Designer does not support creations of singletons (they don’t make much sense here anyway). So, it boils down to a secondary selector or a list.

1-1 If the intention is that equipment in this case is a 1-1 data directly connected to one person. Then the custom entity is not right to begin with. In this case you should add the equipment attributes as custom attributes directly to the person entity. Then you create a group of fields on the person page where you display these attribute values.

Note: Current schema is not enabling CrudActions to be added to a selector. This means that currently it is not possible to bind a group to a selector for anything other than readonly data. Enabling this is something that we decided to add as a future enhancement and will be available in coming release. 

One of our customer who is upgrading from Apps to IFS Cloud is facing the same issue. They have some tabs with forms and now they are forced to create lists, they feel this as a drawback or bug. Any plans to resolve it in near future?

This is now possible in IFS Cloud 23R2.

1. Open Page Designer and Create a new Singleton.

   

2. Connect it to your custom entity.

   

3. Add the required Crudactions 

   

4. Create a group which is connected to the custom entity.

   

5. Create/Go to the tab you want to add the group and add the singleton first.

   

   

   

6. Expand the properties of the singleton to bind it to the parent entity. Make sure to create an association in Projection Configuration to create the relationship between the parent and the custom entity.    
   1. Binding should be the main selector/list of the parent entity.In my case it is the main page selector.
   2. Property should be the association you’ve created in Projection Configuration. It will automatically list all the valid properties once you select a binding.

7. 

   

   

   Add the group to the tab

   

8. Expand the group properties and connect it to the singleton.

   

    

9. That’s it! There will be separate action buttons inside the tab to insert/update/delete records.

   

   

   

    

Yes, support for one-to-one associations have been added. Please see user documentation at https://docs.ifs.com/techdocs/23r2/040_tailoring/225_configuration/200_client_configurations/250_entity_configurations/master_detail_relationships/#one-to-one_detail_view