Validate store presence on orders#935
Conversation
|
A-ha! If I just make sure the |
|
Let me rebase this, the commit comment is still a bit off. |
|
I'm good by this too, as going forward it would be nice to count on an order having a store. The original migration set up the store_id on orders set them so we should be good to count on this usually being there: 15df7e7 👍 |
|
Oh no. So validating |
|
Take away your thumbs @jhawthorn @cbrunsdon, this needs to be reevaluated. |
|
👍 |
|
@tvdeyen Thanks for the |
|
@mamhoff This looks good to go. Could you please rebase so we can merge this in? Thanks! |
|
Rebased! |
|
Github is showing conflicts again. Could you give it another rebase please? |
I need to make some behaviour dependent on the store an order is associated to. Under normal circumstances, the order helper takes care of that in 100% of cases. However, there's no presence validation on the store, and for the feature I'm envisioning (Differing default taxation depending on which store you access) I need every order to have a store. The validation has to be on the `:order_id`, as just validating `:order` will usually pass because `Spree::Store.default` returns a new, invalid store if none is there. This entails a lot of spec setup changes, mostly to make sure a store exists.
Solidus 1.3 will not work well when it encounters an order with no store set. This commit adds a changelog saying that and as well a sample rake task that fixes up orders for relatively simple shops. Also, it introduces a task `solidus:upgrade:one_point_three` which can be hooked up with other data migration tasks we might need.
|
Rebased |
|
👍 From me. Also, very much appreciate the Rake task. |
|
Could you please try to use In Rails 5 this will be default and should work here. Not shure about the Either way 👍 |
|
Nope, that doesn't work as it generates a I could look into |
Validate store presence on orders
I need to make some behaviour dependent on the store an order is
associated to. Under normal circumstances, the order helper takes care
of that in 100% of cases. However, there's no presence validation on
the store, and for the feature I'm envisioning (Differing default taxation
depending on which store you access) I need every order to have a store.
This PR should be a point of discussion as to wether we want to actually validate
this.