Sync MC address during onboarding.

[asvinb]

Changes proposed in this Pull Request:

Closes #2602 .

Replace this with a good description of your changes & reasoning.

Screenshots (Onboarding):

The store address is invalid (missing info)

The store address is not in sync with MC

The store address is in sync with MC
(nothing is shown during onboarding in this scenario)

Screenshots (Settings):

The store address is not in sync with MC

The store address is invalid (missing info)

The store address is in sync with MC

Detailed test instructions:

1. Go through the onboarding flow.
2. The card to sync the store address should be visible if the WooCommerce street address is different from the MC address.
3. Clicking the "Refresh to sync" button should sync the WooCommerce store street address to the MC account.
4. If the address is/has been synced, the card should not be displayed.
5. The "Continue" button should be disabled if there are connected accounts but the store address has not been synced.
6. If there is no address in WooCommerce settings, the card should display an alternate text to prompt the user to add the address in WC settings.

Additional details:

Changelog entry

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.3%. Comparing base (4f5bb47) to head (49c26f0).

Additional details and impacted files

@@                               Coverage Diff                               @@
##           feature/2509-consolidate-google-account-cards   #2653     +/-   ##
===============================================================================
- Coverage                                           62.7%   61.3%   -1.5%     
===============================================================================
  Files                                                325     319      -6     
  Lines                                               5162    4958    -204     
  Branches                                            1265    1214     -51     
===============================================================================
- Hits                                                3239    3038    -201     
+ Misses                                              1746    1744      -2     
+ Partials                                             177     176      -1     

