EventContext

kingboyk wrote:

If I'm wrong and that property is always set then indeed the setter would be the perfect place to do it.

The point, though, is that *I* don't want to be raising events anywhere. I shouldn't have to touch the Nop code. The EventContext is there to provide simple API access to key events and the point of the thread is to encourage Andrei to add a suitable event :)

You should add a new OrderPaid event to EventContext and just raise it into the following methods:
1. OrderManager.MarkOrderAsPaid()
2. OrderManager.Capture() (check whether processPaymentResult.PaymentStatus==PaymentStatusEnum.Paid before raising the event)
3. and OrderManager.PlaceOrder() (check whether processPaymentResult.PaymentStatus==PaymentStatusEnum.Paid before raising the event)

Thanks Andrei. I'll add that in our copy, will you add to the trunk copy?

Also what is the value of the enum if unpaid? 0?

kingboyk wrote:
Yes

kingboyk wrote:
It can be any other value except 30 (PaymentStatusEnum.Paid). By default it's 10 (PaymentStatusEnum.Pending)

Thanks Andrei, you're a star.

nopCommerce team | a.m. wrote:
I'm wrong. It can be any other value (see PaymentStatusEnum enum)

Righto.

See changeset 57552

I'm wondering if it might be better to raise the event (or probably better still raise an additional event) whenever the payment status changes, so that plugins can also be informed when a payment has been rejected? Yes, I think keep OrderPaid as that's nice and easy and will suit most folks but consider adding an event which informs us of any change in payment status?

I'm going to have a scenario soon where I will not be turning features ON when paid, but turning them OFF if payment fails. (That's if I can do recurring payments at varying rates - may have to write my own solution for this).

Thoughts Andrei and/or anyone else?

There's already a work item on CodePlex to add more events to EventContext.