order state changes are not persisted

[frisi]

when using the shop administration view http://localhost:8080/Plone/@@orders to mark oders as payed or done the settings are not persisted.

just reload the @@orders view and you'll see the old status information again.

seems the changes made in bda.plone.orders.browser.views.Transition are not saved into the database

[rnixx]

i did some research on this issue -> changes done by six payment complete are persisted, underlying node.ext.zodb and souper packages working as expected, but somewhere in the execution chain of the ajax action the object looses it's data manager (or never gets one). further investigation required

[frisi]

i doubt it's a problem with the ajax action and that it works for the six payment.

all the six payment does is call payment.succeed which then fires an PaymentSuccessEvent

the event handler bda.plone.orders.common.payment_success will then set salaried=yes in case the payment object is a six_payment.

if i adapt the handle to mark invoce payments on succeed, too (see below) @@orders will list the fresh order as "not payed" too.

def payment_success(event):
    #if event.payment.pid == 'six_payment':
    data = event.data
    order = get_order(event.context, event.order_uid)
    order.attrs['salaried'] = 'yes'
    #order.attrs['tid'] = data['tid']

[rnixx]

i'm willing to bet this works in a production instance. @agitator ?

[frisi]

had a chat with @agitator . on his setup the six payments are indeed marked as salaried.

this worked because the event handler did not just set salaried to yes but in addition added another key to the item in the soup: tid

if i adapt the event handler to simply add a new key/value pair changes are persisted:

def payment_success(event):
    order = get_order(event.context, event.order_uid)
    order.attrs['salaried'] = 'yes'
    order.attrs['foo'] = 'bar'

so the problem seems to be that "the soup" does not recognice changes on it's items properly

[rnixx]

As workaround you can delete the existing attribute from record before setting, anyway this needs to be fixed in souper.

We have the same problem when overwriting state and salaried on order and booking records.