Flag	Coverage Δ
js-unit-tests	61.3% <ø> (-1.5%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
js/src/components/account-card/index.js	89.2% <ø> (-2.7%)	⬇️
.../src/setup-mc/setup-stepper/saved-setup-stepper.js	87.2% <ø> (-0.6%)	⬇️
js/src/setup-mc/setup-stepper/stepNameKeyMap.js	100.0% <ø> (ø)
js/src/utils/urls.js	52.6% <ø> (+0.1%)	⬆️

... and 1 file with indirect coverage changes

[joemcgill]

@asvinb this is looking pretty good. Only a couple of critical issues to address.

[joemcgill]

This hook cannot be used here until after the MC account is connected. Otherwise it will send an API request to /gla/mc/contact-information which will result in a 401 error.

Either we need to incorporate useGoogleMCAccount() into the useStoreAddressSynced() hook so that it returns false early if there is no MC account, or rely on a useState() value that gets updated after the verification is made.

[asvinb]

Thanks @joemcgill . Completely missed that 🤦 . I've updated the useStoreAddressSynced hook. Let me know what you think.

[joemcgill]

Instead of checking data.address here, which is only part of the address, it's probably better to check the data.isAddressFilled property, which checks for all required address fields. See:

google-listings-and-ads/js/src/hooks/useStoreAddress.js

Line 67 in 99408e1

const isAddressFilled = ! missingRequiredFields.length;

[asvinb]

With the recent changes in the hook, we are now using ! missingRequiredFields.length directly @joemcgill

[joemcgill]

The functional changes look good to me, except one note inline.

However, I noticed that the new design are slightly more streamlined, avoiding the separator between the Card description and the Address:

Old

New (ignore the missing button)

[joemcgill]

Adding this refetch is unnecessary, because updateGoogleMCContactInformation() returns the new data and updates the data store.

[asvinb]

👍

[joemcgill]

Thanks @asvinb.

Overall, this is working as expected for the onboarding flow. However, the need to add an additional compactStyles prop to render a style variation on the StoreAddressCard component made me curious about where else this component was used, and whether we could avoid the need to the prop entirely.

Turns out, the other place this component is used is in the EditStoreAddress flow that you can get to by visiting wp-admin/admin.php?page=wc-admin&subpath=%2Fedit-store-address&path=%2Fgoogle%2Fsettings or by clicking the Edit button on the StoreAddressCardPreview component shown in the settings screen after finishing onboarding.

In the develop branch, when you visit the EditStoreAddress flow, the Refresh button is used to update the component with fresh address data from the WC store that is shown in the lower Section.Card.Body, and the the "Save details" CTA button for that flow is what syncs the address to MC. After these changes, the refresh button does the syncing but then stays continually stuck in an updating state, see this video:

Screen.Recording.2024-10-29.at.3.39.10.PM.mov

Currently in develop the Refresh button similarly is used to update changes to the address that have been made in the WC store that aren't yet reflected in the component state and the address is synced to Google MC when that step of the onboarding flow is completed (see this code ref).

Suggestions

Here are my suggestions for how to address these concern. I can verify which option we want to go with, but would appreciate any ideas/feedback you have as well.

Updating the onboard flow

First, we should apply the new compact design everywhere to simplify the implementation and remove the new compactStyles prop.

Next, we revert the changes to the Refresh button so they are used to update the component with local data rather than sync the data to MC for a consistent UI in all places it's used. We can sync the changes to MC when the first onboarding step is completed, as part of the callback passed to the onClick prop of the AppButton here.

During onboarding, we should still only show this component if we either don't have valid address info or the address info doesn't match MC. However, since we'll now sync the data automatically whenever someone finishes this step, we should only disable the Continue button if there are any validation errors for the address (e.g., ! address.isAddressFilled) and show the validation errors in the StoreAddresCard similar to how it's being done in the EditStoreAddress flow:

<StoreAddressCard
  showValidation={ ! address.isAddressFilled }
/>

Alternate: Update the settings screen

An alternative suggestion would be to move the updated StoreAddressCard from this PR directly to the Settings screen—replacing the current ContactInformationPreview component here. With this approach, we would always show the address info (not just when it's different from MC), and the Refresh button would be for the purpose of updating the MC data.

The EditStoreAddress flow will no longer be needed and could be removed. The PhoneNumberCardPreview and StoreAddressCardPreview components could likely be removed entirely as well, because I don't think they're used anywhere else.

[joemcgill]

After confirming with @fblascogarma earlier this week, the approach we decided to go with for resolving this concern is to update the UI on the settings screen to make use of the redesigned StoreAddressCard and greatly simplify the UI there to remove the unnecessary phone verification data, and the edit store address flow. Those updates were implemented in #2661 and merged to this PR for finalization.

One additional issue that we've discovered is that currently when the onboarding flow is loaded, a request is made to mc/setup to return the step that should be started if requirements of the setup flow have already been completed. That logic is handled in the MerchantCenterService::get_setup_status() method (ref). This logic doesn't currently account for the need to check for a synced address before moving to the product_listings step so that will need to be resolved. I think we can add $this->is_mc_contact_information_setup() back to that logic, which previously existed as part of the logic to see if we could start on the paid_ads step.

[joemcgill]

@asvinb I've updated the rest of this PR after incorporating the changes from #2661 if you want to give it another look.

@mikkamp could you review the PHP changes specific to src/MerchantCenter/MerchantCenterService.php and the related PHPUnit tests?

@eason9487 this will still need QA, but would appreciate an early review since there are so many changes (mostly removal of unused components).

Concerns resolved

[eason9487]

Before looking into the code implementation, I would like to raise concerns about the new UI.

1. WooCommerce Settings and Google Merchant Center have different rules for required address fields, so there are often cases where required fields are missing when syncing to GMC.
   
   The UI doesn't guide the merchant through a clear correction process. For example, after a merchant updates the address via WC Settings and switch back, they will find this card is still stuck in the same error state there until they try to refresh the webpage and see the "Refresh to sync" button.

2. This card won't be shown after the address is synced or when the address already matches at the beginning. This will make it uncertain for merchants to know exactly how to (re)update the address to GMC.
   
   And even if the merchant is told how to update the address again, the flow will be less smooth than before. For example, starting with the screenshot above, the merchant must:

   1. Open a new webpage and navigate to WooCommerce Settings
   2. Update address and save changes
   3. Switch back to the webpage of Onboarding flow
   4. Refresh the webpage
   5. Click "Refresh to sync" button

3. A similar concern about insufficient guidance also occurs on the plugin Settings page.
   

   Kapture.2024-11-04.at.16.03.41.mp4

   For example:

   • The merchant may not know they need to refresh the webpage to see the "Refresh to sync" button after they update WC address
   • The merchant needs to refresh the page again and again if they find out they want to edit address again
   • If the merchant has to modify the address again due to something like a typo, they will find that they have to refresh the webpage over and over again

---

The following compares several scenarios: After a GMC account is connected, the operations required to reach the point where the WC address is synchronized to the GMC and continue to the next step.

Scenarios \ Comparisons	Before	After
When the two addresses are already the same	1. Click "Continue" button	1. Click "Continue" button
When the two addresses are already the same but want to edit it	1. Click link to open WooCommerce Settings 2. Update and save address 3. Back to Onboarding webpage 4. Click "Refresh to sync" button 5. Click "Continue" button	1. Open new webpage 2. Navigate to WooCommerce Settings 3. Update and save address 4. Back to Onboarding webpage 5. Refresh webpage 6. Click "Refresh to sync" button 7. Click "Continue" button
When the two addresses are different	1. Click "Continue" button	1. Click "Refresh to sync" button 2. Click "Continue" button
When a required address field is missing	1. Click "Continue" to be notified of the missing field 2. Click link to open WooCommerce Settings 3. Add and save address 4. Back to Onboarding webpage 5. Click "Refresh to sync" button 6. Click "Continue" button	1. Click link to open WooCommerce Settings 2. Add and save address 3. Back to Onboarding webpage 4. Refresh webpage 5. Click "Refresh to sync" button 6. Click "Continue" button
When the two addresses are already the same but want to edit an address field and later find a typo in the just edited field	1. Click link to open WooCommerce Settings 2. Update and save address 3. Back to Onboarding webpage 4. Click "Refresh to sync" button 5. Switch to WooCommerce Settings page 6. Correct and save address 7. Back to Onboarding webpage 8. Click "Refresh to sync" button 9. Click "Continue" button	1. Open new webpage 2. Navigate to WooCommerce Settings 3. Update and save address 4. Back to Onboarding webpage 5. Refresh webpage 6. Click "Refresh to sync" button 7. Switch to WooCommerce Settings 8. Correct and save address 9. Back to Onboarding webpage 10. Refresh webpage 11. Click "Refresh to sync" button 12. Click "Continue" button

That's why the original process was designed that way. It's not very convenient either, but at least the guidance is relatively clear and the operations are fewer and more consistent..

[eason9487]

Without introducing wider changes, whenever the merchant updates WC address, this whole mechanism always requires an action to display the address to be synchronized and maybe also display the errors to be resolved on this plugin page.

• (Re)fetch WC address and compare if it needs to be synced or if there are errors

Replacing this action with the updateGoogleMCContactInformation API call or hiding the UI that triggers this action under certain conditions probably wouldn't make the whole thing any better. At least the current implementation doesn't seem to make it any easier for merchants to use.

It's recommended to confirm if the concerns in #2653 (comment) are in the desired direction. I would suggest that the main direction could be to remove the phone number and merge step 3 into step 1, but to leave the original mechanism of address data (re)fetching and synchronization as unchanged as possible.

Adjustments to this mechanism might be enough by rephrasing the text of the "Refresh to sync" button, or perhaps go one step further by automatically triggering a refetch of address data when the page regains focus.

[joemcgill]

Thanks for flagging your concerns @eason9487. I've asked @fblascogarma and @MatthiasReinholz to review and help provide clarification.

For what it's worth, I did meet with @fblascogarma last week to confirm these requirements, as mentioned in this comment. The decision when we spoke was to update this component so that clicking the "Refresh to sync" button would sync the address information to MC rather than updating the UI with fresh data from the WC store.

In the interest of time, can I get the current implementation reviewed and we can make further adjustments to the acceptance criteria as part of the UAT review that will happen on this feature before it's merged to develop?

[ankitguptaindia]

QA/Test Report- ✅

Testing Environment -

• WordPress: 6.6.2
• Theme active on store: Twenty Twenty-Four Version: 1.2
• WooCommerce - Version 9.3.3
• PHP: 8.3
• Web Server: Nginx
• Browser: Chrome - Version 130
• OS: macOS Sonoma 14.6.1

Test Results - Tested PR based on the information and current Acceptance Criteria provided in connected GH issue. Sync flow is working as expected as described in requirement.

Functional Demo / Screencast -

Onboarding Screen Sync Flow: ✅

Recording.944.mp4

If the store address matches with MC address: ✅

Recording.942.mp4

Setting Screen Sync Flow: ✅

Recording.941.mp4

[joemcgill]

Change of plans here. After confirming with @fblascogarma and @MatthiasReinholz today, we're going to take a slightly different approach here. I've updated the AC in the issue, but the key changes are:

• Show always the Store Address component, independently if a merchant already synced their store address to MC.
• Change CTA wording and keep same functionality. Wording: “Update store address”