broadleafcommerce/broadleafcommerce

Broadleaf Commerce CE - an eCommerce framework based on Java and Spring

Broadleaf Commerce Community Edition (CE)

Broadleaf Commerce CE is an e-commerce framework written entirely in Java and leveraging the Spring framework. It is targeted at facilitating the development of enterprise-class, commerce-driven sites by providing a robust data model, services and specialized tooling that take care of most of the "heavy lifting" work. To accomplish this goal, we have developed the core platform based on the key feature sets required by world-class online retailers. We've also taken extra steps to guarantee interoperability with today's enterprise by utilizing standards wherever possible and incorporating best-of-breed, open-source software libraries. Broadleaf CE and EE are architected as a traditional unified codebase that share a core dependency across a site and admin deployment. If you are looking for a microservices based architecture, check out our Microservices Edition

Editions

There are three editions of Broadleaf:

• Broadleaf Commerce Community Edition (CE) - open source under a dual licence format with both fair use and commercial restrictions. See dual license below for more details.
• Broadleaf Commerce Enterprise Edition (EE) - source available under a commercial license. Built on top of Broadleaf's open core platform, this edition includes additional features and support for B2C, B2B, Multi-Tenant, and Marketplace use cases.
• Broadleaf Commerce Microservices Edition - source available under a commercial license. This next generation platform provides a microservice enablement framework consisting of headless commerce APIs that support many enterprise use cases. Please contact us or sign up for a Developer Evaluation for more information.

CE Dual License

