STSMACOM-790: Add configNamePrefix
prop to custom fields components to be able to store section titles separately for different entityType
s.
#1584
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
When multiple instances of the
EditCustomFieldsSettings
/EditCustomFieldsRecord
/ViewCustomFieldsRecord
/ViewCustomFieldsSettings
UI component, each associated with a distinctentityType
, are used within a single application, then modifying the accordion label in one component results in an unintended change to the label in all other components. This behavior contradicts the expected functionality, causing inconsistency in the labeling of accordion sections based on entityTypes.The issue arises due to the request sent to the configurations API to store the accordion label, which utilizes a single
configName
for all entityTypes.Using a single
configName
for multiple entityTypes, leads to a universal change in the accordion label across all instances of theEditCustomFieldsSettings
/EditCustomFieldsRecord
/ViewCustomFieldsRecord
/ViewCustomFieldsSettings
components, regardless of their associated entityTypes.Approach
Use an optional
configNamePrefix
property to extendconfigName
.Issues
STSMACOM-790
Screencasts
2025-05-26_22h47_53.mp4