Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected Required Field Behavior on Compound Fields when using a Page Layout #13

Open
JodieM opened this issue Nov 28, 2023 · 1 comment

Comments

@JodieM
Copy link

JodieM commented Nov 28, 2023

Expected Behavior

When using a standard page layout...
Eg Lead and Contact only the Last Name is required.

Actual Behavior

All Name fields are required, including Salutation and First Name, plus this includes Middle Name, and Suffix, if they are added as UI Options.

Steps to Reproduce the Problem

  1. Add an Evolve Forms Details section based on Page Layout to Contact or Lead
  2. Edit the Page
  3. Note the fields that are required including Salutation and First Name.

Optionally:

  1. Set the UI Options to include Middle Name and Suffix Fields
  2. Edit the Lead or Contact
  3. Note that all Name fields including Middle Name and Suffix are required.
    2023-11-28_20-15-04

Notes

  • You can not make the Name field not required on a standard page layout.

  • I understand this might just be filed as a Known Issue as the work around would be to create field sections.

  • But as you state the Page Layout is just a series of Field Sections then maybe there is a way to override this and make it behave as standard.

  • The Field Section based on a Field Set with the Name field as the only field works fine and only the Last Name is required.

  • NOTE: Adding a Field Section based on Field Set and then clearing the values from First Name and Middle Name and Salutation still shows the save button, but clicking save does not actually save the new values (this may be a separate ticket).
    2023-11-28_20-28-50

  • For Address it's the opposite, you can not make an Address field required on the Page Layout but you could create a Field Section and make one of the Address fields mandatory, which is cool.

  • I would really like the page layouts to work as standard, because controlling page layouts in only one place is so handy compared to Dynamic Forms.

@mitchspano
Copy link
Collaborator

mitchspano commented Nov 29, 2023

This is interesting...

The problem here arises from how the getRecordUi returns the representation of the field sections.

Take a look at the extractLayoutSectionsFromResponse function - this is where we parse the default page layout into an ordered collection of field sections.

If we add a console.log on the layoutItem as done below,

  extractLayoutSectionsFromResponse(responseData) {
    let result = [];
    for (let key in responseData.layouts[this.objectApiName]) {
      if (key.startsWith(RECORD_TYPE_ID_PREFIX)) {
        for (let section of responseData.layouts[this.objectApiName][key].Full[
          VIEW
        ].sections) {
          let fields = [];
          for (let layoutRow of section.layoutRows) {
            for (let layoutItem of layoutRow.layoutItems) {
              console.log(
                "layoutItem : " + JSON.stringify(layoutItem, null, 2)
              );
              for (let component of layoutItem.layoutComponents) {
                fields.push(
                  this.getFieldStringRepresentation(component, layoutItem)
                );
              }
            }
          }
          let hideHeader = section.useHeading === false;
          let formattedSection = {
            id: section.id,
            sectionLabel: section.heading,
            numberOfColumns: section.columns.toString(),
            apiNamesCsv: fields.join(COMMA),
            hideSectionLabelOnView: hideHeader,
            hideSectionLabelOnEdit: hideHeader
          };
          result.push(formattedSection);
        }
      }
    }
    return result;
  }

Then we will see this raw data returned from the default Contact page layout:

layoutItem : {
  "editableForNew": true,
  "editableForUpdate": true,
  "label": "Name",
  "layoutComponents": [
    {
      "apiName": "Salutation",
      "componentType": "Field",
      "label": "Salutation"
    },
    {
      "apiName": "FirstName",
      "componentType": "Field",
      "label": "First Name"
    },
    {
      "apiName": "LastName",
      "componentType": "Field",
      "label": "Last Name"
    }
  ],
  "lookupIdApiName": "Id",
  "required": true,
  "sortable": false
}

This is why the required asterisk is being applied to all constituent elements of the Name composite field.

At this time, there is no way to resolve this issue when using the default assigned page layout.

The issue does not occur when you provide the exact page layout API name into the page via page builder, because we use a different mechanism to get the collection of field sections:

 List<Metadata.Metadata> layouts = Metadata.Operations.retrieve(
  Metadata.MetadataType.Layout,
  new List<String>{ layoutName }
);
return layouts.isEmpty()
  ? new Metadata.Layout()
  : (Metadata.Layout) layouts[0];

image

image

However, this does appear to have a separate issue where it is including the section headers when it is not supposed to be; I will see what I can do about that issue.

Regarding this note:

NOTE: Adding a Field Section based on Field Set and then clearing the values from First Name and Middle Name and Salutation still shows the save button, but clicking save does not actually save the new values (this may be a separate ticket).

This is actually a consequence of the way lightning record form works. Lightning record form will always mark fields at the database level as required automatically, but that doesn't notify the save/cancel buttons that they are required. When this happens, the save button is enabled, but the system cannot save the record because it has a required field, so the DML operation fails. I will also see what I can do about this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants