A bit belated, but I ran into the same issue. Thanks for figuring out that it was some post-processing that effectively undid the capture logic; I was trying to figure out why it seemed to be doing the right thing when I stepped through the code, but the database changes weren't there later.
My solution was to add a custom admin action to mark orders as shipped; this doesn't trigger the same post-processing, so the capture_on_ship_listener runs, makes its changes and that's it. Works fine. --rbt On Monday, May 21, 2012 12:02:25 PM UTC-7, Matt Rowe wrote: > > Hi list, > > I'm hoping you can help with this issue. > > I'm working on a Braintree processor that works with authorizations. > I'm using the capture_on_ship_listener to run the > "capture_authorizations" function in payment/listeners.py. I believe > my processor is working correctly: when the status is set to > "Shipped," then the order authorization is verified, and set to > complete. > > This is all great. However, there is additional form handling that > comes along and overrides the OrderAuthorization _after_ the signal > has been triggered. It's setting the OrderAuthorizations according to > how they were displayed in the form on the admin page. So, if I don't > manually select the "complete" checkbox in the OrderAuthorization, it > gets reset to the existing state. > > Is there any way around this? Any ideas? > > Thanks, > Matt -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/satchmo-users. For more options, visit https://groups.google.com/d/optout.
