Adding Offer Codes by URL

With core Broadleaf, Customers may add, or remove, offer codes from the cart view. With the AdvancedOffer module, offer codes can also be added to the cart via a URL parameter, a storage (cookie or session), or Customer data.

Each Site-side request passes though the URLHandlerFilter, which leverages AdvancedOfferURLHandlerFilterExtensionHandler to recognize and process offer codes from the request.

Offer codes are saved in storage. A storage can be either cookies or session which is determined by property offer.code.storage.use.session. It has a default value of false and cookie is used as default storage for offer codes.

This process gathers previously applied offer codes from three locations - a storage, the customer, and the customer's cart - and are added to a Set, using the following logic:

If offer codes is present in storage, then the offer codes are gathered from the storage and added to the set.
If the customer is registered, then the offer codes are pulled from the customer offer code table. If the customer is not registered, then the offer codes are pulled from a transient property of the customer.
If the customer has a cart, then the offer codes are pulled from the order offer code table.

Additionally, this process uses the following logic to add/remove offer codes, based on the request:

If this request is for removing an offer code via the cart view, then the code is gathered from the request parameters and removed from the set. The OfferCodeRequestProcessor uses the offer.code.removePromo.path system property to recognize this kind of request. Note this system property is defaulted to /cart/promo/remove.
If this request is for adding an offer code via the cart view, then the code is gathered from the request parameters and added to the set. The OfferCodeRequestProcessor uses the offer.code.addPromo.path system property to recognize this kind of request. Note this system property is defaulted to /cart/promo.
If this request is for adding an offer code via the URL, then the code is gathered from a configurable request parameter (offer.code.request.param.name, defaults to _blOfferCode) and added to the set. In the case of a URL forward, the offer code will be gathered from the request attributes instead.

Once the final set of offer codes is determined, they are saved to the storage, the customer, and the cart using the following logic:

If the offer code set is empty, then value deleted from storage. Otherwise the new set of offer codes will be set on the storage, replacing all previous offer codes. The cookie name is determined by the offer.code.cookie.name property which has a default value of _blOfferCode. Additionally, the offer.code.cookie.value.delimiter and offer.code.cookie.max.age properties are used when defining this cookie.
If the customer is registered, then the offer codes are saved to the customer offer code table, using the current customer. If the customer is not registered, then the customer's transient offer code property is replaced with the current set.
If the customer has a cart, then the final set of offer codes are added the order offer code table, using the current order.

Later, when the cart is priced using the blPricingWorkflow, the OfferActivity makes use of this persisted offer code set to update the cart's pricing.

API module and Site interplay

Offer Codes are stored either in cookies or session of the browser which API cannot access. This causes a known issue when API and Site are used simultaneously.

Assume a scenario where you've added something to the cart and applied offer code from a browser. It is possible to remove that offer code from the cart using API. If you remove via API then continue checkout via API, you will get expected result (cart without offer code).
However, if you decide to continue on the browser, you will find that code that you've removed via API is still there. This is because offer code is retrieved from cookies/session of the browser and will be re-applied.