Notification Release Notes for 1.8.6-GA

Table of Contents

New Features & Notable Changes
- Added Basic Support for Default Notification Preferences
Bug Fixes

New Features & Notable Changes

Added notification listeners to support cart awaiting payment result and pending payment failed events
Updated email templates to optionally gather data from a fulfillment/fulfillmentGroup’s pricedFulfillmentOption (new structure introduced with FulfillmentServices) or fulfillmentOption.

Added Basic Support for Default Notification Preferences

Notification Service will now consult external Customer and Admin User Services to determine recipients' default communication preference. Currently, this is a general preference that applies to all notifications that user receives. The default method is email.

There are now a CustomerProvider, AccountMemberProvider, and AdminUserProvider that send requests to the configured endpoints to retrieve the respective users. These should be interacted with through the UserResolver service.

Important

You likely need to update the Provider base URLs for different configurations and environments.

If using the min flexpackage for example, set the following in application-default.yml:

broadleaf:
  notification:
    # both the customer and account member providers use the customer service
    customerprovider:
      url: 'https://localhost:8447'
    adminuserprovider:
      url: 'https://localhost:8447'

If using the balanced flexpackages, set the following in Cart’s application-default.yml:

broadleaf:
  notification:
    # both the customer and account member providers use the customer service
    customerprovider:
      url: 'https://localhost:9458'
    adminuserprovider:
      url: 'https://localhost:9457'

If you are using Notification on its own in a granular deployment, set the following in Notification’s application-localdev.yml:

broadleaf:
  notification:
    # both the customer and account member providers use the customer service
    customerprovider:
      url: 'https://localhost:8463'
    adminuserprovider:
      url: 'https://localhost:8464'

AbstractEmailNotificationMessageListener#processMessage has been updated to group notifications by the recipient’s communication preference rather than sending them all together. It will also set the delivery type of the notification based on the recipients' preference. If no NotificationHandler is found for that type, the system will attempt to send the notification through a "default" handler.

To that end, NotificationHandler now has a #isDefault flag, and Notification Services defines a defaultNotificationHandler bean out of box. It will try to send the notification as an email.

Tip	The default bean can be overridden by name or completely disabled be setting `broadleaf.notification.default-notification-handler.enabled` to `false`.

Additionally, there is now a defaultEmailMessageSender bean defined that. It will simply log the compiled email.

Important

Implementors should configure a true MessageSender bean for production. The demo comes with an example SendGridMessageSender that Broadleaf uses in our own QA. This requires the following dependency and an API key with the provider:

<dependency>
    <groupId>com.sendgrid</groupId>
    <artifactId>sendgrid-java</artifactId>
</dependency>

Updating Permissions

The new providers require updates to the Notification Client’s permissions in Auth. The following SQL can be used to do so

INSERT INTO blc_client_scopes (id, scope) VALUES ('notificationclient', 'CUSTOMER');
INSERT INTO blc_client_scopes (id, scope) VALUES ('notificationclient', 'ACCOUNT');
INSERT INTO blc_client_scopes (id, scope) VALUES ('notificationclient', 'ACCOUNT_MEMBER');
INSERT INTO blc_client_scopes (id, scope) VALUES ('notificationclient', 'ADMIN_USER');

INSERT INTO blc_client_permissions (id, permission) VALUES ('notificationclient', 'READ_CUSTOMER');
INSERT INTO blc_client_permissions (id, permission) VALUES ('notificationclient', 'READ_ACCOUNT');
INSERT INTO blc_client_permissions (id, permission) VALUES ('notificationclient', 'READ_ACCOUNT_MEMBER');
INSERT INTO blc_client_permissions (id, permission) VALUES ('notificationclient', 'READ_ADMIN_USER');

Introduce communication preferences support
- Add new UserResolver to resolve Customer, AccountMember, and AdminUser entities.
- Add CustomerProvider and AdminUserProvider to perform API requests to the corresponding Microservices.

Bug Fixes

Fixed PathNotFoundException from a partial fulfillment notification for anonymous customers