Ensure Dashboard Sharing works without UA

[nfmohit]

Feature Description

Since as a part of this epic, Site Kit will no longer require UA and would work with only GA4 connected, we need to ensure that Dashboard Sharing still works without UA and only GA4.

We're updating the module connection logic for GA4 in #6737 and according to those changes, the Analytics module doesn't show up as a shareable module anymore. We need to work around this in one of the two possible ways:

• Have both Analytics and Analytics 4 show up in the Dashboard Sharing modal by removing the restriction for internal modules to be visible, based on the connection of each module.
• Similar to how we change the module connection logic for Analytics in Update Analytics module connection logic #6737, we can change the logic for Analytics being shareable similarly based on the availability of the Analytics_4 module.

Both approaches have their own challenges. Showing both modules might not be 100% acceptable from a product perspective, and the second approach might require some more undertaking regarding the permissions check for authentication.

---

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

Acceptance criteria

• If the ga4Reporting feature flag is enabled:
  • The Analytics_4 module should be displayed as a shareable module in the dashboard sharing settings modal.
  • Instead of showing both Analytics and Analytics_4 simultaneously, Analytics_4 should only be shown if the Analytics dashboardView module setting is google-analytics-4, otherwise, the Analytics module should be shown.
  • A two way synchonization should be established between the module sharing settings between Analytics and Analytics_4, similar to the one-way we're doing in Ensure GA4 widgets can display data on the Shared Dashboard. #6687.
  • If the site switches between dashboard views, the module sharing settings and behaviour should remain identical for both cases.

Implementation Brief

• In assets/js/modules/analytics-4/index.js:
  • In the registerModule() function, add the Icon property duplicating that of assets/js/modules/analytics/index.js.
• In assets/js/googlesitekit/modules/datastore/modules.js:
  • The getShareableModules() selector should be updated to do the following:
    • Inside the modules reduce function, before returning anything yet, check if modules[ slug ] is analytics. If so, check if the current dashboard view is GA4 (can be checked using the isGA4DashboardView() selector from the modules/analytics store). If that is the case, return the analytics-4 module instead of analytics, e.g. return { 'analytics-4': modules[ 'analytics-4' ], ...acc };.
• In assets/js/googlesitekit/modules/datastore/sharing-settings.js:
  • Update the reducer changes for the actions SET_SHARED_ROLES and SET_SHARING_MANAGEMENT such that if the moduleSlug is either analytics or analytics-4, the updates would also be mirrored to the other. In short, whatever changes are applied to analytics should also apply to analytics-4 and vice-versa.
• We also need to take care of the scenario where a user had shared the Analytics module before we introduce the above replication, in which case we can't rely entirely on changes to the sharing settings, we want it to work automatically for this case. In includes/Modules/Analytics_4.php:
  • In the register() method, use the 'option_' . Module_Sharing_Settings::OPTION filter (documentation) to check if the sharing settings don't include the analytics-4 module but do include analytics. If so, it should include a copy of the analytics settings for analytics-4 in the sharing settings array, and return the updated sharing settings array.

Test Coverage

• In assets/js/googlesitekit/modules/datastore/modules.test.js:
  • Update test cases for getShareableModules() to reflect the above changes.
• In assets/js/googlesitekit/modules/datastore/sharing-settings.test.js:
  • Update test cases for setSharedRoles() and setSharingManagement() actions to reflect the above changes.
• Fix any other failing tests.

QA Brief

• With the ga4Reporting feature flag disabled, test the "Module Sharing Settings" for Analytics within the Dashboard Sharing Settings modal and verify that these settings are fetched, can be edited and saved correctly as before. There should be no change in its behaviour.
• With the ga4Reporting feature flag enabled, ensure the 'Dashboard View' setting toggle is "off" so that Universal Analytics data is still show on the dashboard. For a new site, this should be the default case anyways. Repeat the first QAB point above and test the "Module Sharing Settings" for Analytics within the Dashboard Sharing Settings modal. This should still work as before. However, make a note of the settings that are saved for Analytics.
• Switch the 'Dashboard View' setting toggle in Analytics settings to "on" to enable GA4 data on the dashboard. Again test the "Module Sharing Settings" within the Dashboard Sharing Settings modal. Verify the AC (a single Analytics-4 row should be displayed with the same settings that were selected for Analytics in the above step). Modify these settings and make a note of the new settings.
• Switch off the 'Dashboard View' setting toggle in Analytics settings again (back to UA dashboard). Test the Dashboard Sharing Settings modal now shows a single "Analytics" row with the same settings selected for Analytics-4 in the step above.

