Skip to content

Change dismissal behaviour on policy violation notifications #12247

@wpdarren

Description

@wpdarren

Bug Description

As per conversation with Mariya and Sigal on Slack here.

This issue combines #12246 and #12247 per @aaemnnosttv's suggestion, confirmed by Mariya.

Problem 1 (from #12246): When a user completes the setup of RRM and the organization/publication has a policy violation, the dashboard notification appears immediately after navigating away — even though the user just saw the setup success notification. As mentioned on this Slack conversation, this is too soon and frustrating.

Problem 2 (original #12247): For extreme violations, dismissing the dashboard notification currently results in permanent dismissal. Instead, it should reappear up to 5 times with a buffer between each appearance, before being permanently dismissed.

Solution: Per Evan's suggestion, we substitute "next login" with a 24-hour time-based buffer, which fits into the existing notification dismissal infrastructure. This applies to both problems.


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

Acceptance criteria

Dashboard notifications should not appear immediately after setup (all severity levels):

  • When the user sets up RRM with an organization or publication that has any level of policy violation, when they navigate away from the dashboard, they should not instantly see the dashboard notification upon returning to the dashboard.
  • The dashboard notification should not reappear for 24 hours after the setup success notification is shown.
  • This should apply to all policy violation severity levels (pending, active moderate/high, and extreme).

Extreme notifications should reappear up to 5 times:

  • When the user sets up RRM with an organization/publication that has an extreme policy violation, they will be able to dismiss the dashboard notifications.
  • Despite being dismissed, the notification will reappear after 24 hours, for up to 5 total dismissals. After the 5th dismissal, the notification should no longer appear on the dashboard.

Implementation Brief

  • Proactively dismiss dashboard notifications when the setup success notification renders with a policy violation — update assets/js/modules/reader-revenue-manager/components/dashboard/RRMSetupSuccessSubtleNotification/index.tsx:

    • For moderate/high violations (PENDING_POLICY_VIOLATION / ACTIVE_POLICY_VIOLATION):
      • call registry.dispatch( CORE_USER ).dismissItem( RRM_POLICY_VIOLATION_MODERATE_HIGH_NOTIFICATION_ID, { expiresInSeconds: DAY_IN_SECONDS } ).
    • For extreme violations (EXTREME_POLICY_VIOLATION, from #12245):
      • call registry.dispatch( CORE_USER ).dismissItem( RRM_POLICY_VIOLATION_EXTREME_NOTIFICATION_ID, { expiresInSeconds: DAY_IN_SECONDS } ).
    • The existing isShowingSuccessNotification() check in checkRequirements already prevents overlap while the setup page is active; the 24-hour dismissal covers the period after navigating away.
  • Add dismissRetries: 5 to the extreme notification registration — update assets/js/modules/reader-revenue-manager/index.js:

    • On the RRM_POLICY_VIOLATION_EXTREME_NOTIFICATION_ID notification config, add dismissRetries: 5.
    • This tells the notification system to use the prompts-based dismissal with 5 retries before permanent dismissal.
  • Update dismissOptions for the extreme notification — update assets/js/modules/reader-revenue-manager/components/dashboard/PolicyViolationNotification/index.tsx:

    • For the extreme case, change dismissOptions from {} (permanent, expiresInSeconds: 0) to { expiresInSeconds: DAY_IN_SECONDS } (24-hour expiry).
    • Each dismissal suppresses the notification for 24 hours. After 5 total dismissals, the dismissRetries mechanism switches to expiresInSeconds: 0 (permanent), so the notification never appears again.
  • No Storybook changes needed — this is a behavioral change, not a visual change.

Test Coverage

  • Add unit tests in RRMSetupSuccessSubtleNotification/index.test.tsx to verify that when the setup success notification renders with a policy violation, the corresponding dashboard notification is proactively dismissed with a 24-hour expiry.
  • Add/update tests in PolicyViolationNotification/index.test.tsx to verify the extreme notification is registered with dismissRetries: 5 and uses a 24-hour expiry on dismissal.

QA Brief

  1. Turn on the rrmPolicyViolations feature flag.
  2. Set up Site Kit.
  3. Set up RRM with a publication that has an extreme policy violation.
  4. Upon seeing the setup success notification, dismiss it.
  5. Verify that you do not see the corresponding policy violation notification.
  6. Open the DB and look for {prefix}_googlesitekitpersistent_dismissed_items (associated with your user ID) in the {prefix}_usermeta table. Change the expiry timestamp for rrm-policy-violation-extreme-notification to the current (or a past) timestamp, so that our code thinks that 24 hours have passed since the notification was dismissed.
    a. To get the current timestamp, go to unixtimestamp.com and simply click on the "Copy" button underneath the current timestamp.
  7. Go back to the Site Kit dashboard and verify that you see the policy violation notification.
  8. Dismiss it.
  9. Similar to step 6, open the DB and look for {prefix}_googlesitekitpersistent_dismissed_prompts (associated with your user ID) in the {prefix}_usermeta table. Change the expiry timestamp for rrm-policy-violation-extreme-notification to the current (or a past) timestamp, so that our code thinks that 24 hours have passed since the notification was dismissed.
    a. You do NOT need to increment its count. It will be incremented automatically when the notification is dismissed.
  10. Go back to the Site Kit dashboard and verify that you see the policy violation notification again.
  11. Repeat steps 9-10 for 5 dismissals. After dismissing it for 5 times, the expiry timestamp in the DB should automatically change to 0 (permanent dismissal) and you no longer should see the policy violation notification.

Changelog entry

  • Improve dismissal behavior for RRM policy violation notifications by delaying them for 24 hours after setup and allowing extreme notifications to reappear up to 5 times before permanent dismissal.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Module: RRMReader Revenue Manager module related issuesP0High priorityTeam MIssues for Squad 2Type: EnhancementImprovement of an existing feature

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions