Prevent dashboard feature tours from being triggered during module setup

[eugene-manuilov]

Feature Description

We probably need to update tooltip tours to avoid popping up on the module setup pages. It is not a big deal and a user can always close it for sure, but it would be more convenient if we just don't display tooltip tours there.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• A new JS constants VIEW_CONTEXT_MODULE_SETUP with value "moduleSetup" should be added.
• The constant should be used instead of the current value for the viewContext prop of Root when the ModuleSetup component will be used within (i.e. within googlesitekit-dashboard.js and googlesitekit-module.js).

Implementation Brief

Inside assets/js/googlesitekit/constants.js:

• define and export a new constant, VIEW_CONTEXT_MODULE_SETUP, with value "moduleSetup".

Inside assets/js/googlesitekit-dashboard.js:

• Import VIEW_CONTEXT_MODULE_SETUP in addition to the existing VIEW_CONTEXT_DASHBOARD
• If setupModuleSlug is truthy, pass the new VIEW_CONTEXT_MODULE_SETUP constant to <Root> as the viewContext prop.
• If setupModuleSlug is falsy, pass VIEW_CONTEXT_DASHBOARD to <Root> as the viewContext prop.

Inside assets/js/googlesitekit-module.js:

• Import VIEW_CONTEXT_MODULE_SETUP in addition to the existing VIEW_CONTEXT_MODULE
• If setupModuleSlug is truthy, pass the new VIEW_CONTEXT_MODULE_SETUP constant to <Root> as the viewContext prop.
• If setupModuleSlug is falsy, pass VIEW_CONTEXT_MODULE to <Root> as the viewContext prop.

Test Coverage

• No new tests needed

Visual Regression Changes

• Images dealing with feature tours might need updating.

QA Brief

• The issue was originally visible when activating Optimize (or another module that requires a setup form) - the feature tour would run on the setup form page, which isn't ideal.
• Verify that the feature tours no longer run in this scenario. You will likely need to do something along these lines:
  • delete your dismissed tours (e.g. by using WP CLI)
  • navigate to the dashboard and dismiss all the tours that appear there (except for example the 'help visibility' tour)
  • then proceed to activate Optimize and check if the tour appears on the setup form page.

Changelog entry

• Prevent feature tours from appearing during module setup.

[aaemnnosttv]

I think this is something to evaluate on a per-tour basis. For help specifically, I think it makes sense to allow here as module setup is probably one of the areas where users encounter trouble.

However, the dashboard and page dashboard view contexts shouldn't include module setup IMO. Perhaps what we should do is move module setup into a dedicated page rather than reusing the dashboard URL for this. We can't really use the module-specific dashboard screens for this since not every module has one, but most have a set up flow.

So in this case, I think the problem is more that the dashboard entrypoint GoogleSitekitDashboard is doing too much.

[felixarntz]

@aaemnnosttv Sounds good. Maybe let's refocus this issue on splitting out the responsibility of module setup from the dashboard, e.g. via a googlesitekit-dashboard-module-setup.js asset that is conditionally enqueued instead of the googlesitekit-dashboard.js / googlesitekit-dashboard-details.js one.

[felixarntz]

@aaemnnosttv @eugene-manuilov @tofumatt Do we still think this is an idea worth pursuing at this point? We've been occasionally talking about working more towards a single page application, and this issue specifically would counter that tendency. Should we maybe close this instead?

[aaemnnosttv]

@felixarntz As is, I don't think we need a separate JS asset to solve this problem. The simpler change would be to use a different viewContext for module set up where as it currently shares the same as the dashboard due to using the same entry point. That way we could allow for setup-specific tours if we wanted but otherwise this would solve the problem of showing dashboard tours during module set up as the view context is not really accurate here. So I don't think we should close it but redefine it in a simpler way.

[eugene-manuilov]

Yep, I agree with Evan. Let's solve it using a simpler way instead of closing it.

[felixarntz]

@aaemnnosttv @eugene-manuilov Sounds like a plan - I've added ACs accordingly (also a lot simpler!).

[johnPhillips]

Sorry @eugene-manuilov for the accidental assignment there - mouse slip!

[eugene-manuilov]

IB ✔️

[wpdarren]

@aaemnnosttv as per our conversation on Slack last week, am I assuming correctly that this cannot be tested until #4069 is in develop? I have tried to trigger the helpVisibility tour but no success.

[aaemnnosttv]

@wpdarren it should be testable now, but you'll need to disable the overriding of feature flags since this one is no longer controllable via the tester plugin. You may still need the tester plugin active though to force the older initial version. Does that make sense?

[wpdarren]

@aaemnnosttv okay, I have run through this again, but no success at getting the helpVisibility tour appearing.

Here are the steps that I took.

• Test site on develop branch.
• Tester plugin activated, but Force enabled feature flags set to Do not override.
• The Force initial Site Kit plugin version was set to 1.27.0
• When I connected to Site Kit, no feature tour appeared. I was on Site Kit Dashboard screen.
• I logged into the site on Terminal and noticed that wp_googlesitekitpersistent_initial_version entry was not appearing.
• I ran the command to add this in. I set it to 1.27.0 (and 1.25.0 because that is what I used for testing tours previously).
• I then reset SiteKit and connected again but no feature tour appeared.

Any ideas?

[aaemnnosttv]

@wpdarren try clearing any dismissed tours you may have by deleting wp_googlesitekitpersistent_dismissed_tours for your user.

[wpdarren]

@aaemnnosttv I looked at that and wp_googlesitekitpersistent_dismissed_tours isn't in for my user. 🤔

[wpdarren]

QA Update: ✅

When setting up Optimize no tour appeared after it had been dismissed.