Changelog entry

• Ensure Dashboard Sharing works without Universal Analytics being enabled.

[tofumatt]

I don't think adding another module to the module sharing options is the right choice from a product/UX perspective. It would be a bit confusing and mean:

• Users who had enabled sharing for Analytics (UA) are required to know to open sharing settings and select Analytics 4
• Users can disable one of two Analytics modules to share (this is confusing)
• Users are presented with a module (Analytics 4) that doesn't appear anywhere else on the site
• Users will see "duplicate" Analytics icons/text in the sharing settings

I think instead we should adjust the logic here… probably what should happen is something similar to #6737 as mentioned in the issue preface.

Partly this seems a bit complicated though, if the ga4Reporting feature flag is enabled or UA is not connected but Analytics 4 is, we should treat Analytics 4 as the Analytics module and the old Analytics (UA) module as the internal one.

Additionally, we probably want to transfer settings/enabled flags/etc. between the two modules so they're in-sync whenever the "sharable" Analytics module changes. It would be bad UX to need to "re-share" an already-shared module because the "underlying module" changed.

---

Does that all make sense or am I overcomplicating/misunderstanding something? 😅

[jimmymadon]

@tofumatt This is exactly what @aaemnnosttv, @kuasha420, @marrrmarrr and I discussed yesterday on our AC sync. The conclusion was to have a two way sync of the sharing settings like you suggest and similar to the way we are planning to sync the "owner" in #6465. The only concern would be if this approach is "too hard" to implement as a first iteration before GA4 reporting launch.

c.c. @nfmohit

[nfmohit]

Thank you for your kind feedback, @tofumatt & @jimmymadon!

