- v1.0.0-latest-prod
The 2.x versions are Spring Boot 3 compatible.
Updated ModelMapperDomainMapperMember to handle requests with no Tenant ID the same as if the tracking context was disabled.
This allows domain to be mapped without errors in such cases.
Added support for product related entities archival listener
Introduced a Spring event, CatalogEntityDeletedEvent, to notify the system when a CatalogTrackable entity is deleted.
Updated the event propagation logic to ensure that the CatalogEntityDeletionEvent is only emitted once at the starting catalog, instead of all of its child catalogs.
Changes to ContextRequest:
Deprecated forceCatalogForFetch in favor of better naming forceFilterByCatalogIncludeInheritance.
Introduced forceFilterByCatalogIncludeInheritance flag that controls the narrowing logic to only filter on the specified catalog within the context rather than the whole catalog hierarchy.
Reduced error logs from HydrationUtility to be warnings
Support Spring Data Query annotation on non-trackable domain repositories
Enables expanded usage of JpaMappableRepositoryFactoryBean in @EnableJpaRepositories
|
Important
|
Addressing this issue required breaking changes to a few method signatures, outlined below. |
In most cases, create/update/delete (CUD) operations in Broadleaf occur in a sandbox context by default and are subsequently promoted/deployed to production.
In some cases, however, it’s possible for CUD operations to directly target a production context and bypass the promote-deploy flow. For example, it’s possible to import products directly into production.
The logic to determine whether a change is an override (ex: application-catalog-level override of a tenant-catalog-level product) was not correct specifically in the direct-to-production flow. This led to unexpected 'override' labels appearing in the admin for such operations.
There were also issues observed with 'delete' overrides not being correctly created in direct-to-production flows, both for sandboxable and non-sandboxable entities.
The following changes were employed to resolve the issues:
Introduced a new PropagationHelperUtility bean to serve as the central component containing logic around override determination
Updated CrudEntityHelper (which handles direct-to-production flows) and DefaultWorkflowMapper (which handles promote/deploy flows) to inject and use the new PropagationHelperUtility for override determination.
This consolidation ensures both flows do not deviate from each other in the future.
Introduced a new SlimPropagationTracking object, which serves as an immutable deep-copy snapshot of select Tracking information relevant for override determination in PropagationHelperUtility.
This is relevant particularly for operations in CrudEntityHelper, as the original Trackable entity loaded from the datastore is often directly mutated as part of the update process - capturing an early immutable snapshot allows later-stage override determination to see the unaltered original state.
Updated the PropagationIntegrator interface (implemented by CrudEntityHelper) to now require a new SlimPropagationTracking parameter in prepare() and propagateIfApplicable()
|
Important
|
Due to the signature change, this is technically a breaking change. However, clients will not be affected unless they are directly calling these methods in their customizations. The out-of-box framework uses of these methods (which typically are the primary consumers) have already been updated.
Client-customizations calling these methods can simply inject |
Additional CrudEntityHelper.prepare() changes:
Excluded obsolete ChangeDetail entries from being created as FieldOveride entries on the result
Only build and update FieldOverride entries if the updated instance is an override
Updated SortPositionStrategy and DecimalSplitSortPositionStrategy method signatures to accept PropagationHelperUtility as an argument and use it to build the SlimPropagationTracking that is now required to pass to prepare() and propagateIfApplicable()
|
Important
|
Due to the signature change, this is technically a breaking change. However, clients will not be affected unless they are directly calling these methods in their customizations. The out-of-box framework uses of these methods (which typically are the primary consumers) have already been updated.
Client customizations calling these methods will need to inject |
Updated DefaultTrackableDomainMapperMemberSupport to ensure direct-to-production delete overrides result in non-archived records with SandboxInfo.changeType set to DELETE.
This includes addressing an edge case where delete flows were relying on contextRequest.sandboxId==null to make determinations around sandboxing instead of also looking at whether the underlying entity had sandbox behavior.
With the latest changes, sandboxable catalog discriminated entities and non-sandboxable catalog discriminated entities both now have correct delete override behavior.