July 7, 2022
Feature/Notable Change | Impacted Services | Links |
---|---|---|
Added new ItemList management endpoints to allow updating only the list name or attributes |
CartOperationServices, Commerce SDK |
|
Refined the process of saved payment method creation to be executed after the first transaction execution ( |
CustomerServices |
|
Refined |
CustomerServices |
|
Introduced new sensitive customer payment account endpoints, to support PTS to create payment account and update last transaction execution data, in response to the new saved payment creation process |
CustomerServices |
|
Introduced new properties to control where saved payment methods are stored and managed |
CustomerServices |
|
Introduced a new field |
CustomerServices |
|
Updated the saved payment management and checkout form components to use the new SavedPaymentMethod client and hooks |
NextJS Starter |
|
Added methods to use new SavedPaymentMethod management endpoints for customer’s saved payment management |
Payment JS SDK |
|
Payment Transaction Services 1.0.2 Release |
PaymentTransactionServices |
Commerce SDK
Deprecated the PaymentAccount-related types and hooks in CustomerClient in favor of the new SavedPaymentMethod management with PaymentTransactionServices
Deprecated Payment#customerPaymentAccountId
in favor of Payment#savedPaymentMethodId
for more accurate naming
Deprecated Payment#shouldSavePaymentToCustomer
in favor of Payment#shouldSavePaymentForFutureUse
to support owning user types other than customer in a future release
CustomerServices
Deprecated Payment and PaymentAccount related domains, components, and endpoints, as PaymentTransactionServices is now the default and preferred approach of storing and managing saved payment methods. See PaymentTransactionServices 1.0.2 release notes for details
checkoutCompletionInputCustomer
message binding is removed from customer-defaults.yml
. See Messaging Components for more details
Payment JS SDK
Deprecated CardFormData#customerPaymentAccountId
in favor of CardFormData#savedPaymentMethodId
for more accurate naming
Deprecated CardFormData#shouldSavePaymentToCustomer
in favor of CardFormData#shouldSavePaymentForFutureUse
to support owning user types other than customer in a future release
Deprecated PaymentAccount-related methods in favor of the new SavedPaymentMethod management with PaymentTransactionServices
With 1.7.2
, we did an audit of our out-of-box SpringCloudStream bindings, & for various flexpackage configurations, we found a few anonymous bindings (i.e. subscription id like anonymous.*
). This means that the binding was not configured, so SpringCloudStream registered a default binding. These cases can be split into two categories:
Bindings with missing configuration
The primary consequence of this case is that a SpringCloudStream consumer group is not declared. Therefore, each application instance of that flex package will receive the message.
Unnecessary bindings that can be disabled
In most cases, this correlated to the registration of sandbox-related bindings in a context that doesn’t contain sandboxable entities. Therefore, the message listeners were disabled, rather than configuring their bindings.
In your project, make sure to define the following properties to complete the configuration:
broadleaf:
sandbox:
messaging:
active: true
transitionrequest:
enabled: true
changesummary:
notification:
active: true
broadleaf:
changesummary:
notification:
active: false
transitionrequest:
enabled: false
broadleaf:
changesummary:
notification:
active: true
transitionrequest:
enabled: true
broadleaf:
sandbox:
messaging:
active: true
changesummary:
notification:
active: true
transitionrequest:
enabled: true
PostgreSQL versions 11.15, 12.10, and 13.6 include a regression that causes the usage of Trigram indexes to produce the following error: variable not found in subplan target list
.
To mitigate the problem, we introduced the trigram
liquibase changeset label. Add the following properties in your project to avoid creating trigram indexes:
Note
|
Subsequent versions of PostgreSQL should be immune to the problem and this workaround should not be required at that point. |
broadleaf:
adminuser:
liquibase:
labels: "!trigram"
asset:
liquibase:
labels: "!trigram"
campaign:
liquibase:
labels: "!trigram"
catalog:
liquibase:
labels: "!trigram"
customer:
liquibase:
labels: "!trigram"
menu:
liquibase:
labels: "!trigram"
offer:
liquibase:
labels: "!trigram"
pricing:
liquibase:
labels: "!trigram"
broadleaf:
asset:
liquibase:
labels: "!trigram"
campaign:
liquibase:
labels: "!trigram"
catalog:
liquibase:
labels: "!trigram"
menu:
liquibase:
labels: "!trigram"
offer:
liquibase:
labels: "!trigram"
pricing:
liquibase:
labels: "!trigram"
broadleaf:
customer:
liquibase:
labels: "!trigram"
broadleaf:
campaign:
liquibase:
labels: "!trigram"
catalog:
liquibase:
labels: "!trigram"
customer:
liquibase:
labels: "!trigram"
menu:
liquibase:
labels: "!trigram"
offer:
liquibase:
labels: "!trigram"
pricing:
liquibase:
labels: "!trigram"
broadleaf:
adminuser:
liquibase:
labels: "!trigram"
Starting with 1.7, we have begun publishing common base charts to a private helm repository. In order to pull in and use these charts, you will need to authenticate (i.e. helm repo add broadleaf https://repository.broadleafcommerce.com/repository/helm-private/ --username $BLC_REGISTRY_USER --password $BLC_REGISTRY_PASSWORD
) using the same credentials that were sent to you (these are the same credentials that allow you to build and run the microservice applications).
See the following for more details:
README instructions in the provided devops-helm-charts
repo