The problem here is at the OrderItem level. The item gets first
created by the payment module, specifically by
payment.utils.update_orderitem and is created with the right price:
the trial price, and gets marked with the subscription details by a
call to payment.utils.update_orderitem_for_subscription.

This brings to my attention yet another problem here, which is the
high coupling level between the payment base app and a supposedly
"independant" product submodule. I have the feeling that this
processing should be delegated somehow to the product module, because
a 3rd party product module could also need to intervene in the
creation of the OrderItem objects.

But besides that point, the thing is that AFTER the original creation
of the OrderItem (right after, as a matter of fact) the call to
order.recalculate_total ends up in a call to this:

adjustment = get_product_quantity_adjustments(lineitem.product, qty=qty)

and this "adjustment" object ignores the subscription product, and
just uses the original product's price, so the Oreritem's price gets
updated to that.

Now, I really wonder, has really no one ever used this, and has gone
unnoticed for so long, or, more probably, am I doing something utterly
wrong and I haven't figured it out yet?

Tomas

--
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.