For Quality

What to test

For each of the nine mutations below, the assertion is the same: after the action, the affected user's pushNotifications array is empty, in addition to whatever session-ending behavior already existed. A practical proxy for "empty push token array" without direct DB access: log in on a second device/session first so a token is registered, trigger the action, then confirm that device no longer receives a test push notification without logging back in.

Mutation	How to trigger it in the UI	Who it affects
`updateAuthDetails`	Settings → Account → Security → Update Password, submit with current + new password	The logged-in user only
`resetPassword`	"Forgot your password?" flow from the login page, complete with emailed token	The user who owns the reset token
`confirm2FAToken`	Settings → Account → Security → Enable Two Factor Authentication, confirm with a TOTP code	The logged-in user only
`disable2FA`	Settings → Account → Security, with 2FA already on, disable with a valid TOTP code	The logged-in user only
`editGroup`	Settings → Permission Groups → open a group → change a permission checkbox → save	Every user currently in that group
`deleteGroup`	Settings → Permission Groups → open a group with members → Delete → pick a replacement group	Every user who was in the deleted group
`editUser`	Settings → Users → edit icon → change any field → Update	The one edited user
`adminDisableTwoFactor`	Internal admin console only	The targeted user
`disableCompany` (disabling only)	Internal admin console only	Every user in that company

Edge cases worth poking at

disableCompany re-enable path: confirm push tokens are not touched when disabled is set back to false — the code only runs the clear when args.disabled is true (adminMutations.js:422-424). Re-enabling shouldn't need to wipe anything since nothing new was added to the account while it was disabled.
deleteGroup when the group has zero members: args.newGroup isn't required in that path (the code only demands it when groupToDelete.users.length is truthy — companyMutations.js:949-952). Confirm deleting an empty group still succeeds and doesn't error trying to clear push tokens for a user set that's empty.
editUser on a user with no push tokens at all: { set: [] } on an already-empty array should be a silent no-op, not an error.
Multi-session users: a user logged into two phones, only one of which triggers the mutation (e.g. they reset their own password from phone A) — both phones' tokens should be cleared, since the field wipes the whole array, not per-session. This is a deliberate behavior (the array has no way to know which token belongs to which device beyond what's separately tracked on UserSession.pushNotification), but worth confirming testers understand it's "wipe all of this user's tokens," not "wipe only the token for the session that triggered it."
Patient tokens are untouched: run any of the above against a user who is also somehow associated with Patient.pushNotifications data (different model, different table) and confirm that field is unaffected — the two pushNotifications columns are unrelated aside from sharing a name.
logout and logoutOutAllUsers are unchanged by this PR — good regression-check targets to confirm nothing here accidentally altered their existing (already correct) behavior.

Out of scope for this PR (don't file as bugs against it)

disableCompany leaving stale UserSession rows in the database (it only clears the Redis session cache) — pre-existing, unrelated to push tokens.
Any push-notification delivery/formatting issues — this PR only touches when the token list is emptied, not how notifications are sent.

Generated from the feat/accounting-module PR · internal documentation