Fix: unexpected behavior when deleting Option A and renaming Option B with Option A's value. (#13204)
resolve #12345 The issue was caused by the delete running after the update, which led to both the old and new options being deleted when they shared the same value. --------- Co-authored-by: Marie Stoppa <marie.stoppa@essec.edu>
This commit is contained in:
@ -71,7 +71,12 @@ export class FieldMetadataRelatedRecordsService {
|
||||
if (view.viewGroups.length === 0) {
|
||||
continue;
|
||||
}
|
||||
const valuesToDelete = deleted.map((option) => option.value);
|
||||
|
||||
await viewGroupRepository.delete({
|
||||
fieldMetadataId: newFieldMetadata.id,
|
||||
fieldValue: In(valuesToDelete),
|
||||
});
|
||||
const maxPosition = this.getMaxPosition(view.viewGroups);
|
||||
|
||||
const viewGroupsToCreate = created.map((option, index) =>
|
||||
@ -103,13 +108,6 @@ export class FieldMetadataRelatedRecordsService {
|
||||
);
|
||||
}
|
||||
|
||||
const valuesToDelete = deleted.map((option) => option.value);
|
||||
|
||||
await viewGroupRepository.delete({
|
||||
fieldMetadataId: newFieldMetadata.id,
|
||||
fieldValue: In(valuesToDelete),
|
||||
});
|
||||
|
||||
await this.syncNoValueViewGroup(
|
||||
newFieldMetadata,
|
||||
view,
|
||||
|
||||
@ -139,8 +139,14 @@ export class WorkspaceMigrationEnumService {
|
||||
}
|
||||
|
||||
if (allEnumValues?.includes(value)) {
|
||||
const isDestinationOfRename = renamedEnumValues?.some(
|
||||
(enumVal) => enumVal.to === value,
|
||||
);
|
||||
|
||||
if (!isDestinationOfRename) {
|
||||
return value;
|
||||
}
|
||||
}
|
||||
|
||||
if (isDefined(defaultValueFallback)) {
|
||||
return defaultValueFallback;
|
||||
|
||||
Reference in New Issue
Block a user