[Payment due @aimane-chnaif] Skip card decline notifications for workspace members other than the cardholder

[youssef-lr]

Explanation of Change

Card decline messages are meant only for the cardholder, but admins and auditors who follow the workspace chat still get a sound and a browser notification for them.

We'll skip the notification when an action asks to notify only its actionableForAccountIDs (shouldScopePushToActionableAccounts) and the current user isn't one of them. Mobile push already applies the same check on the server in SendFetchableOnyxUpdates.

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/689061
$ #96274
PROPOSAL: N/A

Tests

1. Create a Control workspace with a submitter and an auditor
2. As the auditor, set the submitter's workspace chat to always notify, then open another chat
3. Send the submitter an Expensify Card decline message in their workspace chat
4. Verify the auditor hears no sound and gets no browser notification
5. As the submitter, on another chat, verify you get the notification for the decline

• Verify that no errors appear in the JS console

Offline tests

Same as tests. The notification is shown when the update arrives, which doesn't happen offline.

QA Steps

Same as tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[codecov]

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/libs/ReportActionsUtils.ts	83.60% <91.66%> (+0.03%)	⬆️
src/libs/actions/Report/index.ts	72.52% <33.33%> (-0.01%)	⬇️
... and 7 files with indirect coverage changes

[melvin-bot]

@aimane-chnaif Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[aimane-chnaif]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

test.mov

[aimane-chnaif]

I tested via a patched dev build since I don't have real Expensify Card.

1. In src/libs/actions/User.ts, inside triggerNotifications, add the flag to every incoming action right before the showReportActionNotification(...) call:

   const scopedAction = {...action, originalMessage: {...(action.originalMessage ?? {}), shouldScopePushToActionableAccounts: true, actionableForAccountIDs: [ACCOUNT_B_ID]}} as ReportAction;

   Then pass scopedAction instead of action.
2. Find Account B's account ID. Open B's profile; the number in the /a/<accountID> URL is the ID. Put it in place of ACCOUNT_B_ID.
3. Use three accounts, A, B and C, and create a group chat containing all three.
4. Run the patched dev build on web in two separate browser profiles. Log into B in one and C in the other. Allow browser notifications in both.
5. In both B's and C's windows, open a different chat (or switch to another tab) so the group chat isn't the one on screen.
6. From A (any client, unpatched is fine), send a message in the group chat.
7. Expected:
   • B gets a desktop notification.
   • C gets none, and C's browser console shows [LocalNotification] No notification because the action is only meant for other accounts.
8. Regression check: remove the patch and send another message. Both B and C get notified.

This covers the shared function both paths use.
The mobile push path needed the same patch, applied to reportAction in src/libs/Notification/PushNotification/shouldShowPushNotification.ts.

[melvin-bot]

🎯 @aimane-chnaif, thanks for reviewing and testing this PR! 🎉

A payment issue will be created for your review once this PR is deployed to production.
E/E issue linked to the PR - https://www.github.com/Expensify/Expensify/issues/689061.

If payment is not needed (e.g., regression PR review fix etc), react with 👎 to this comment to prevent the payment issue from being created.

[MelvinBot]

The change looks correct, and I found no blocking bugs. isPushScopedToOthers fails open: a missing flag, a missing or empty actionableForAccountIDs, or a missing action all still notify. The new check sits next to the whisper check in shouldShowReportActionNotification, so it covers both local and web push notifications.

Two follow-ups to consider:

1. The tests are missing // Given / // When / // Then comments. The App test guidelines require them for every test case. See tests/unit/ReportActionsUtilsTest.ts:2544-2561.
2. The in-chat sound path doesn't use this check. playSoundForMessageType plays a sound when the user is already viewing the report. An auditor with the submitter's chat open may still hear the decline arrive if its originalMessage has html. I didn't confirm the decline payload shape. The message is on screen in that case, so this may be fine as is.

Nit

The typeof originalMessage !== 'object' check in ReportActionsUtils.ts:724 never fires, because getOriginalMessage already returns undefined for anything that isn't an object. You can remove it.

---

view run

[joekaufmanexpensify]

Good for product

[Julesssss]

LGTM,had some NAB comments about additional tests but no real need for them.

[github-actions]

🚧 Julesssss has triggered a test Expensify/App build. You can view the workflow run here.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #103161.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-db0eb85-a57d040-245dd6fcadf4477f52977b9c9c7da4be5d500f51/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-db0eb85-a57d040-ccdc075a04f7221062c0b69eb154b58fcff94ca1/index.html

Web 🕸️
https://103161.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/Julesssss in version: 9.5.6-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

No help site update needed. This is a bug fix: admins and auditors no longer get sound or browser alerts for card decline messages meant only for the cardholder. No article says those users get these alerts. The Expensify Card Notifications article says only the cardholder gets them, which is still true.

---

view run

[IuliiaHerets]

Hi @youssef-lr. How can we trigger a decline on an Expensify card?

cc @Julesssss @joekaufmanexpensify

[youssef-lr]

@IuliiaHerets I think this is tricky to reproduce, it needs an actual card declined system message. We can check it off.

[OSBotify]

🚀 Deployed to production by https://github.com/puneetlath in version: 9.5.6-6 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS

[melvin-bot]

🤖 Payment issue created: #103655