Refactor RRMSetupSuccessSubtleNotification to use the new Notifications datastore

[jimmymadon]

Feature Description

This is the first issue that refactors the newly implement "subtle notifications" in the plugin as part of Phase 1 of the Banner Notifications Refactoring epic. It should refactor the RRMSetupSuccessSubtleNotification so that it uses the new datastore infrastructure to register and queue the notification. It should also incorporate the newly introduced SubtleNotification component as a new "layout"

---

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

Acceptance criteria

• The RRMSetupSuccessSubtleNotification 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. directly in <SubtleNotifications>) 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.
• It should make use of the newly introduced SubtleNotification component and refactor this reusable component as a new "layout" within the new notifications framework.

Implementation Brief

• Update assets/js/modules/reader-revenue-manager/components/dashboard/RRMSetupSuccessSubtleNotification.js
  • Check the assets/js/components/notifications/GatheringDataNotification.js for the example
  • Remove usage of SubtleNotification component
  • Include 2 new props - id and Notification
  • Wrap the component with Notification component passed as the prop
  • Refactor the existing props used for SubtleNotification to create a new layout assets/js/googlesitekit/notifications/components/layout/SubtleNotification.js
• Update assets/js/googlesitekit/notifications/register-defaults.js
  • Register the notification, following the existing patterns already added
  • For checkRequirements transfer the existing checks from assets/js/components/notifications/SubtleNotifications.js and RRMSetupSuccessSubtleNotification component itself
  • For priority, bump it by 10 from the last added notification (not including error ones, which start from 150).
  • Use NOTIFICATION_AREAS.BANNERS_BELOW_NAV for areaSlug
• Remove RRMSetupSuccessSubtleNotification from the assets/js/components/notifications/SubtleNotifications.js

Test Coverage

• Update existing stories in assets/js/modules/reader-revenue-manager/components/dashboard/RRMSetupSuccessSubtleNotification.stories.js

QA Brief

• Test the RRM Setup Success Notification once thoroughly by really completing RRM setup.
• For additional retesting, you can use the following URL to trigger the notification: /wp-admin/admin.php?page=googlesitekit-dashboard&notification=authentication_success&slug=reader-revenue-manager
• Test that all GA events include the "Publication Onboarding State" as the event label.
• Test clicking on the main CTA which is an external link.
• Test the dismiss behavior and new GA events being fired on dismissal.
• Also test this notification when the site is in Gathering, Zero data and Unsatisfied Scope alert test. This notification will appear "first" and all others will appear later once this is dismissed.

Changelog entry

• Update the Reader Revenue Manager setup success notification to use the new notifications datastore.

[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]

@aaemnnosttv @sigal-teller

When refactoring this issue, I noticed that when we click on the main CTA, it takes us to an external link in a new window but this does not dismiss the notification. Sometimes, this behaviour is actually good because it allows the user to visit the link again if they accidentally close the new window. So we should either:

1. Change the "Maybe later" dismiss button on all version of this notification to be "Ok, got it!" so that if the user comes back from the external link window, then they can click on this button which makes more sense than "Maybe later".

OR

2. Dismiss the notification on the main CTA click.

[sigal-teller]

@jimmymadon I was thinking about the first option as well. I think it's good idea to keep the CTA because if the user didn't complete customization or lost the page, it will be easier for him to re-visit the link and dismiss it at his convinience. I would replace the "Maybe later" with "got it", this is what we're using in otehr features.

[zutigrm]

@jimmymadon it seems you forgot to assign @nfmohit I see he did initial CR on the issue, I assigned him now

[kelvinballoo]

QA Update ⚠

⚠ Hi @jimmymadon , I've tested this from a QA perspective and it's working well on the FE and is according to the QAB.
That said, I am unable to confirm the points from the ACs specifically as these are more technical and more to the backend logic.
I'll label this ticket as QA:Eng to verify for the AC point to ensure we are covered appropriately.

Verified the following as good from the QAB ✅

• Tested all 3 events related to the RRM setup success subtle notification with different Publication Onboarding State. The latter would appear as the event label. Screenshots for 'View notification' event are attached.

  ONBOARDING COMPLETED
  

  ONBOARDING ACTION REQUIRED
  

  PENDING VERIFICATION
  

• Event when clicking on the main CTA which is an external link is working fine with event label containing Publication Onboarding State.

  ONBOARDING COMPLETED
  

  ONBOARDING ACTION REQUIRED
  

  PENDING VERIFICATION
  

• Tested the dismiss behavior and GA event is being fired on dismissal with event label containing Publication Onboarding State.

  ONBOARDING COMPLETED 

  ONBOARDING ACTION REQUIRED
  

  PENDING VERIFICATION
  

• Also tested the notification when the site is in Gathering, Zero data and Unsatisfied Scope alert test. This notification appears "first" and all others will appear later once this is dismissed.

  Reduced scope - The subtle notification will appear first before others.

  8981.-.Onboarding.action.required.reduced.scope.480p.mov

  Above screenshots were in gathering state. Zero data and with full data are as below:
  

  

[kelvinballoo]

QA Update ✅

Confirmed with @jimmymadon that CR / MR process does cover the AC verification.
Hence, we are good to move this to Approval.

Verified the following as good from the QAB ✅

• Tested all 3 events related to the RRM setup success subtle notification with different Publication Onboarding State. The latter would appear as the event label. Screenshots for 'View notification' event are attached.

  ONBOARDING COMPLETED
  

  ONBOARDING ACTION REQUIRED
  

  PENDING VERIFICATION
  

• Event when clicking on the main CTA which is an external link is working fine with event label containing Publication Onboarding State.

  ONBOARDING COMPLETED
  

  ONBOARDING ACTION REQUIRED
  

  PENDING VERIFICATION
  

• Tested the dismiss behavior and GA event is being fired on dismissal with event label containing Publication Onboarding State.

  ONBOARDING COMPLETED 

  ONBOARDING ACTION REQUIRED
  

  PENDING VERIFICATION
  

• Also tested the notification when the site is in Gathering, Zero data and Unsatisfied Scope alert test. This notification appears "first" and all others will appear later once this is dismissed.

  Reduced scope - The subtle notification will appear first before others.

  8981.-.Onboarding.action.required.reduced.scope.480p.mov

  Above screenshots were in gathering state. Zero data and with full data are as below: