Offer the AmlCheck action on completed call outcomes

[Blume1977]

Problem

Saving a call-queue outcome with Completed stores the comment and the userData phone-call fields, but the pending transaction is never touched. The AmlCheck action selector is hidden exactly when the outcome is Completed:

const showAmlCheck = hasTx && outcome !== CallOutcome.COMPLETED;

so saveCallOutcome skips the transaction step entirely and the payment stays on amlCheck = Pending.

For ManualCheckIpCountryPhone this is a dead end: the reason is part of BlockAmlReasons in the API, so the AML recheck cron never picks the pending transaction up again. Setting the userData check date alone has no effect there. This used to work in the Google-Sheet process; since the sheet access was removed, the tool is the only path.

Fix

• Show the AmlCheck action for transaction-based queue items on all outcomes.
• When the outcome is set to Completed, default the action to Reset (per review: not Pass). Reset clears amlCheck + amlReason via DELETE :id/amlCheck, so the AML cron re-runs the full AML check: with the check date now set the phone error is gone, and the tx only passes if no other errors remain. Overridable via the selector.
• Reorder saveCallOutcome to write the userData update before the transaction step. A reset transaction is re-evaluated from scratch by the cron; if the check date were written after the reset, the cron could re-pend the tx into its recheck-blocked reason in the gap and it would be stuck again.

Tests

• Component test call-queue-outcome-form.test.tsx: action offered for tx items, Reset default on Completed, override, reset on other outcomes, no action for user-based queue items.
• Hook test compliance-call-outcome.hook.test.ts: userData (incl. queue-specific check date, e.g. phoneCallIpCountryCheckDate) is written before the transaction reset; no transaction call without an action.
• npm test: 62 suites / 610 tests green, npm run lint clean on the touched files.

[Blume1977]

@Yannick1712 Could you review this one? Since the Google Sheets were shut down, the compliance tool is the only release path for the phone call queues, and completing a call currently leaves the transaction on Pending (details in the description). Two API-side questions in this context: is ManualCheckIpCountryPhone intentionally part of BlockAmlReasons (no cron recheck, manual pass as the official path), and is AUTO_AML_CHECK currently running normally in prod?

[Blume1977]

@davidleomay Could you review this as well? Context is in the description and the comment above.

[Blume1977]

@Yannick1712 Danke, ist umgesetzt: Default bei Completed ist jetzt Reset über den DELETE-Endpoint (:id/amlCheck) statt Pass. Damit läuft der volle AML-Check nochmal und die Tx passt nur, wenn keine anderen Fehler mehr da sind.

Zu deiner Frage: ja, phoneCallIpCountryCheckDate wird gesetzt. saveCallOutcome schreibt bei Outcome Completed per PUT /userData sowohl phoneCallStatus=Completed als auch das queue-spezifische Check-Datum (für ManualCheckIpCountryPhone also phoneCallIpCountryCheckDate). Das war schon vor dem PR so; es fehlte nur die Aktion auf der Transaktion.

Eine Sache habe ich dabei noch angepasst: Das userData-Update läuft jetzt vor dem Reset. Sonst gäbe es ein Fenster, in dem der Cron die zurückgesetzte Tx neu prüft, bevor das Check-Datum sichtbar ist, dann würde sie sofort wieder auf Pending/ManualCheckIpCountryPhone laufen und wäre wegen BlockAmlReasons wieder blockiert. Die Reihenfolge ist jetzt per Hook-Test abgesichert.

[Blume1977]

@Yannick1712 Eine Frage aus dem ersten Kommentar ist noch offen und für den Reset-Default kritisch: Läuft AUTO_AML_CHECK in prod normal?

Der Reset-Default hängt vollständig daran: doAmlCheck läuft nur, wenn Process.AUTO_AML_CHECK nicht disabled ist (buy-crypto-job.service.ts / buy-fiat-job.service.ts). Wäre der Prozess aus, bliebe eine resetete Tx auf amlCheck = NULL liegen, und zwar unsichtbarer als vorher: Sie verschwindet aus der Call-Queue (die listet nur Pending) und taucht in keiner Queue mehr auf. Das alte GS-Pass brauchte den Cron nicht.

Kannst du kurz bestätigen, dass der Prozess in prod aktiv ist? Dann wäre der PR aus meiner Sicht bereit.

Die andere Frage (ist ManualCheckIpCountryPhone absichtlich in BlockAmlReasons) hat sich über die Historie geklärt: Recheck-Entfernung (266175172) und BlockAmlReasons (33bcd89c4) kamen am 02.12.2025 direkt nacheinander, der manuelle Weg ist offensichtlich gewollt.