I finally posted the proposal for dynamic price pre-calculation after deleting it on accident once and then traveling home from a week in Michigan. : P

Focusing on the need to populate a table with data based on Rule applicability, I neglected to specify precisely how we would determine which Rules apply to which prices, what module would contain the code, and how these prices would then be displayed. Part of the problem is that dynamic pricing itself wasn't complete - there is a price object and Rules to manipulate it, but the calculated price doesn't appear anywhere. : )

So, this issue here is something of a meta-issue and will be broken apart as necessary. The gist of it is we need the following items resolved before dynamic price pre-calculation can happen:

  1. Convert the Price altering actions to use a line item instead of a price object.
  2. Find an appropriate home for the Rules event (right now it's in Price, but that won't do based on module dependencies... my hunch is Product Reference will have to do it unless we abstract it out to Line Item).
  3. Determine what entities have prices that need to be dynamically calculated (see, the line item has two price fields, products will have one or more, and none of these will be displayed in the same way).

The actual task of knowing what price needs to be dynamically calculated, finding the applicable Rules, and populate the commerce_calculated_price table isn't that difficult once the other pieces are in place.

Comments

rszrama’s picture

rszrama CreditAttribution: rszrama commented
Status: Active » Needs work

This commit primarily addresses number two but by extension takes care of number three. The way it played out was code that depended on building product line items needed to stay in the Product Reference module. This is the module that defines the product line item type, and it's also the module that handles displaying product fields in nodes where a user will need to see a calculated sell price anyways. So, the event was moved there and the interaction with the Price module comes through the use of hooks (that need to be documented):

  • hook_commerce_price_field_calculation_options() - tells the Price module that a particular instance of a price field has an option for dynamic calculation; otherwise price fields will default to always display the original price.
  • hook_commerce_price_field_formatter_prepare_view() - now, this is clutch... the calculation of a dynamic price doesn't need to occur on every load; if no calculation has been requested, a field doesn't need all the extra data lying about... the extra data can always be generated or retrieved at the point where it's actually needed (like when adding a product to the cart and wanting the customer's actual purchase price). So, this hook is really just an extension of hook_field_formatter_prepare_view() for the price field. Modules implementing this hook are directly altering the $items array prior to display; in the case of dynamic sell prices, we're checking to ensure a cardinality of 1 (among other things) and just swap in the unit price from the pseudo line item that was passed through Rules to calculate the sell price.

Those names suck, but I don't know how to shorten them without making them more confusing. Wanted this to land, and then will run through and update all the old actions to work directly on the line item unit price instead of a random price object. We will need to log changes to the price's data array somehow in the future.

Oh, and it's worth noting that this system is extensible, so other modules can let the Price module know they govern other calculated price fields just the same.

https://github.com/rszrama/drupalcommerce/commit/568560f01377332df756d67...

rszrama’s picture

rszrama CreditAttribution: rszrama commented

And now number one is nailed as well:

https://github.com/rszrama/drupalcommerce/commit/32f13e97ad74bda89ca2bf7...

(Also, in case anyone is keeping score, the Product Reference Rules include file got bypassed on an earlier commit. If you're looking for it, it's in this commit.)

rszrama’s picture

rszrama CreditAttribution: rszrama commented

Just a note that the first go at a database table and API level support for figuring out all the permutations of Rules / products to pre-calculate prices for is in this commit:

https://github.com/rszrama/drupalcommerce/commit/08b2a82b3fe7e0139fb4a82...

I still need to figure out how to execute only the actions from a subset of the available Rules for the event...

rszrama’s picture

rszrama CreditAttribution: rszrama commented

And with this commit, the API function is actually saving to the database. Holy smokes, I think it works!

https://github.com/rszrama/drupalcommerce/commit/068a9ec76bb744adef0e1b4...

Now it just needs a UI and View integration. : D

rszrama’s picture

rszrama CreditAttribution: rszrama commented

Ok, got a little bit of the UI in, but I've realized I need to do some API refactoring to enable batching of sell price calculation and to get some queries out of the form builder / submit handler functions. After that I'll just need to implement basic Views support and call it beta ready.

https://github.com/rszrama/drupalcommerce/commit/c03ea5b8d3b6f7734d2046f...

rszrama’s picture

rszrama CreditAttribution: rszrama commented
Status: Needs work » Fixed

Actually, I think we can safely consider this ticket closed. I'm going to spawn a few child issues that pertain to integrating pre-calculated prices into Views and to improving the API / UI, but the actual task of performing the calculation has been accomplished.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.