Symptom (QA row 250, Purchases page > Opportunities flow step 5.6)
When an admin user clicks "Purchase 1 selected" -> "Send all for approval" for an Azure commitment, the success toast says:
Approval request sent to jcorbett@archera.ai
even though cristi@leanercloud.com is set as Notification email under Admin > General Settings.
Subsequently, in Purchase History on the Purchases page, the row shows:
awaiting approval from cristi@leanercloud.com
So two different "approver" identities are surfaced for the same execution:
- The toast names the email of the user who is hard-coded somewhere (likely the original Archera contact for the org), instead of the Admin-set notification email.
- The Purchase History row correctly shows the Admin-set notification email.
This is confusing and a real bug: it is unclear who actually receives the approval email. If the toast is correct, the Admin Settings field is ignored. If the Purchase History row is correct, the toast displays stale/wrong data.
Reproduction
- Set
Notification email = cristi@leanercloud.com under Admin > General Settings.
- From Opportunities, select an Azure recommendation -> "Purchase 1 selected" -> "Send all for approval".
- Observe the toast: it names a different email than
cristi@leanercloud.com.
- Open Purchase History -> the row shows
awaiting approval from cristi@leanercloud.com.
Fix direction
Trace the toast message's data source. The likely culprits:
- Frontend hardcoding the Archera contact email when building the toast string (look for
jcorbett or a default approver constant in frontend/src/).
- API returning a different approver field than what Purchase History reads. The Purchase History row clearly uses the right notification email, so the toast just needs the same data source.
Whichever is wrong, fix it so both UIs show the Admin-set notification email (and the email actually goes there).
Tests required
- Acceptance test: change
Notification email in Admin Settings, kick off an Azure purchase approval from Opportunities, assert the toast names the same email shown in Purchase History.
- Backend regression: ensure the approval-email-send path uses
config.notification_email, not a hardcoded default.
Source of finding
QA verification spreadsheet row 250 (step 5.6 of Opportunities > Purchase).
Symptom (QA row 250, Purchases page > Opportunities flow step 5.6)
When an admin user clicks "Purchase 1 selected" -> "Send all for approval" for an Azure commitment, the success toast says:
even though
cristi@leanercloud.comis set as Notification email under Admin > General Settings.Subsequently, in Purchase History on the Purchases page, the row shows:
So two different "approver" identities are surfaced for the same execution:
This is confusing and a real bug: it is unclear who actually receives the approval email. If the toast is correct, the Admin Settings field is ignored. If the Purchase History row is correct, the toast displays stale/wrong data.
Reproduction
Notification email = cristi@leanercloud.comunder Admin > General Settings.cristi@leanercloud.com.awaiting approval from cristi@leanercloud.com.Fix direction
Trace the toast message's data source. The likely culprits:
jcorbettor a default approver constant infrontend/src/).Whichever is wrong, fix it so both UIs show the Admin-set notification email (and the email actually goes there).
Tests required
Notification emailin Admin Settings, kick off an Azure purchase approval from Opportunities, assert the toast names the same email shown in Purchase History.config.notification_email, not a hardcoded default.Source of finding
QA verification spreadsheet row 250 (step 5.6 of Opportunities > Purchase).