- v1.0.0-latest-prod
The 2.x versions are Spring Boot 3 compatible.
Previously, JpaTrackableRepository#purgeObsoleteSandboxData was unimplemented, which meant that there was no behavior in place to clear records in the database where TRK_SANDBOX_ARCHIVED was true.
This feature is now implemented, which means obsolete records are now cleared from the system.
Key details:
There was always a PURGE_OBSOLETE_SANDBOX_DATA scheduled job available in the system, and there were already corresponding PurgeObsoleteSandboxDataListener and PurgeObsoleteSandboxDataHandler components to listen for those job events and invoke TrackableRepository.purgeObsoleteSandboxData on supported repositories.
However, since the actual purge logic was unimplemented, it was effectively a no-op.
PurgeObsoleteSandboxDataListener has been updated to execute work asynchronously on a new TaskExecutor with bean name purgeObsoleteSandboxDataTaskExecutor.
This allows the potentially long-running purge process to complete in a background thread rather than blocking up the message listener for a long time.
Please see the Javadocs of this component for more details.
PurgeObsoleteSandboxDataHandler now carefully checks which repositories support the current data route before invoking the purge logic on them.
Furthermore, if one repository’s purgeObsoleteSandboxData() fails, the exception is caught and the handler continues invoking the flow on other repositories as a 'best-effort' attempt.
JpaTrackableRepository now injects JpaPurgeObsoleteSandboxProperties, List<JpaPurgeObsoleteSandboxRecordsHandler>, and the universal TransactionTemplate.
JpaTrackableRepositoryFactoryBean, JpaTrackableRepositoryFactory, and DefaultJpaTrackableRepositoryDelegateHelper have been updated to populate these values on the repository instances that are created.
The Javadocs of TrackableRepository.purgeObsoleteSandboxData have been updated to be more clear about behavioral expectations.
Please review the Purging Obsolete Sandbox Data article for more details on the new functionality.
Audit update fields are populated on create. This is controlled by a broadleaf.common.data.application.configuration.populate-audit-update-on-create property, default false
Added support for a single sort across multiple columns based on select case.
Added support for modernization of Billing Service.
Supports optimized converter based mapping in ModelMapper flows
Supports an explicit mapping pattern with ModelMapper, required to provide better performance
Added support for imported entities with no changes
Added support for conjunction in the JPA RSQL criteria builder.
Updated ModelMapper cache to not cache entities that don’t have a projection domain.
Usages of forceCatalogForFetch in DefaultTrackableDomainMapperMemberSupport were updated to use forceFilterByCatalogIncludeInheritance.
Fixed FilterAndSort issue causing Catalog Access Policies targeting the Product#brand to not apply.
Fixed issue where LinkedField cannot be found if "rootType" is an extended entity.
Fixed export and other operations to include catalogs with "PENDING" status, since they are called from the admin context.
Added a new PendingCatalogInclusionContext to dictate when to include pending catalogs.
Additionally, added a utility proxy contract to check if in an Admin context from Data Tracking, since Data Tracking does not rely on Broadleaf’s Security library.
Improved the randomness of IDs generated by UlidIdentifierGenerator
Improved NotificationState to be consistent and deterministic during resolution, by applying a sort on the id when there are multiple matches for a given message type.
Added handling for null catalog inclusion and exclusion filters.
Added serialization to emit JSON for the amount field and ignores the currency, to avoid currency mismatch errors.
Provides a relaxed field comparison pass in ContextStateBuilder should the normal first pass fail.
Fixed an issue where extremely large queries could be built through the narrowing process, causing performance issues in some cases.
Archived items are excluded from being utilized in the JpaNarrowExecutor in order to reduce the query size.