Specific notifier question - experts please!

[wilt]

In terms of the IPN application top, yes it is something we have discussed in terms of bringing it into the init_system structure rather than using custom code.

It should be noted as well, than even Paypal EC still has a dependeancy on the IPN handler for things like echecks

[s_mack]

Ok, I think I have an idea... feel free to shoot it down :)

Here's the logic... in a "regular" (non-paypal) order, at some point the function "create" within the order.php class is called and (I think) it generates the order number. That same function is called from the ipn_main_handler.php file!

So can't we put a notifier inside that function? right after an id is generated?

- Steven

[DrByte]

since you're doing stock mgmt, you'd be better advised to intercept the $order->create_add_products() call.

In this case, you already have access to these notifier points:
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_END');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_CREDIT_ACCOUNT_UPDATE_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_ATTRIBUTES_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_ONE_TIME_CHARGES_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_AFTER_ORDER_CREATE_ADD_PRODUCTS');

[DrByte]

The problem is that the ipn_application_top doesn't have any of the functionality in it to load the custom notifier classes. Thus, even though the notifier points may exist and be fully functional via normal order-creation activities, the IPN subsystem doesn't have all the additional support present, and as such has no knowledge of any extra work it should do to follow actions in the defined notifier points.

[s_mack]

since you're doing stock mgmt, you'd be better advised to intercept the $order->create_add_products() call.

In this case, you already have access to these notifier points:
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_END');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_CREDIT_ACCOUNT_UPDATE_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_ATTRIBUTES_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_ONE_TIME_CHARGES_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_AFTER_ORDER_CREATE_ADD_PRODUCTS');

Yeah... I started with that and ran into a problem. Can't recall right now what that was though... hmm.

This part of the code isn't really doing any stock management per se though. Here, I'll tell you what it does do:

A customer previously came on and found an item that was out of stock, so instead of a "Add to Cart" or "Sold Out", they see "Request Item". That adds an entry to the DB so I know that item is wanted. When the item comes in, I add it to stock like normal, but one of them is made invisible to normal customers and is "on hold" for that particular customer. Its quite slick really. Everything works well right up until the customer who has it on hold purchases the on-hold item... at this point, I want the on-hold status to be removed. In order to do that though, I need to know what they bought...

so here we are. What my observer does (or rather... is trying to do) right now is listen for when the order_id is generated so that I can look up what was purchased and match that against the HOLDS table.

Now to mess with this even further, my stockManger also allows complete use of attributes too... and that could be why STOCK_DECREMENT doesn't do me any good... I can't remember exactly what was wrong there - it was a couple months ago. Since the core code only handles stock without attributes, its quite likely that was the reason I can't use that notifier. I would still need to know the order_id to look up the products AND attributes in order to remove the HOLD.

Does that make any sense at all?

My store has a large contingent of "special order" items... items I want to offer for sale, but that I don't (and won't) keep in stock. It was becoming unmanageable handling all the manual "can you bring this in for me" requests by email so I allowed people to order out-of-stock items... but then that really commits me to bring the item in, and depending on the number of requests and/or who the supplier is and their current situation that may not always be possible so that didn't work. Also, I didn't like taking people's money 60 to 90 days before the product arrived.

To solve this, I devised this Request/Hold system. And it works very well... save for this little quirk where I can't automatically remove the hold from the system after a PayPal order.

- Steven

[s_mack]

The problem is that the ipn_application_top doesn't have any of the functionality in it to load the custom notifier classes. Thus, even though the notifier points may exist and be fully functional via normal order-creation activities, the IPN subsystem doesn't have all the additional support present, and as such has no knowledge of any extra work it should do to follow actions in the defined notifier points.

Ok, I think I get that now... but then how would I use those notifiers you mention above? Aren't they still under the same umbrella? The system still wouldn't be aware of those either with a PP order if I understand correctly.

- Steven

[DrByte]

Ok, I think I get that now... but then how would I use those notifiers you mention above? Aren't they still under the same umbrella? The system still wouldn't be aware of those either with a PP order if I understand correctly.

- Steven

As things exist today, that is correct

[DrByte]

Thanks for the explanation. Given the fact that you wish to manage the stock status "after" the order has been "fully" created, I would suggest not using the create_add_products notifiers anyway, as those notifiers are triggered on each line-item insert into the database.

It would be better to do something later on, either in the send-email routine or maybe yet a separate call altogether ... as you mention, you need to pass the order number to it anyway.

[s_mack]

As things exist today, that is correct

Ok, thanks for confirming that.

Thanks for the explanation. Given the fact that you wish to manage the stock status "after" the order has been "fully" created, I would suggest not using the create_add_products notifiers anyway, as those notifiers are triggered on each line-item insert into the database.

It would be better to do something later on, either in the send-email routine or maybe yet a separate call altogether ... as you mention, you need to pass the order number to it anyway.

Sounds like a plan.

Now that I have a good local PP testing ground to work with (thanks for that too ;) ) I'm going to find a way to do this. If y'all are interested, I'll update with my solution when I find it. Maybe it'll give you something to work off of for a future release.

- Steven

[DrByte]

Ok, I think I get that now... but then how would I use those notifiers you mention above? Aren't they still under the same umbrella? The system still wouldn't be aware of those either with a PP order if I understand correctly.

The extra support layer could be coded... it's essentially a matter of duplicating some of the functionality of the init_system infrastructure into ipn_application_top.
Sounds easy to "say" that ... but writing it ... hmmm ...