We need the following base fields added:
- default (boolean) (Done)
- currencies (entityreference of allowed currencies) Reverted due to the new store/product architecture.
- address
- available_countries
And the following configurable fields, added to each store bundle:
- registrations (list of country codes where the store is additionally registered to collect tax) -> add this via commerce_tax
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | Screen Shot 2015-07-07 at 1.36.55 PM.png | 109.07 KB | bojanz |
| #9 | Screen Shot 2015-07-07 at 1.33.01 PM.png | 132.29 KB | bojanz |
Comments
Comment #1
googletorp commentedDo you think it's a good idea to store the default store on the actual store entity? I don't think it makes sense to store that information on the actual store, since it's a bit redundant (we can only have one default store anyways). Also if something bad happens, or with custom SQL - we can end up having multiple default stores.
I'm thinking that it would make more sense to save the this information as a setting instead.
Just my 2 cents.
Comment #2
bojanz commentedWe can potentially have an unlimited amount of stores.
So there's no store selector that can scale on a settings page (other than some kind of an autocomplete which doesn't feel optimal).
That's why I wanted to have the default flag on the individual store, feels easier UX wise.
EDIT: I misunderstood googletorp. It makes sense to have a default checkbox on the store that sets a global setting. That means we don't need to do an entity query to find the default store, and we don't need to update other stores when one changes.
Comment #3
vasikehttps://github.com/commerceguys/commerce/pull/168
pull request : Currencies field, default store config, fields re-ordering.
Comment #4
googletorp commentedIt looks like this does what we want, haven't actually tested the code, but it looks right.
Comment #5
vasikeComment #7
bojanz commentedUpdated the issue with the latest plan.
Comment #9
bojanz commentedRelabelled and reordered the form, added the address and countries fields.
Also made the form fields UI-alterable. Attaching screenshots.
The registrations one will be added in a separate tax specific commit/issue.
Comment #10
bojanz commentedJosh had a valid point on Twitter: https://twitter.com/joshtaylor/status/618570795711774720
Wanted to clarify the reasoning behind the countries field, so that we can use it for further UX improvements.
In Commerce 1.x if you wanted to remove a country from the list, you'd usually edit the addressfield and the "Available countries" setting there. This allowed you to choose which countries you sell to / ship to. It also allowed you to have different country lists for the billing and shipping address fields.
In 2.x this approach no longer works because those fields can be used via multiple stores, and each store can reasonably have its own country list. This is why the Address module has both an "Available countries" field setting and an event thrown which allows modules to alter the setting, taking the store value instead, for example.
The idea is that commerce_order would respond to the event and offer the store country list for both billing and shipping fields. So if you removed NZ, it would disappear from both the billing and shipping selectors.
The same pattern can be seen in Woo Commerce, Magento and it also applies to both addresses there. Of course, the developer can still implement the event on its own and offer shipping-only/billing-only tweaks.
As an alternative, we can apply $store->countries only to the billing address field, and make sure shipping creates its own field.
We'd need to figure out how to label / explain both of these ("Billing countries" and "Shipping countries"?). There's also the problem of copying ("Ship to the billing address"), since you might try to reuse an address with a forbidden country. We'd need to make sure the validation covers that.
I think that makes sense, we just need to figure out the UX.