Adding an Account ID to Shipping Object on Cart is Not Prefilling the Shipping

[osseonews]

I'm not sure if something changed in the API, but I'm pretty sure that in the past when we added an account_address_id to the shipping object in a cart (PUT cart endpoint, {shipping: {account_address_id: ACOUNTADDRESSID}}, the cart then pre-filled the address from that address ID into the cart shipping object. This happened automatically immediately after the account_address_id was added to the cart shipping object. But we are running into situations now that this simply does not happen. The Cart has the correct Account_Address_Id on the shipping object, but the shipping address is simply not displayed on the cart, just the account_address_id. Is this the intended outcome now? In order to get the proper shipping address on the cart, we now have to actually PUT the entire address into the cart shipping object and sending in the account__address_id no longer has any effect?

[osseonews]

So as a follow up to the above, we located the precise bug. The issue is that if you add a shipping address to an Order in the admin dashboard, and that order is associated with a customer, there is no new address created for the customer or any new address at all. The dashboard simply pre-fills the shipping address fields without actually creating an address. This causes bugs per below. The solution would be to make sure that whenever an address is added to an order on the dashboard that is associated to the customer, that the address is added to the customer/addresses (actually save the address, and then associate it with a customer).

So what's the bug (and this happens frequently, as a customer service agents needs to add/fix addresses to orders on the dashboard):

1. Customer adds an address to the cart on the frontend, this is accomplished with frontend SDK assigning the account_address_id to the cart on the frontend. This works fine.

2. Customer calls up and needs some changes to an address, for whatever reason. Customer service agent fixes the address on the order. but since this fix doesn't register a new address, the account_address_id on the cart remains the same as previously in step 1, and there is no new address

3. On front end, customer is confused. They called to change the address, but when they go to the frontend, the new address doesn't show up b/c there was no address created. On the backend, the account_address_id is the same as step 1, even though the address was changed?

4. There is no way to change the address anymore on this order, by changing the account_address_id, every attempt to change the account_address_id will do nothing. The address entered in step 2 remains the address.

So in sum, manually adding a shipping address to an order via the dashboard, overrides any value that is from the account_address_id in the shipping object. This doesn't make sense, b/c the account_address_id should be what determines the shipping address for the order. I assume this is an issue b/c Swell runs on Mongo and there is no concept of a Foreign Key, so that the account_address_id isn't really meaningful. In which case, you need to add some precautionary code here so that the shipping address on the order, actually corresponds to the account_address_id, or else there are potentially many bugs that can occur.

[ericingram]

Thanks for the details. This appears to be a bug, but we'll investigate to be sure. The intended behavior is basically what you described.

A few specific things are supposed to happen:

1. If you update a record and set or change account_address_id, it will load address details into the shipping object, but if you also specify new shipping details in the same request, it will update the newly specified account address record as well

2. If you update a record with an existing account_address_id, it will update the existing account address record with new details

3. If you set shipping details on a cart/order where no account_address_id exists, it will create a new account address record with those details and put that ID in the shipping object

We'll follow up on what we find

[osseonews]

Thanks. So I've tested this alot and here is what I found:

1. If you send in an account_address_id via the API when you first create the order, it will fill the shipping details without a problem. Subsequently, sending in an account address id via API, will also update with no problems. The issue arises, if you then manually change the shipping address on the admin dashboard as the dashboard doesn't have any address book of any sorts, so you are just editing the shipping address fields on the cart. In that case, the cart address gets "frozen". Sending in another account_address_id will do nothing and the only way to fix the shipping address, is to actually send in the entire new shipping object.

2. Setting a shipping address on a cart via the dashboard, does not create a new address, nor does it assign it to the cart user (at least on the dashboard - I have never tried this via the API, so I don't know). You need to create the address separately, and then put the account_address_id to the cart via the API.

3. Updating the account_address_id will only work to update with new details, if the cart was never edited with a manual shipping address, per 1 above.

Our only workaround right now to the above is that we send in the entire shipping address to the cart on every update, as just sending in the account_address_id is simply unreliable. Many times, the address simply does not get updated when you send in new account_address_id.

[ericingram]

Very helpful details. We'll validate and prioritize a fix.

[SusannaSwell]

@osseonews for shipping prefilling to work, you will need to add "account_id" as well as account_address_id, account address needs to be associated to the particular customer to retrieve its shipping data. so request should look something like this

{
  "account_id": "accountId",
  "shipping": {
    "account_address_id": "accountAddressId"
  }
}