Broadleaf Commerce core is released under a dual license format. It may be used under the terms of the Fair Use License 1.0 (http://license.broadleafcommerce.org/fair_use_license-1.0.txt) unless the restrictions on use therein are violated and require payment to Broadleaf, in which case the Broadleaf End User License Agreement (EULA), Version 1.1 (http://license.broadleafcommerce.org/commercial_license-1.1.txt) shall apply. Alternatively, the Commercial License may be replaced with a mutually agreed upon license between you and Broadleaf Commerce.

Getting Started

Check out our Getting Started guide to quickly kick off your Broadleaf-enabled website.

Key Features and Technologies

Spring Framework

Spring is the enterprise Java platform on which BroadleafCommerce is based. It provides numerous features, including dependency injection and transaction control.

Security

Spring Security provides a robust security framework for controlling authentication and authorization at both the code and page level and is utilized by BroadleafCommerce for access control.

Persistence

JPA and Hibernate represent the BroadleafCommerce ORM infrastructure for controlling persistence of our rich domain model.

Search

Flexible domain search capabilities in BroadleafCommerce are provided through integration with Solr.

Task Scheduling

Scheduling of repetitive tasks in BroadleafCommerce is offered through the Quartz job scheduling system.

Email

Email support is provided throughout the BroadleafCommerce framework in either synchronous or asynchronous (JMS) modes. Email presentation customization is achieved via Thymeleaf templates.

Modular Design

Important e-commerce touchpoints are embodied in the concept of BroadleafCommerce "Modules". A module can provide interaction with a credit card processor, or even a shipping provider. Any number of custom modules may be developed and utilized with BroadleafCommerce.

Configurable Workflows

Key areas in the e-commerce lifecycle are represented as configurable workflows. Implementors have full control over the keys steps in pricing and checkout, allowing manipulation of module ordering, overriding existing module behavior and custom module execution. Composite workflows are also supported to achieve more exotic, nested behavior.

Extendible Design

BroadleafCommerce is designed from the ground-up with extensibility in mind. Almost every aspect of BroadleafCommerce can be overridden, added to or otherwise modified to enhance or change the default behavior to best fit your needs. This includes all of our services, data access objects and entities. Please refer to the extensibility section of our documentation.

Configuration Merging

As an extra bonus to our extensibility model, we offer a custom merge facility for Spring configuration files. We minimize the BroadleafCommerce configuration semantics that an implementer must be aware of, allowing our users to focus on their own configuration particulars. BroadleafCommerce will intelligently merge its own configuration information with that provided by the implementer at runtime.

Presentation Layer Support

BroadleafCommerce also includes a number of pre-written Spring MVC controllers that help to speed development of the presentation layer of your own BroadleafCommerce-driven site.

QOS

BroadleafCommerce also provides quality of service monitoring for modules (both custom and default modules) and provides support for several QOS handlers out-of-the-box: logging and email. Additional, custom QOS handlers may be added through our open API.

Promotion System

BroadleafCommerce includes a highly-configurable system for including your pricing promotions. We provide several standard levels at which promotions may be applied: Order level, Order Item level and Fulfillment Group level. In addition, your promotion business rules are represented in a flexible and standardized way using the MVEL expression language.

PCI Considerations

We have taken measures in the construction and design of BroadleafCommerce to help you achieve PCI compliance, should you decide to store and use sensitive customer financial account information. Payment account information is referenced separately, allowing you to segregate confidential data onto a separate, secure database platform. API methods have been added to allow inclusion of any PCI compliant encryption scheme. Also, verbose logging is included to track payment interaction history.

Admin Platform

BroadleafCommerce includes a wholely extendible administrative application built with Spring MVC. The admin application also provides an easy-to-use interface for catalog, order and customer functions and provides a robust, rule-driven environment for creating and managing discount promotions.

Admin Customization

BroadleafCommerce provides a robust set of admin presentation annotations that allow configuration of domain class display and persistence semantics without touching any admin code. This provides an easy-to-consume approach for introducing entity extensions and additional fields into the admin forms so that your business users can immediately start to benefit. We also provide a full annotation or xml-based approach for overriding the admin config declared inside BroadleafCommerce so that you can have an impact on our defaults. And for more advanced customizations, our admin platform is based on Spring MVC, so your Spring knowledge will translate here as well when it comes to adding additional controllers, and the like.

Content Management

BroadleafCommerce includes a robust content management system for creating and managing static pages and content. We also include a powerful content targeting feature that allows business users to dynamically drive the most appropriate content to users.

Please contact us for information.

broadleafcommerce's Issues

Refactor BaseActivity and set the default automaticallyRegisterRollbackHandler to "false"

Consider Refactoring BaseActivity and set the default automaticallyRegisterRollbackHandler to "false" because in most cases if you define an activity with a Rollback Handler. The activity itself needs to programmatically register itself with the Activity Manager instead of having the SequenceProcessor register it. Right now as it is set to "true", the activities that do register a rollback have to manually set it and produce some boiler plate code. See: org.broadleafcommerce.inventory.service.workflow.DecrementInventoryActivity and org.broadleafcommerce.core.payment.service.workflow.PaymentActivity

if (getRollbackHandler() != null && !getAutomaticallyRegisterRollbackHandler()) {
  ...
}

In the cases of the existing activities, the Rollback Handlers are null anyways so the logic in the SequenceProcessor should still work if you set automaticallyRegisterRollbackHandler to "false"

if (activity.getRollbackHandler() != null && activity.getAutomaticallyRegisterRollbackHandler()) { 
  ActivityStateManagerImpl.getStateManager().registerState(activity, context, activity.getRollbackRegion(), activity.getRollbackHandler(), activity.getStateConfiguration());
}

Null PersistenceUnitRootUrl during Ejb configuration error

[java] ERROR (Ejb3Configuration.java:843) - Container is providing a null PersistenceUnitRootUrl: discovery impossible

This is seen in the logs during startup of tomcat. Does not seem to affect the project when orm locations are manually defined, but it they were to be scanned off of classpath, it could be a problem.
It looks like the PersistenceUnitInfo coming out of the MergePersistenceUnitManager needs to set the PersistenceUnitInfo.persistenceRootUrl to the classpath of the merging PU.

After validation failure, product bundle fields are shown when editing a product

Custom Persistence Handlers should be bean refs for overriding

Rather than defining custom persistence handlers like this:

    <bean id="blCustomPersistenceHandlers" class="org.springframework.beans.factory.config.ListFactoryBean" scope="prototype">
        <property name="sourceList">
            <list>
                <bean class="org.broadleafcommerce.admin.server.service.handler.CategoryCustomPersistenceHandler"/>
                <bean class="org.broadleafcommerce.admin.server.service.handler.CustomerPasswordCustomPersistenceHandler"/>                
               ...
            </list>
        </property>
    </bean>

It should instead be defined like this:

    <bean id="blCustomPersistenceHandlers" class="org.springframework.beans.factory.config.ListFactoryBean" scope="prototype">
        <property name="sourceList">
            <list>
                <ref bean="blCategoryCustomPersistenceHandler" />
                <ref bean="blCustomerPasswordCustomPersistenceHandler" />
               ...
            </list>
        </property>
    </bean>

This way, someone can override it with their own by just adding:

<bean id="blCategoryCustomPersistenceHandler" class="com.mycompany.admin.service.handler.MyCategoryCPH" />

ProductDaoImpl possibly using obsolete Join on 'allProducts'

Found this while disabling the Solr search service. I'm getting a "Unable to resolve attribute [allProducts] against path" when browsing through the front-end categories.

I think the 'allProducts' Join in

public List readFilteredActiveProductsByCategory(Long categoryId, Date currentDate, ProductSearchCriteria searchCriteria)

// We want to filter on attributes from product and sku
Join<Category, Product> product = category.join("allProducts");

Is causing this. From the Git history it seems that this has been refactored to take advantage of the CategoryProductXrefs.

Not sure what the best approach would be to fix this?

Sku bundle item form is blank after selecting a Sku

Originally from the forums

Description: Since your last commit (19efc61) on 2.2.1-SNAPSHOT branch, we are not able to add a skuBundleItem in a bundle through the admin, the popup where we have to set the skuBundleItem sale price and quantity is empty:

Test inheritance for product bundles when removing additionalSkus and product options list

The lines I am referring to specifically are in AdminProductController. What happens when we're using an extension of ProductBundle (MyProductBundleImpl)? Will the type of the form still be ProductBundleImpl?

@jefffischer @apazzolini you guys might know off the top of your head. If not we should investigate to see if this is a potential future bug.

Cannot modify the state of the CartStateRequestProcessor to reprice for locale/currency changes with an active cart

The boolean to control this (copyCartWhenSpecifiedStateChanges) is currently static so there is no way to change with a bean override

Enhance bean merging to allow inline definitions

This would remove a requirement to create a separate bean id for merging lists/maps/sets into previously-defined ones.

Entity properties should be validated in the admin based on their field types

For instance, an Integer field must be an integer, a Decimal field must be a decimal, etc.

Money is not serializing properly in REST APIs

Product option fields are not shown when adding a new additional Sku

These should show up as dropdowns for the currently configured product options for that particular product

Text not correctly internationalized

On the demo site, in the page fragment dedicated to being able to share the item through the social networks, the title text is not correctly translating

Fix precision problems when saving Money fields in the admin

Money fields should always be instantiated with BigDecimal, never Double.

Add validation to ensure sum of accepted payments is equal to the order total

Under certain configurations, there was a possibility that an order might be marked as submitted even if payments did not go through

Error resolving template "utility/blcRedirect" exception in the admin

Run DemoSitу with 3.0.0-BETA verion for broadleaf dependencies.
It means that the property in the parent pom.xml should be

<blc.version>3.0.0-BETA3</blc.version>
.
Login to admin project http://host;port/admin
Try to create Category or Product.
The exception occures :

[ERROR] TemplateEngine - [THYMELEAF][3] Exception processing template "utility/blcRedirect": Error resolving template "utility/blcRedirect", template might not exist or might not be accessible by any of the configured Template Resolvers

Backport FieldManager changes to 2.2.1-SNAPSHOT

Change description:

In inheritance hierarchies where several entities are siblings at the most derived position, FieldManager can end up picking the wrong sibling.
    For example
    ProductImpl
    MyProductImpl
    ProductBundleImpl
If the property is on MyProductImpl, it's possible that FieldManager will try to find it on ProductBundleImpl instead, which is not correct.

The commit SHA is ec3f286 and should be safe to backport to the BroadleafCommere-2.2.1-SNAPSHOT branch. Currently being used by an implementor.

Price adjustments set on a product option do not apply if there is no price set for a non-default sku

Scenario:
ProductOption A is set up with 2 possible values. The first one has no price modification and the second value has +$50.00 as its adjustment.
Product B has defaultSku with price $100.
Product B also has 2 generated skus, neither of which has a price set.
In this case, adding the sku with the price modifier to cart will result in the price being $100, not $150.
This is fixed in 2.3, the change just needs to be backported.

Originally reported by @apazzolini

Create minimalist interfaces for tax module integration

The idea here is to create minimalist interfaces to allow tax modules more stability over time. Rather than pass a Broadleaf Order to a tax module, we'll pass a more minimalist "TaxableOrder".

Write the first Admin Test

Let's get this kicked off!

This is a test issue

Some test comments

The Structured Content Targeting Processor needs to support a product attribute.

The 3.0 ContentProcessor needs to support a product rule similar to the TagLib from 2.x.

Test Issue

test

NPE after product validation failure

Move validation errors to after field names

Static assets are still served up when they are deleted

When you delete a static asset, it is still being served up via it's url. Additionally, if you create a new static asset with the same url as a previously deleted asset, the deleted asset will continue to be served instead of the new asset.

Create DefaultPaymentRollbackHandlers for each of the Payment Modules

Each of the Payment Modules should provide a default RollbackHandler implementation. Depending on integration, some may need to provide a way to credit or void a transaction or at least create a record for it.

The PaymentActivity already sets up the Rollback State, a default handler would be useful for the different integrations

if (getRollbackHandler() != null && automaticallyRegisterRollbackHandlerForPayment) {
  Map<String, Object> myState = new HashMap<String, Object>();
  if (getStateConfiguration() != null && !getStateConfiguration().isEmpty()) {
    myState.putAll(getStateConfiguration());
  }
  myState.put(ROLLBACK_ACTIONTYPE, seed.getActionType());
  myState.put(ROLLBACK_PAYMENTCONTEXT, paymentContext);
  myState.put(ROLLBACK_RESPONSEITEM, paymentResponseItem);
  ActivityStateManagerImpl.getStateManager().registerState(this, context, getRollbackHandler(), myState);
}

Introduce ability for client-side Javascript validators in the admin

Instead of simply submitHandlers, this could be exploded in preValidationHandlers, validationHandlers and postValidationHandlers.

Cannot add more than 1 additional Sku to a product

Incorrect validation led to multiple Skus not being able to be added individually

In a portlet environment, AuditableListener does not work and throws an NPE

This is because of these lines in the setValueAgent method:

BroadleafRequestContext requestContext = BroadleafRequestContext.getBroadleafRequestContext();
            if (requestContext != null) {
                Object customer = requestContext.getRequest().getAttribute(customerRequestAttributeName);

In a portlet environment, requestContext.getRequest() will return null since this is not a servlet request. Instead, this should use the requestContext.getWebRequest() method to return Spring's WebRequest which will be set in both the servlet and portlet contexts.

Consider Refactoring PaymentActivity/DecrementInventoryActivity to use a consistent approach to registering Rollback Handlers

Consider Refactoring PaymentActivity/DecrementInventoryActivity to use a consistent approach between all activities That register Rollback Handlers.
The way that rollback handlers are registered is inconsistent between org.broadleafcommerce.core.payment.service.workflow.PaymentActivity and org.broadleafcommerce.inventory.service.workflow.DecrementInventoryActivity. This could be resolved if issue #93 is addressed.

Not sure the significance of having a separate boolean for Payment?

if (getRollbackHandler() != null && automaticallyRegisterRollbackHandlerForPayment) {
  ...
}

vs.

if (getRollbackHandler() != null && !getAutomaticallyRegisterRollbackHandler()) {
  ...
}

Branch Cleanup

Pretty sure that the following branches can be deleted:

price-splits
MultiSite
offer_customization
developadvancedoffer
Emit-JAXB

Anyone else have comments on these?

NPE when throwing a ValidationException (and it's not the cause of a ServiceException)

Domain objects should use EL naming convention for getters of instance variables

Variables isDefault and isActive in AddressImpl.java do not follow the naming convention for getters that will allow proper property access from within EL. Currently, the only way to access these variables is via a direct method call.
e.g., ${address.isDefault} throws javax.el.PropertyNotFoundException whereas ${address.isDefault()} functions as you would expect it to.
I am unsure if these are the only two occurrences of where this is happening.

Originally opened by @apazzolini

Additional Skus List in the admin is difficult to read

@apazzolini, @bpolster, @jefffischer, Wondering what you guys think makes more sense for displaying Skus. The list in the screenshot is operating off of getters, and thus gleaning prices and start date from the defaultSku:

On this additionalSkus field (when viewing a product) Do you think that it makes more sense to:

1. Leave these inherited fields blank
2. Fill in the values with '(Not Set)' (current implementation that has some problems
3. Fill in the values from the getter but include something like '(inherited)' somewhere?
4. Some sort of clickable tooltip info button that says that this field was inherited from the defaultSku

The other case is when we are displaying the Sku list elsewhere in the admin (like searching for a Sku to associate to a bundle). In that case, I assume that the values for each Sku field should come from the getter (and thus could inherit from the defaultSku) with no messaging about defaultSkus anywhere.

Thoughts?

StaticStorageAssetService needs to leverage existing resized files more efficiently

When assets are being loaded from the classpath and then dynamically resized, they should not generate unique filenames by site or other context criteria.

Archived products are accessible and visible

If you delete (archive) a product from the administration view, the product will still be accessible via URL or, if it was in a featured/cross sale/up sale list, by just clicking it.

Will also be possible to proceed to add to the cart and buy the deleted (archived) product.

The problem of the products being visible in the featured/cross sale/up sale lists seems to be related to this snippet (and same goes for the other lists):

@Override
public List<FeaturedProduct> getFeaturedProducts() {
    if (filteredFeaturedProducts == null && featuredProducts != null) {
        filteredFeaturedProducts = new ArrayList<FeaturedProduct>(featuredProducts.size());
        filteredFeaturedProducts.addAll(featuredProducts);
        CollectionUtils.filter(featuredProducts, new Predicate() {
            @Override
            public boolean evaluate(Object arg) {
                return 'Y' != ((Status) ((FeaturedProduct) arg).getProduct()).getArchived();
            }
        });
    }
    return filteredFeaturedProducts;
}

The filter is run on the wrong variable therefore the returned variable is just a copy of the original array.

This are my 2 cents, as I don't know deeply the code of Broadleaf Commerce, but seems a simple error.

I'm right to assume that fixing this will not make unwanted changes to other core functions?

REST API serializes Dates as Long value, only as JSON. Should be ISO 8601 format.

XML serialization seems to work fine, but JSON serialization renders dates as long values.

Named query BC_READ_ACTIVE_SUBCATEGORIES_BY_CATEGORY may not return correct results due to missing null check on active date.

REST API CategoryWrapper should use SearchService to find product list for the category

Move default vals for applicationContext-filter out of DemoSite and into the framework

Could cause compatibility issues down the line. I'm referring to that file that is currently managed in DemoSite:

    <bean id="openEntityManagerInViewFilter" class="org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter"/>

    <bean id="hiddenHttpMethodFilter" class="org.springframework.web.filter.HiddenHttpMethodFilter"/>

    <bean id="blPreSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
        <sec:filter-chain-map request-matcher="ant">
            <sec:filter-chain pattern="/**" filters="
               openEntityManagerInViewFilter,
               blAdminRequestFilter"/>
        </sec:filter-chain-map>
    </bean>

    <bean id="blPostSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
        <sec:filter-chain-map request-matcher="ant">
            <sec:filter-chain pattern="/**" filters="
               hiddenHttpMethodFilter,
               blPrecompressedArtifactFilter,
               blAdminSandBoxFilter"/>
        </sec:filter-chain-map>
    </bean>

Previously, @jefffischer I think you had merge configuration to handle comma-separated lists like this within a bean definition. Since we've now moved away from default.properties this syntax probably doesn't work anymore (if someone wanted to add their own filter).

Thoughts?

Keyword search is not working in 3.0 Beta

From the heat clinic demo, type in sauce in the keyword search field and hit enter. No results are displayed.

RecordOfferUsageActivity needs to configure Rollback State and create a Rollback Handler

org.broadleafcommerce.core.offer.service.workflow.RecordOfferUsageActivity assumes that it is included in a larger Transactional Context. However, this is often untrue for a Checkout Workflow. The Checkout workflow by default should assume each activity as Transactional and provide a Rollback Handler for each activity.

broadleaf-profile-web project not generating sources

Refactor resolveFulfillmentType(sku) in FulfillmentGroupItemStrategy to take in DiscreteOrderItem

refactor the method signature of resolveFulfillmentType(Sku) in FulfillmentGroupItemStrategy to pass in a DiscreteOrderItem so that you can resolve against any extensions of DiscreteOrderItem as well as DiscreteOrderItem.getSku()

Simplify TaxProvider API. Remove cancelTax method.

Cancel and refund taxes is only possible when we start moving into OMS land. For now, remove any methods that are related to cancellation or returning of taxes. These will likely need to be added back in, or provided in a different interface once we provide functionality to cancel or refund orders.

Field names are not being replaced with . when submitting a post in the admin

The JSFieldNameCompatibilityInterceptor isn't invoked in time for the property names to be replaced correctly in a POST

Add "translation" support for BLC locales

Indexing every supported locale in SOLR is inefficient and not very practical. Instead, lets add a field to BLC_LOCALE to indicate that it should be utilized for translations. For example, in heat_clinic we will only index "es", "en" and "fr".

When evaluating a LOCALE during the search phase. We will see if it that LOCALE is translatable for search. If it is not and it is a typical country/language (e.g. en_US) then we will search for the root locale (e.g. "en"). If still not found, we will search without a locale (e.g. default site values).

PaymentInfoDetailType should be a BroadleafEnumeration so that it can be extended

@Jerry77oz The PaymentInfoDetailType is a Java enum. Shouldn't it be a BroadleafEnumeration so that it can be extensible? If not, we need to add an enum value called "SETTLED".

REST api needs to utilize Broadleaf Filters in a way that does not rely on the session.

The blTranslationFilter and blRequestFilter are needed for REST api processing. By default these filters rely on the session to manage state. In a RESTful context they will need to not create a session.