SELECT id, context_id, name, trk_level, trk_sandbox_archived
FROM catalog.blc_product_business_type
WHERE trk_sandbox_archived = 'Y'
- v1.0.0-latest-prod
|
Tip
|
The 2.x versions are Spring Boot 3 compatible. |
This version includes all changes up to 2.1.4 Release Notes.
Updated BusinessTypeService and BusinessTypeRepository to introduce a method that can find BusinessType by ID as well as additional RSQL filters
Refactored logic that built BusinessType instances from DefaultProductType values into its own DefaultProductTypeBusinessTypeBuilder component.
BusinessTypeEndpoint now injects and uses this component instead of having the logic inline within itself.
For BusinessType instances built for DefaultProductType values, added logic to set a reserved corresponding ID for BusinessType.id instead of keeping it blank.
The ID mapping is defined in DefaultProductTypeBusinessTypeBuilder.
Introduced the ability to define available terms for Products.
Introduced support to be able to add Products with a rule-based Category Item Choice Product Option to cart.
Introduced the ability to Sync Characteristics and translations for any missing Characteristics for Product Business Types and default any values as applicable.
Added priceDataViewType as a property in CatalogMetadataProperties to dictate changes in the metadata for Products and Option Templates to either display default views or recurring/subscription-specific views.
Introduced a new /product-types/all endpoint in BusinessTypeEndpoint to serve the purpose of returning all non-paginated BusinessType records.
Deprecated the previous conflicting request mapping at /product-types
Updated the BusinessType metadata configuration to use the new endpoint path instead of the old one.
Updated the BusinessType metadata configuration to remove the narrowedPaging() configuration when using the endpoint, since neither the previous nor current implementation of that endpoint support pagination.
CatalogEntityDeletedEventHandler Failures with Deactivated ApplicationsCatalogEntityDeletedEventHandler implementations would fail on a security validation when run against data from a deactivated application (see Application.deactivated).
To address this, each of the out of box implementations have been updated to disable security policy validation before invoking any CRUD methods to find/remove data.
This is a safe change, as the cleanup handlers are always run internally by the system (rather than by any user/client).
Almost all policy validations are skipped in such an environment already, but the Application.deactivated check is an exception, and the CatalogEntityDeletedEventHandlers are a rare case which actually attempt to deal with deactivated applications.
Thus, explicitly bypassing security validation in this flow is necessary.
The changes:
Introduce a new doWithoutPolicyValidation() method in AbstractCatalogEntityDeletedEventHandler
Update all out of box implementations of CatalogEntityDeletedEventHandler to wrap their CRUD service invocations with the new doWithoutPolicyValidation() method
|
Note
|
If you have introduced your own CatalogEntityDeletedEventHandler or customized one of the out of box implementations, you may want to check that your custom code flows also bypass security validation.
|
BusinessTypeThe BusinessType domain was always meant to be non-sandboxable, and all operations against this domain from the Broadleaf admin have been 'production' level accordingly.
However, the Trackable configuration of JpaBusinessType did not explicitly exclude sandbox behavior.
This meant that theoretically, it was possible to create sandbox-level records for this domain if requests were made by a custom API caller.
With this release, JpaBusinessType has been explicitly annotated with @TrackableExtension(TrackableBehavior.APPLICATION), which excludes it entirely from supporting sandbox behavior.
Clients who have exclusively been managing this domain from the Broadleaf admin will not be impacted by this change, as the Broadleaf admin has always affected this domain at the production (non-sandbox) level.
For clients that believe they may have sandbox-level BusinessType records, here are some recommended steps:
First, examine the change summaries in the BLC admin’s 'Application Updates' section. From here, you can audit and manage (deploy/reject/etc) any changes to BusinessType domains until there are no more pending changes.
At this point, all that should be left in the CatalogServices database are production level records and 'obsolete' sandbox level records. The goal now is to find and remove those obsolete records.
|
Note
|
Technically, this step to remove obsolete sandbox records is optional. However, we include it in case clients find it helpful. |
You can run the following SQL to see the BusinessType records who exist in the datastore with a sandbox-archived state
SELECT id, context_id, name, trk_level, trk_sandbox_archived
FROM catalog.blc_product_business_type
WHERE trk_sandbox_archived = 'Y'Inspect these results and verify that these obsolete records are indeed okay to remove
You can run the following SQL to see the Notification State records that would become orphaned if those business types were deleted:
SELECT id
from catalog.blc_notification_state
WHERE entity_type = 'com.broadleafcommerce.catalog.provider.jpa.domain.product.type.JpaBusinessType'
AND container IN (SELECT id
FROM catalog.blc_product_business_type
WHERE trk_sandbox_archived = 'Y')If everything looks fine to remove, then you can first execute a DELETE on the blc_notification_state table with the same criteria as above, and then execute a DELETE on the blc_product_business_type table, again with the same criteria as above.
Added a new GET endpoint to fetch BusinessType records, replacing a now-deprecated endpoint.
Previously, there were several different GET operations mapped to the same /product-types path, distinguished only by request parameters.
While technically functional, the operations deserved to be more clearly disambiguated due to their differing semantics and response schemas.
Thus, this existing mapping has been deprecated:
GET /product-types?includeDefaults=(boolean)&includeTemplates=(boolean), returning List<BusinessType>
The replacement endpoint is:
GET /product-types/all?includeDefaults=(boolean)&includeTemplates=(boolean), returning List<BusinessType>
The BusinessType admin metadata configuration has been updated to use the new endpoint path instead of the old one.
Furthermore, the narrowedPaging() configuration has been removed when calling this endpoint, as neither the previous nor current implementation of the endpoint supports pagination.
Refactored Product Characteristic value handling and updated Characteristic field labels to fix issues with default values and labels.
Fixed issue where translations were allowed on numeric characteristic values.
| Path | Description |
|---|---|
|
Read a page of Characteristics, accepting RSQL filters and a name ( |
|
Create a new Characteristic. |
|
Read a single Characteristic by ID. |
|
Patch a single Characteristic by ID. |
|
Replace a single Characteristic by ID. |
|
Delete a single Characteristic by ID. |
|
Replace the translations for a single Characteristic by ID for a given locale. |