- v1.0.0-latest-prod
The 2.x versions are Spring Boot 3 compatible.
JpaCustomizedCommonCatalogRepository
Include archived status when building members in inheritance line.
InheritanceLine(s)
Exclude archived catalogs when InheritanceLines#flatten is called. flatten(boolean) is available to include archived
Add InheritanceLine#getActiveMembers to only return unarchived catalogs in the hierarchy
DefaultTrackablePolicyUtils
Use InheritanceLines#getActiveMembers for getImplicitApplicationCatalog and matchInheritanceLine
JpaNumericIdNarrowExecutor
Filter archived catalogs in getIsolatedCatalogIdsFromApplication
DefaultJpaRsqlFilterRulesCriteriaBuilder
buildCatalogCriteria updated to use new InheritanceLines#getActiveMembers instead of #getMembers
Previously it was seen that when a Characteristic was created with no default value and then added to a Product, after promoting the change (not saving or deploying), the entire Product ended up set as the value of the Product Characteristic.
This was not the intended behavior, as the Product Characteristic’s value should have been set to null instead.
The root issue was the logic during a promotion that is interested in setting back-references from the child entity to the parent entity interpreted the Product Characteristic’s value (which is Object) as the same as the parent’s type, e.g., JpaProduct in this case.
(This back-reference is being set because a promotion causes the production record to be copied, so the child reference needs to point to the copy not the original.)
After an entity with an embedded child entity was promoted and when reclaiming references on the promoted record, the parent entity was set as the value of null Object fields of child entities.
This is only intended to happen when the child field’s type is the same as or is a subclass of the parent entity, indicating that it is a back-reference or otherwise part of a bidirectional relationship.
The check previously being made to detect this matching type was too general since it only checked that the child field’s type isAssignableFrom the parent’s type, and, since the child field’s type was Object, this was true.
The change made was to check if the child field’s class is Object and then only set the parent reference if it is equal to Object.class, which likely will never be true.
This preserves the original intent of setting entity back-references.