-
Notifications
You must be signed in to change notification settings - Fork 39
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
Comments
This is interesting... The problem here arises from how the 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 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:
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]; 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:
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. |
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
Optionally:
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).
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.
The text was updated successfully, but these errors were encountered: