companionstudio / islay-shop Goto Github PK

The sku_price_logs table is going to be removed, since it's functionality is entirely replaced with the price points update.

The user should be able to add multiple assets, much as they can with products.

This needs to take into account the countries available for delivery, and restrict the delivery address options as appropriate.

They should be displayed pretty much everywhere in the catalogue. Overview, category, product and stock level indexes.

For example, when listing orders, have aggregate counts for things like total orders, pending, cancelled etc.

The same could be done in may other places e.g. promotions.

Categories can be nested, but we don't present a UI for managing this to the user.

At the moment it's undercooked. Badly styled and showing enough useful information. Some kind of report/overview of sales would be useful.

When updating a SKU, the validation failing (for example a missing value for Freight Class) will cause an invalid price point to be inserted into the form - in turn this breaks validate_boxed_and_bracketed_overlap or any other method which relies on sorting by volume.

Currently these codes are single use only, but it would be good to have them as single, multiple, or unlimited use.

They currently show the current month, and have logic for other date ranges, but there's no way to select them in the UI.

Sometimes the generated summary just isn't what's required. Simplest solution might be to just have a field which can override the whole generated summary.

For example, if two promotions apply free shipping, they will combine their discounts leaving the total with a negative amount. Basically, all line-items should be bound to zero at the lower end.

Currently conditions can optionally include a Hash of targets when returning a result via #check. This count is used by effects to decide the results of their application. For example, the Get N Free effect needs to know how many items qualify.

However, with some conditions there is a difference between the number of order items which are considered as qualifying and a count of qualifications. This is a subtle but important difference.

For example, consider the Quantity conditions. If we configure a condition that says buy at least 5 of SKU foo, and an effect which is 10% off each qualifying item.

• Customer buys 11 of SKU foo
• Condition check is successful
• Number of qualifications is one; the customer did buy at least 5
• Number of items qualifying is 11; all of them
• Discount effect knows it needs to apply the discount to all 11

Without this distinction between qualifying and qualifications, the discount effect would only know about the single qualification, not the count of items that were used to determine the qualification.

Here is a slightly more complicated scenario. A condition is specified that says for every 10 of SKU bar, and an effect that says $2 off each.

• Customer buys 25 of bar
• Condition check is successful; quantity is over the minimum of 5
• Number of qualifications is 2; 10 goes into 25 twice
• Number of items qualifying is 20; the extra 5 items are not qualifying
• Discount effect knows that it has to discount 20 items

Now, imagine the above scenario, but with a Get N Free effect. In that case the promotion described would be 'For every ten of SKU bar get one free'. In this example, the effect needs to know the number of qualifications, not the count of qualifying items.

It would be convenient if the user could optionally add a default SKU when creating a new product. This would save a bit of busy work.

Currently they're fired off inline with any order processing. This is a problem, since an exception when sending an email can hose an otherwise valid transaction.

Because of the condition scope, adding a code which applies free shipping won't work until there are shipping charges (which there often aren't, at the point a code is entered). For now, I'll just remove the condition scope, so we don't require shipping charges before applying the effect.

The decorator blows up when trying to produce a summary:

undefined method `sku' for #PromotionBonusEffect:0x007fc633cffa20

order and conditions keys need to be converted to the proc syntax

Promotions which have a shipping effect should have a corresponding condition which enforces:

a. Order has shipping service
b. Shipping total is greater than zero

Then the condition_scope for each could be defined as :shipping_service. The end result of this is that discounted shipping can only be offered when orders have shipping charged against them; avoids the nonsensical effect of discounting shipping that is already free.

Concerns fit the Rails 4 model better, and won't mess with the Autoloader.

When viewing details for a promotion, the user needs a way to get to the codes - either single or unique.

Looks like a regression from an update to SpookAndPuff::Money, which isn't a dependency of SpookAndPay. Islay Shop needs to check the payment provider and provide the right value (bit icky).

Currently the effect and condition loaders only consider files in the engine's code base. We need to allow including apps to provide their own and have them loaded.