Writing a custom module should be at least as powerful as setting up a CA predicate

Here's a start towards this goal. I decided to put the hook implementations in ca.module on a whim. It won't bother me if they're put back in the modules that call them.

There are surprisingly few CA triggers in Ubercart. Most of them actually involve sending notification emails, and I haven't figured out yet what to do with them. A few were already associated with hooks, like updating the order status, so I left those alone. This left two triggers: uc_checkout_complete and uc_payment_entered

OK, that makes sense. I also figured that the uc_payment_entered trigger could use an $account variable as well, even though we don't have any conditions or actions using it at the moment.

From a feature request at the Ubercart.org forums, I've added a trigger that is fired when a shipment is saved. There was already a hook in that place, so it makes sense to have both there.

So, I got to wondering why I was always redirected to the cart page after I completed checkout. It turns out that uc_cart_checkout_complete() is already a function, but now module_invoke_all() is calling it again. That's not good, so I've changed the name of the hook to hook_checkout_completed().

OK, one more time. Ryan pointed out that the example hook_checkout_completed() had the wrong name, and we should be using clone when passing in the global $user object so that nothing bad happens to it.

Even with the way they're written now, shipping quotes don't use CA the same way that users are meant to. Even if you add extra actions to the quote predicates, they won't actually get run. It doesn't seem like the same kind of use-case that makes Rules integration natural. Now, I could implement Rules the same way here, and probably will eventually, but it will probably be with the same kind of customization prevention that's already in place.

Ryan thought it would be a good idea to name the new hooks after the CA triggers they are associated with.

andreiashu, I'd like for both the hook function and the conditional actions to have the same access to the payments on an order. The real solution, I think, would involve adding data to the $order object in uc_payment_order('load'), but that's really out of the scope for this issue. However, you can run a database query to get all of the payments on an order or call db_last_insert_id() in your hook implementation yourself.

Committed.