Related to Spree upgrade. state field has been added to adjustments, and does not seem to be playing perfectly with OFN yet.
Steps to reproduce.
Site will crash due to the following error:
NoMethodError spree/admin/orders#update
undefined method `state' for nil:NilClass
Stacktrace :
app/models/spree/order_decorator.rb:351
````ruby
def update_adjustment!(adjustment)
state = adjustment.state
聽 adjustment.state = 'open'
聽 adjustment.update!(self)
聽 adjustment.state = state
````
I never worked on this one, so unassigning myself (and Rob won't either). You might have a better picture after your work on adjustments @luisramos0 . Any feedback about that state field?
I dont think this issue is up to date.
I am not sure this is being applied:
app/overrides/spree/admin/orders/_form/relabel_update_button.html.haml.deface
the code now looks like this:
def update_adjustment!(adjustment)
return if adjustment.finalized?
state = adjustment.state
adjustment.state = 'open'
adjustment.update!
adjustment.state = state
end
We can get back to this when these are closed: #2935, #2938, #2940, #2941
I did some investigation around this issue.
Edit shipping adjustment is not possible. The adjustment amount is correctly updated on the DB but the an order.update is triggered and that updates all the adjustments and, because the shipping adjustment is OPEN, the value is reset to the original shipping method cost.
In v1 this recalculation only happens when in the order details page, when the button "update and recalculate fees" is pressed, if the shipping fee was edited by the user, the shipping feee is reset to the base shipping method cost. I think that's how it should remain in v2. I am not sure how to fix this... we probably need to set the shipping adjustment to closed after the controller updates it.
It works in v2 like in v1.
The difference to the shipping fee is that in the adjustments edit page, the shipping method adjustment is open but the payment_method adjustment is closed. So, when the payment method value is updated, the order.update gets triggered but because the adjustment is closed, it does get reset to the origin payment method cost. However, as in v1, this value gets reset when user presses "update and recalculate".
Delete the shipping adjustment doesn't work, the shipping feee gets re-added not in the adjustments page after deleting but when after if user loads the order edit page. This is probably related to the workflow being progressed automatically in the order edit page.
Deleting the adjustment related to a payment fee works correctly, and it gets re-added when "update and recalculate" is used. I am not sure this is the behaviour in v1, but I think it is.
In the v2 order adjustments edit page, the adjustments state is displayed and can be edited, this is not showing up through the current deface. What we have from v2 are the buttons "open/close all adjustments".
Option 1 - remove possibility of user to change adjustments state like in v1 - much easier (it's one line to remove the buttons with deface)
Option 2 - add new state field to list and edit form and make it work, this probably means the total de-defacing of the page into a OFN view
We also need to manually test these pages for:
Quite a few things todo here... any takers? @sauloperez @mkllnk
Edit Shipping Fee - broken
The button to Update and recalculate fees was a workaround for fees that were not adjusted when removing or adding line items. Maybe if we now have a working dependent-destroy for the fees then we don't need to call the re-calculate any more?
Edit Payment Fee - works
I'm not clear how this should actually work. So if somebody paid by credit card there may be a fee on that depending on the amount. If we now add or remove items the fee has been charged and should not change. If the payment has not been made it should be updated, I guess.
I implemented the payment fee and just tried to mimic the shipping fee. When we came to this problem, we thought it's good enough and wait for feedback if there is an issue.
Adjustments State - needs adaptation
Definitely option 1: remove the possibility. Let's not introduce a feature no-one asked for. I'm already wondering how much of the other flexibility here is actually needed or if we can remove functionality here.
I agree with option 1. It's been the general idea for v2 so far.
I'll need to reread this to fully understand each case but there are still things on my pipe that I want to close first.
Adjustments State - Option 1 is now done in #3548
We still have the other points to discuss (or ignore!)
To get familiar with this issue I just retested this again. Unlike Rob's original description the app doesn't crash any more. But as Luis described, the shipping fee cannot be edited and if deleted, it re-appears when visiting the order details page. I'm wondering if we can close the adjustment to behave like the transaction fee. I will experiment with that.
I have a proposal to enable editing shipping fees: https://github.com/openfoodfoundation/openfoodnetwork/pull/3666
I think the deletion of shipping fees is a bit more complicated. I would not bother. As I mentioned in the pull request, I would add this to the user guide:
If you delete a shipping fee and look at the order details again, the shipping fee will re-appear. You can use this behaviour if you want to re-calculate the shipping fee. If you don't want to charge a shipping fee you can set the amount of the shipping fee to
0.
@RachL What do you think about a paragraph like that one in the user guide?
Otherwise we need to somehow remember if we created and deleted a shipping fee or if it has never been created. I guess we could do that depending on the state. We could try to prevent the shipping fee creation when the order is complete. I can look into that if you think it's important. But I worry that it will end up in some ugly Spree overrides.
I think you solution is awesome, specially because it's simple! I hope everyone agrees.
@mkllnk the paragraph sounds clear to me.
we need to add the paragraph to the user guide...