Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

order state changes are not persisted #1

Open
frisi opened this issue Mar 25, 2013 · 5 comments
Open

order state changes are not persisted #1

frisi opened this issue Mar 25, 2013 · 5 comments

Comments

@frisi
Copy link
Contributor

frisi commented Mar 25, 2013

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
Copy link
Member

rnixx commented Mar 25, 2013

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
Copy link
Contributor Author

frisi commented Mar 25, 2013

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
Copy link
Member

rnixx commented Mar 25, 2013

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

@frisi
Copy link
Contributor Author

frisi commented Mar 29, 2013

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
Copy link
Member

rnixx commented May 18, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants