Refactor the UnsatisfiedScopesAlert to use the new Notifications datastore and layout components

[jimmymadon]

Feature Description

This issue is the first issue to refactor an "Error" notification in Site Kit. It should refactor the UnsatisfiedScopesAlert so that it uses the new datastore infrastructure to register and queue the notification. It should also use newer lighter "layout" and "common" components that replace the bloated BannerNotification component as per the pattern introduced in #9071.

---

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

Acceptance criteria

• The UnsatisfiedScopesAlert component should be refactored so that it is registered and rendered (queued) using the new core/notifications datastore.
• This notification component should not be called directly (i.e. in ErrorNotifications) but only via the generic getQueuedNotifications selector.
• The refactored component should not contain any business logic that hides it / prevents it from rendering. This logic should be contained in a callback function defined during registration.
• The component should not use the bloated BannerNotification component. Instead, it should be rendered using the new Notification component wrapper and a simpler "layout" component that solely encapsulates its structure and design.

Implementation Brief

• [x] Update assets/js/components/notifications/UnsatisfiedScopesAlert.js
  • Check the assets/js/components/notifications/GatheringDataNotification.js for the example
  • Remove usage of BannerNotification component
  • Include 2 new props - id and Notification
  • Wrap the component with Notification component passed as the prop
  • Use new components from assets/js/googlesitekit/notifications/components/common/ to assemble the notification using the existing props used to for BannerNotification
  • You can refactor a bit the assets/js/googlesitekit/notifications/components/common/ActionsCTALinkDismiss.js to accept isDismissal prop which would conditionally render dismiss button, so it can be used as part of this notification which is not dismissible.
  • Perhaps, you can also include a new layout type in assets/js/googlesitekit/notifications/components/layout/ so other simple layout notification can use it. It can be called NotificationWithNoSVG for example
• [x] Update assets/js/googlesitekit/notifications/register-defaults.js
  • Register the notification, following the existing patterns already added
  • For checkRequirements transfer the existing checks in assets/js/components/notifications/ErrorNotifications.js
  • For priority, I would suggest using 400 as base number, starting from this one. So all error style notifications can use it, by incrementing on this base number for later higher priority ones.
• [x] Remove UnsatisfiedScopesAlert from the assets/js/components/notifications/ErrorNotifications.js

Test Coverage

• Add stories for new notification. You can use assets/js/components/notifications/GatheringDataNotification.stories.js as an example

QA Brief

• Test the Gathering and Zero Data notifications - mainly the CTA action buttons as this issue modifies that code.
• Test the UnsatisfiedScopesAlert by reducing the number of satisfied scopes.
  • To do this, you can modify the wp-usermeta table's wp_googlesitekit_auth_scopes meta-key row. Set meta value where the webmasters scope has been deleted:

    a:4:{i:0;s:46:"https://www.googleapis.com/auth/userinfo.email";i:1;s:48:"https://www.googleapis.com/auth/siteverification";i:2;s:6:"openid";i:3;s:48:"https://www.googleapis.com/auth/userinfo.profile";}

Changelog entry

• Update banner notification code for the "Unsatisfied Scopes Alert" banner notification.

[tofumatt]

Moving this to the backlog until #8976, which is marked as blocking this issue, is completed. That way we can mirror the approach used in #8976 for other migrations/refactoring.

[eugene-manuilov]

AC ✔️

[eugene-manuilov]

IB ✔️

[jimmymadon]

@zutigrm

For priority, I would suggest using 400 as base number.

Since Errors are higher priority than the other notifications, I would suggest we use 150. GatheringData and ZeroData have priorities 300 and 310. The other banners (about 9 other Banners will come above them taking us to priority 210 approx (each banner increments by 10 - so 290, 280, 270, etc...). There aren't many Errors or notifications above the UnsatisfiedScopesAlert - so we will have many empty slots above and below this notification once all of them are registered.

As mentioned in the stand up, I will probably pick this up this week itself so I can ensure the order is correct. I will also add these priority values into our spreadsheet when completing it.

c.c. @eugene-manuilov

[zutigrm]

@jimmymadon Thanks, makes sense

[jimmymadon]

Since these issues combine the registration and design, I will bump up the estimate to 15 here in line with our points experiment as this would unlikely be a 7 in "normal" scenarios. As seen in other issues, these issues do require proper CR and QA + any time for fixes in case the issue fails QA.

[mohitwp]

QA Update ❌

• Tested on dev environment.

@jimmymadon Please find my observations below

• Issue 1: Zero and data-gathering notifications are appearing below the success notification and other notifications, such as the 'Enable Enhanced Measurement' banner notice.

   

• Issue 2: Zero data notifications appear only once and do not reappear after reloading the page or opening the dashboard in a new tab.

https://github.com/user-attachments/assets/868d0c92-6f2e-4703-a35b-b2c1f066ddc1

Issue 3 : Alignment of unsatisfied scope alert is not correct on dev environment.

   

[jimmymadon]

QA Update ❌

• Tested on dev environment.

@jimmymadon Please find my observations below

• Issue 1: Zero and data-gathering notifications are appearing below the success notification and other notifications, such as the 'Enable Enhanced Measurement' banner notice.

This should now be fixed.

• Issue 2: Zero data notifications appear only once and do not reappear after reloading the page or opening the dashboard in a new tab.

For me, the ZeroDataNotification does appear on page reload. However, it does not appear when we open the dashboard in a new tab. I will add this to the ACs of #9227 as the cause of the inconsistent behaviour is the same here.

Issue 3 : Alignment of unsatisfied scope alert is not correct on dev environment.

This should now be fixed as well.

[mohitwp]

QA Update ✅

• Tested on main environment.
• Verified gathering and zero data notifications for both SC and analytics.
• Verified gathering and zero data notifications appearing on both Main and entity dashboard.
• Verified UnsatisfiedScopesAlert appear before gathering or zero data notifications.
• Verified Issues number 1 and 3 mentioned above are are now fixed.
• I will add issue number 2 related to zero data notification under #9227.

@jimmymadon Regarding issue number 2, I’ve observed that the "zero data" notification appears upon reload if both Analytics and SC are connected. However, if only SC is connected and is in a zero data state, the notification appears only once. It does not reappear upon reload or if we log in from another browser or open the dashboard in a new tab. I will add this scenario under #9227. Same issue exist on latest environment also.

cc @aaemnnosttv @wpdarren

https://github.com/user-attachments/assets/64222246-a799-44e6-8d98-943f5003f4e8

PASS CASES

**Main**  **Latest**  https://github.com/user-attachments/assets/f9689fa3-53eb-4d28-bfe7-c542ecec37cf https://github.com/user-attachments/assets/7866c4c7-4b16-4461-985a-8bf42b7940bb