I had some follow-up discussion about this with @aaemnnosttv and we decided it could be ideal to combine your ideas and show the appropriate module (Analytics or Analytics_4) depending on the dashboardView setting (e.g. if in GA4 dashboard view, show Analytics_4 module as shareable.

@tofumatt Over to you for another look, thank you!

[tofumatt]

ACs here sound good. I was trying to think if we need any error handling/states/messaging for a case where the user of UA wouldn't have access to GA4… but I don't think that should be possible with how we have Analytics set up, so I think we're good 👍🏻

Moving to IB 👍🏻

[nfmohit]

Note to IB Reviewer

Asked in #6687 (comment) to help clarify the relationship between these two issues.

[aaemnnosttv]

In assets/js/googlesitekit/modules/datastore/sharing-settings.js:

• Update the saveSharingSettings() action so that before calling the fetch store:

  • If the current dashboard view is GA4 (can be checked using the isGA4DashboardView() selector from the modules/analytics store), the sharingSettings object should be updated so that it has an analytics property with a duplicate object value as analytics-4.

• If the current dashboard view is not GA4, the opposite should happen, i.e. the sharingSettings object should be updated so that it has an analytics-4 property with a duplicate object value as analytics.

@nfmohit I think we could perhaps simplify this by applying the change in the reducer for the SET_SHARED_ROLES and SET_SHARING_MANAGEMENT actions which are module specific. We'd only need to mirror the incoming change to the other module which wouldn't need any other conditions related to the dashboard view.

Thinking about this a bit more, one scenario we need to consider here are for folks that already have Analytics shared, in which case we can't rely entirely on changes to the sharing settings, we want it to work automatically for this case. This could be a one-time backend migration or perhaps something we bake into the backend sharing settings to populate it from GA settings if GA4 isn't present. What do you think?

[nfmohit]

In assets/js/googlesitekit/modules/datastore/sharing-settings.js:

• Update the saveSharingSettings() action so that before calling the fetch store:

  • If the current dashboard view is GA4 (can be checked using the isGA4DashboardView() selector from the modules/analytics store), the sharingSettings object should be updated so that it has an analytics property with a duplicate object value as analytics-4.

• If the current dashboard view is not GA4, the opposite should happen, i.e. the sharingSettings object should be updated so that it has an analytics-4 property with a duplicate object value as analytics.

@nfmohit I think we could perhaps simplify this by applying the change in the reducer for the SET_SHARED_ROLES and SET_SHARING_MANAGEMENT actions which are module specific. We'd only need to mirror the incoming change to the other module which wouldn't need any other conditions related to the dashboard view.

Agreed, I've updated this part of the IB accordingly.

Thinking about this a bit more, one scenario we need to consider here are for folks that already have Analytics shared, in which case we can't rely entirely on changes to the sharing settings, we want it to work automatically for this case. This could be a one-time backend migration or perhaps something we bake into the backend sharing settings to populate it from GA settings if GA4 isn't present. What do you think?

Nice catch! I've included in the IB to return GA settings if GA4 isn't present in the backend. Let me know if this sounds good.

Thank you, Evan!

[aaemnnosttv]

• Update the get() method such that if the $settings being returned doesn't include the analytics-4 module but does include analytics, it should return a copy of the analytics settings for analytics-4

@nfmohit this would work, but we don't really need to modify that class to modify the value. This can be done just about anywhere using the option_ filter. This would make sense to keep even after UA is removed for BC so this could go in the Analytics_4 class or even a new one specific for this kind of backwards compatibility going forward.

[nfmohit]

Hi @jimmymadon!

I was just checking this out and it doesn't seem to be working as expected. Please check the following screencast:

I think this happens because this new check wasn't placed before the check if the module is internal.

site-kit-wp/assets/js/googlesitekit/modules/datastore/modules.js

Lines 1363 to 1376 in 216103d

	return Object.keys( modules ).reduce( ( acc, slug ) => {
	if ( modules[ slug ].shareable && ! modules[ slug ].internal ) {
	if (
	slug === 'analytics' &&
	select( MODULES_ANALYTICS ).isGA4DashboardView()
	) {
	return { 'analytics-4': modules[ 'analytics-4' ], ...acc };
	}
	return { [ slug ]: modules[ slug ], ...acc };
	}
	return acc;
	}, {} );

Instead of the above, I think it should be the following:

return Object.keys( modules ).reduce( ( acc, slug ) => {
	if (
		slug === 'analytics' &&
		select( MODULES_ANALYTICS ).isGA4DashboardView()
	) {
		return { 'analytics-4': modules[ 'analytics-4' ], ...acc };
	}

	if ( modules[ slug ].shareable && ! modules[ slug ].internal ) {
		return { [ slug ]: modules[ slug ], ...acc };
	}

	return acc;
}, {} );

Let me know what you think. Thanks!

(also added a comment in the relevant code review)

CC: @techanvil

[nfmohit]

Hi folks!

I did some further testing after this was merged, and found out that Analytics widgets do not show up in the view-only dashboard if the Analytics module is connected with only GA4 without UA.

Since this wasn't mentioned in the ACs and it is out of the scope for this issue, I've opened #6824 to address this.

CC: @aaemnnosttv

[wpdarren]

QA Update: ⚠️

Updated: Odd behaviour with the tester plugin.

@jimmymadon @nfmohit when I have GA4Reporting feature flag enabled, the Dashboard Sharing icon does not display on the header navigation. Do you feel this is a bug from this ticket?

[wpdarren]

QA Update: ⚠️

@jimmymadon @nfmohit I have two observations that might be fixed in one of the tickets still in definition, but I wanted to check before sending this back to Execution.

1. I have a site with GA4Reporting flag enabled. The dashboard is set to UA in settings. As admin I shared access to Analytics, etc. When I login as an Editor, on the view only dashboard the Analytics widgets are not appearing.

Screencast below.

ds-ua.mp4

2. I have a site with GA4Reporting flag enabled. I changed the dashboard to be GA4 in settings. When I click on the Dashboard Sharing icon, Analytics is not appearing in the options to share.

[wpdarren]

QA Update: ⚠️

I am going to leave this ticket in QA because currently it does not pass the QAB due to #6824 as reported in issue 1 above. I would like to test this ticket again when the fix is merged.

[wpdarren]

QA Update: ✅

Verified:

This passed all of the scenarios in the QAB. Made sure settings were saved by refreshing. Reset settings, and checked to make sure the change took place. Checked console and network tab for any errors, none found. Screenshots below.