How are subscription trials supposed to work?

[Tomas Neme]

I've been reported a bug where when you buy a subscription with a
trial, even though the trial price shows in product page and cart, the
full price is shown in checkout, and is charged. I have confirmed the
display issue, not the payment, yet.

I've so far figured out that this is because while the product page
uses the product/detail_subscriptionproduct.html template, and this in
turn uses product.subscriptionproduct.recurring_price (which takes the
trial into account), the checkout template (that ends up being
shop/_order_details.html) knows nothing of subscription products and
shows just unit_price.

Moreover, this unit_price is not a Product thing, but rather an
OrderItem element, that gets filled in at order creation with,
apparently, the "wrong" data. Even if this was not the case, I see no
way for the Order to create a recurring billing from this data
(there's a link to the original Product, of course). So, I wonder..
how is this supposed to work? I assume I'm doing something wrong along
the path, but I can't pinpoint exactly what.

I'd also like an explanation on how does the system ensure people
don't get the same free trial multiple times.

Thanks
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.

[Tomas Neme]

OK, so far I have discovered this.

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?