Show the Introductory Popup / Banner to view-only users and secondary admins

[techanvil]

Feature Description

Show the Introductory Popup / Banner to view-only users and secondary admins to introduce the feature once it has been set up.

See dashboard sharing and secondary admins in the design doc.

---

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

Acceptance criteria

• Given that the Audience Segmentation feature has been set up by the primary admin (i.e. an admin has enabled the feature via the Setup CTA Banner, or the Setup CTA on the Settings screen):
  • When a secondary admin, or a view-only user subsequently visits the main dashboard, the Introductory Popup / Banner should be displayed (see Add the Introductory Popup / Banner (Storybook) #8171).
  • Clicking on the Popup / Banner's Show me CTA will scroll to the Audiences Widget Area, and permanently dismiss the Popup / Banner.
  • Clicking on the Popup / Banner's Got it CTA will permanently dismiss the Popup / Banner.
  • The Popup / Banner should not display on the entity dashboard.

Implementation Brief

• Rendering the banner/popup is handled here. It will be visible when the Audience Segmentation feature is enabled.

  • Update the condition to also check if the Audience Segmentation feature has already been setup. This can be checked with the flag audienceSegmentationSetupCompleted in Analytics settings being introduced in Implement the secondary user setup #8130.

• In assets/js/modules/analytics-4/components/audience-segmentation/dashboard/AudienceSegmentationIntroductoryOverlayNotification.js

  • Import getContextScrollTop from assets/js/util/scroll.js.
  • Add a new handler scrollToWidgetAndDismissNotification for scrolling and dismissing the notification.
    • This function should call the dismissNotification.
    • Pass context as googlesitekit-widget-area--mainDashboardTrafficPrimary and breakpoint using useBreakpoint hook to getContextScrollTop.

• As the getContextScrollTop is now being used to get the position for widgets and widget areas as well as widget context elements, rename this function to getNavigationalScrollTop and update all its usages indicating it's a general purpose utility for use in scrolling to an area which is within the remit of the dashboard navigation, below the header.

Test Coverage

• Add a test for AudienceSegmentationIntroductoryOverlayNotification component to test the scroll behaviour.
• Add a test for AudienceSegmentationIntroductoryOverlayNotification component to test the dismissal behaviour.
• Update story for AudienceSegmentationIntroductoryOverlayNotification to include a new scenario dependent on audienceSegmentationSetupCompleted flag.

QA Brief

For secondary admins.

1. Enable the audience segmentation feature and complete the setup with primary admin account.

2. Create an another admin account and login with that account. Pop up notification must be visible for the secondary admin user.

For view only user

1. Enable the audience segmentation feature and complete the setup with primary admin account.

2. Create a view only user account and provide it the view only access using Sharing Settings in Site Kit. Note that we will need to provide view only access to Analytics module so that view-only user has access to the Audience Segmentation feature.

3. Login with view only user's account and go to Site Kit dashboard, there should be the pop-up notification appearing for the user.

Changelog entry

• Ensure the Audience Segmentation Introductory Popup / Banner is only shown to to view-only users and secondary admins once the feature has been setup by the initial admin.

[techanvil]

Hi @ankitrox, thanks for drafting this IB. Here are a few points:

• Rendering the banner/popup is already been taken care here. It will be visible when the audience segmentation feature is enabled.

• Actually, while this is true in itself, the banner should not be shown purely based on whether the feature flag is enabled. In fact the banner should only be shown under the conditions described in the AC, i.e. once the feature has been setup by a primary admin. I imagine we can add a check for audienceSegmentationSetupComplete (being introduced via Implement the secondary user setup #8130) in the conditions for rendering the banner (either in OverlayNotificationsRenderer, or to potentially return null in AudienceSegmentationIntroductoryOverlayNotification).
• Further to the above I've added Implement the secondary user setup #8130 as a dependency to this issue.

---

• As to the rest of the IB - there's no need to add a scrollToAudienceWidgetArea parameter and modify dismissNotification. Instead, we should simply follow the example of AnalyticsAndAdSenseAccountsDetectedAsLinkedOverlayNotification and provide a separate click handler for the Show me CTA with a similar implementation:

site-kit-wp/assets/js/components/OverlayNotification/AnalyticsAndAdSenseAccountsDetectedAsLinkedOverlayNotification.js

Lines 182 to 201 in 51452f6

	const scrollToWidgetAndDismissNotification = ( event ) => {
	event.preventDefault();
	dismissNotification();
	setTimeout( () => {
	const widgetClass =
	'.googlesitekit-widget--adsenseTopEarningPagesGA4';
	global.history.replaceState(
	{},
	'',
	`#${ ANCHOR_ID_MONETIZATION }`
	);
	global.scrollTo( {
	top: getContextScrollTop( widgetClass, breakpoint ),
	behavior: 'smooth',
	} );
	}, 50 );
	};

• We should pass .googlesitekit-widget-area--mainDashboardTrafficAudienceSegmentation rather than googlesitekit-widget-area--mainDashboardTrafficPrimary to getContextScrollTop() to ensure we scroll to the Audiences Widget Area rather than the top of the Traffic context.
• Incidentally seeing as getContextScrollTop() is now being used to get the position for widgets and widget areas as well as widget context elements, we should rename the function. I'd suggest a new name of getNavigationalScrollTop() indicating it's a general purpose utility for use in scrolling to an area which is within the remit of the dashboard navigation, below the header.

[ankitrox]

Hi @techanvil ,

Thanks for reviewing the IB. I've addressed the feedback points mentioned in the comments and updated the IB.

Assigning this to you for re-review.

[techanvil]

Thanks @ankitrox. The main body of the IB is looking good (although it needed a tweak for formatting, please review). I have though realised the Test Coverage section is written in a way that would encourage more spying on implementation details.

We don't really want to test whether getContextScrollTop() has been called as that's not verifying the actual behaviour of the component. If anything a spy and assertion on global.scrollTo() would be more appropriate here, that being the public DOM API call that would be the clearest indication we've actually scrolled or not.

Also, although it does look like we're in the process of setting a precedent of testing whether an action has been dispatched by spying on it, we should still try to stick with our more usual approach where we can. As such the more conventional approach would be to mock the dismiss-item endpoint and assert the DOM after interacting with the component.

For example here are a couple of existing tests for dismissing a UI item:

site-kit-wp/assets/js/components/OverlayNotification/AnalyticsAndAdSenseAccountsDetectedAsLinkedOverlayNotification.test.js

Lines 436 to 466 in 817317d

	it( 'clicking the `Show me` button dismisses the notification', async () => {
	provideAnalytics4MockReport( registry, reportOptions );
	fetchMock.getOnce( fetchGetDismissedItemsRegExp, { body: [] } );
	fetchMock.postOnce( fetchDismissItemRegExp, {
	body: [ ANALYTICS_ADSENSE_LINKED_OVERLAY_NOTIFICATION ],
	} );
	const { container, getByRole, waitForRegistry } = render(
	<AnalyticsAndAdSenseAccountsDetectedAsLinkedOverlayNotification />,
	{
	registry,
	viewContext: VIEW_CONTEXT_MAIN_DASHBOARD,
	}
	);
	await waitForRegistry();
	expect( container ).toHaveTextContent(
	'Data is now available for the pages that earn the most AdSense revenue'
	);
	act( () => {
	fireEvent.click( getByRole( 'button', { name: /show me/i } ) );
	} );
	await waitForRegistry();
	expect( container ).not.toHaveTextContent(
	'Data is now available for the pages that earn the most AdSense revenue'
	);
	} );

site-kit-wp/assets/js/modules/adsense/components/dashboard/AdSenseConnectCTAWidget.test.js

Lines 113 to 125 in 817317d

	it( 'should close the modal on clicking the dismiss button', async () => {
	// eslint-disable-next-line require-await
	await act( async () => {
	fireEvent.click(
	document.querySelector(
	'.googlesitekit-tooltip-buttons > button'
	)
	);
	} );
	expect(
	document.querySelector( '.googlesitekit-tour-tooltip' )
	).not.toBeInTheDocument();
	} );

To be honest, we don't usually specify the test coverage in an IB in such detail. I would suggest simply specifying that we provide test coverage for the relevant behaviour, and leave the details to implementation time.

[ankitrox]

Hi @techanvil
Thanks for the feedback. I agree that details in the test coverage section is not required, so I updated the section just to mention which tests will be required to cover the feature.

Assigning this to you to re-review the test coverage section.

Thanks again!

[techanvil]

That's great, thanks @ankitrox. The IB LGTM! ✅

[ankitrox]

The PR #9239 is ready, but this issue will be parked in execution till #8130 gets merged. Once #8130 is merged, need to do following checks before moving it to CR.

1. Merge develop into feature branch and resolve any conflicts.
2. Make sure all tests and VRTs are passing.
3. Test the feature on local.
4. Write QAB for the issue.

[mohitwp]

QA Update ⚠️

• Tested on dev environment.
• Verified on both 'view only dashboard' and 'secondary admin dashboard.'
• Verified that introductory Popup/Banner appears to view only users and secondary admins.

@ankitrox

Question -I noticed that if I log in as a secondary admin and go directly to the main dashboard without visiting the 'View Only Dashboard,' I receive an insufficient permission error for the Audience widget. However, if I either disconnect and visit the 'View Only Dashboard' first or access the 'View Only Dashboard' before signing in, I don’t encounter the insufficient permission error.

Note: All admins have view-only access to Analytics.

Should I create a separate issue for this ?

Recording.1419.mp4

- View only dashboard-

Recording.1417.mp4

[mohitwp]

QA Update ❌

• Tested on dev environment.
• Verified on both 'view only dashboard' and 'secondary admin dashboard.'
• Verified that introductory Popup/Banner appears to view only users and secondary admins.

@ankitrox

Issue : Popup/Banner appearing on entity dashboard for secondary admin which is not expected.

Recording.1420.mp4

Note : For the issue reported above I created a separate ticket #9411

[ankitrox]

Thank you @mohitwp

I've created a follow-up PR #9416 to address the issue you have reported.

@techanvil Can you please look review the PR if you have bandwidth? I have not assigned you directly in case you are already occupied with something else.

[techanvil]

Thanks @ankitrox! I'll get that PR reviewed 👍

[techanvil]

Reviewed and merged, back to you for another pass @mohitwp.

[mohitwp]

QA Update ⚠️

• Tested on dev environment.
• Verified that now on 'entity dashboard' popup is not appearing.

Recording.1439.mp4

@ankitrox

Question
When visiting the 'view only' dashboard, I'm encountering a console error:Cannot read properties of undefined (reading 'error').Could you please confirm if this is related to the changes introduced in this ticket?

[techanvil]

Hi @mohitwp, thanks for spotting that. It does not appear to be related to the changes in this issue, please can you raise a new one for it?

[mohitwp]

QA Update ✅

• Tested on dev environment.
• Verified on both 'view only dashboard' and 'secondary admin dashboard.'
• Verified that introductory Popup/Banner appears to view only users and secondary admins.
• Verified that now on 'entity dashboard' popup is not appearing.

Recording.1439.mp4