I'll have to speak to Rusty, but I'm pretty certain it's one wishlist and one basket per customer. I'm not sure how or why you would need multiple per customer?

Hey Lee,

Thanks for getting back to me, I see it may be a slightly bespoke requirement but just as an example of its usage; say you're a regular customer of a supermarket and you have your regular weekly shop saved as a basket so you can just hit reorder. Then say once a month you have another list of items that aren't required on a weekly basis that you can save to another basket, does that make sense? This could be handled in custom code/db table, I was just wondering if Merchello did support the functionality of multiple saved baskets/wish lists first.

Cheers, Tom :)

Ah ok I'm with you. As far as I know, this isn't supported (As you say it's a bit of an edge case scenario) but I'll wait for Rusty to come on here later or tomorrow and confirm whether I'm talking rubbish or not ;)

We did design Merchello around the use case that a Member would need different sorts of persisted item (product) collections.

Baskets and wishlists contents are stored in tables named merchItemCache and merchItemCacheItem - you can think of it as a container record and line items records.

The thing that identifies them is the itemCacheTfKey (type field key - which is just a made up GUID key). The entityKey in the merchItemCacheTable would in this case be the merchCustomer.pk (foreign key) to associate the collection with the customer.

They each are represented as a class that inherits from CustomerItemCacheBase https://github.com/Merchello/Merchello/blob/merchello-dev/src/Merchello.Web/Workflow/CustomerItemCache/CustomerItemCacheBase.cs (e.g. Basket : CustomerItemCacheBase and WishList : CustomerItemCacheBase)

So, in the inquiry above, you could create a class named ShoppingList which inherits from CustomerItemCacheBase and give it a some new GUID (which would be a constant reference to designate the ItemCacheType is a a ShoppingList so it can be retrieved quickly) - and then build out the transfer methods - to dump everything in the list to the basket on the reorder.

There is a configurable validation chain that you might also want to look at (probably replace the default tasks to not remove items - probably rather drop and re-add them with any product changes like pricing). Tasks are listed in execution order in the Merchello.config:

       <taskChain alias="ItemCacheValidation">
  <!-- Added Merchello Version 1.11.0
  This chain validates basket and wish list items against values in the back office to assert that the customer has not
  added items to their basket that were subsequently changed in the back office prior to checkout.  The process is needed
  as the relation between the basket and wish list items are decoupled from the actual persisted values.
  -->
    <tasks>
        <task type="Merchello.Web.Validation.Tasks.ValidateProductsExistTask, Merchello.Web" />
        <!--
            The following task is intended to assert that pricing and/or on sale value has not changed in the back office since the
            customer has placed an item into their basket or wish list. If you have made custom pricing modifications in your
            implementation, you may either remove this task or adjust your code to add a new extended data value
            merchLineItemAllowsValidation = false
            to the line item so that it is skipped in the validation process.
        -->
        <task type="Merchello.Web.Validation.Tasks.ValidateProductPriceTask, Merchello.Web" />
        <!--
            Validates that products are still in inventory
        -->
        <task type="Merchello.Web.Validation.Tasks.ValidateProductInventoryTask, Merchello.Web" />
    </tasks>
  </taskChain>

It should also be pretty simply to check the ItemCacheTfKey to in the task to determine if this validation is actually relevant to the item cache being validated ... basic condition that returns a Attempt.Success to allow the chain to continue.

At one point, I built a wedding registry where I used a custom ExtendedData value to designate whether or not an item has already been purchased using this method.

I've never tried, but can't think of a reason why multiple collections with the same entityTfKey could not be created from a database perspective. However, as of Merchello 2.2.0 there is no method on the ItemCacheService to retrieve a collection of IItemCache, but customer and entityTfKey as it assumes that there will be only one.

I've added a task here and will try to get it into the 2.3.0 release. I'll keep the task updated on the issue list with progress or any problems ... I have to make sure the basket conversion strategies will not break =) http://issues.merchello.com/youtrack/issue/M-1101

Another gotcha is the CustomerItemCacheBase assumes there will be one set of data for each customer for each entityTfKey ... so I know a new class that does not inherit from CustomerItemCacheBase would need to be created to the container of the "multiple saved baskets".

Something like:

 public interface ISavedBasketCollection
 {

      IEnumerable<ISavedBasket> Baskets { get; }
 } 

 // The derived type of ISavedBasket could inherit from 
 // CustomerItemCacheBase as the ItemCache object is passed
 // in the constructor 
 public interface ISavedBasket : CustomerItemCacheBase
 {
 }

is working on a reply...