Profile deletion (and every confirm) proceeds without waiting for the confirmation #421
Labels
No labels
autopilot:pending-human
source:analyste
source:defenseur
source:human
source:medic
status:approved
status:blocked
status:in-progress
status:needs-clarification
status:needs-fix
status:ready
status:review
status:triage
type:bug
type:feature
type:infra
type:refactor
type:schema
type:security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: maximus/Simpl-Resultat#421
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Contexte
Dans Paramètres → Profils, supprimer un profil secondaire efface le profil sans attendre la réponse à la boîte de confirmation : la boîte s'affiche alors que la suppression est déjà partie, et « Annuler » n'empêche rien. Un refus se comporte comme une confirmation. La base du profil est supprimée du disque par
delete_profile_db: perte de données irréversible. Signalé par Max le 2026-10-12.Cause (vérifiée dans le code,
main1954502)tauri-plugin-dialog2.6.0 (enregistré danssrc-tauri/src/lib.rs:391) injecte sur desktop un script d'initialisation (init-iife.js,js_init_scripthors Android) qui remplacewindow.confirmpar une fonctionasync:confirm(...)renvoie donc unePromise, toujours vraie. Le garde deProfileFormModal.tsx:91ne bloque jamais :TypeScript ne voit rien : le type DOM de
window.confirmresteboolean. Le plugin est présent depuis49e0bd2(2026-02-08), la suppression de profil depuis la v0.3.0 (20cae64) : le défaut est dans toutes les versions publiées.Portée : toutes les confirmations de l'app
src/components/profile/ProfileFormModal.tsx:91src/components/categories/CategoryDetailPanel.tsx:44src/components/adjustments/AdjustmentDetailPanel.tsx:39src/components/budget/TemplateActions.tsx:61src/pages/AccountsPage.tsx:126src/components/settings/LicenseCard.tsx:161→src/hooks/useLicenseMachines.ts:383et:391Les tests de
performRemoveLicense(useLicenseMachines.test.ts:752) injectent unconfirmsynchrone : le vert ne couvre pas le chemin réel.Décisions (Max, 2026-10-12)
confirmAction()qui appelleask()de@tauri-apps/plugin-dialog, boutons libellés FR/EN,kind: "warning". Les sites fontawait. Écartés :await window.confirm(boutons natifs non traduits, typebooleanmensonger) et une modale React maison (plus de code pour le même résultat).Travail à faire
@tauri-apps/plugin-dialogaupackage.json(borne^2.6.0, alignée sur le crate du lock). La permissiondialog:defaultdesrc-tauri/capabilities/default.jsoninclut déjàallow-ask: rien à changer côté Rust.src/services/confirmService.ts) :confirmAction(message: string, opts?): Promise<boolean>qui appelleask(message, { kind: "warning", okLabel: t("common.confirm…"), cancelLabel: t("common.cancel…") }). Réutiliser des clés i18n existantes si elles existent, sinon en ajouter dansfr.jsoneten.json. Un échec de l'appel (askqui rejette) vaut refus (fail closed) et passe parlogWarn.if (!(await confirmAction(...))) return;.useLicenseMachines.ts: passer le type dedeps.confirmà(message: string) => Promise<boolean>,awaitaux lignes 383 et 391 ;LicenseCard.tsx:161passeconfirmAction. Adapter les tests pour unconfirmasynchrone.src/**/*.{ts,tsx}(hors tests) et échoue sur tout appel àconfirm(/window.confirm(/alert(hors du helper (pas d'ESLint dans le projet).alertest aussi remplacé par le plugin (non bloquant, sans valeur de retour) : le garde l'interdit pour éviter qu'un futur code compte sur son blocage.[Unreleased]: les suppressions (profil, catégorie, ajustement, gabarit, catégorie du Bilan) et le retrait de la clé attendent la confirmation.docs/architecture.md: mentionner le helper dans la liste des services.Hors portée, à noter
prompt(...)deProfileFormModal.tsx:102(saisie du PIN) n'est pas remplacé par le plugin. Son comportement dans WebKitGTK (Linux) et WebView2 (Windows) n'est pas vérifié ; à observer pendant la vérification manuelle, issue séparée si la saisie échoue.Fichiers concernés
package.json,package-lock.json— paquet JS du plugin dialogsrc/services/confirmService.ts(nouveau) — helpersrc/components/profile/ProfileFormModal.tsx,src/components/categories/CategoryDetailPanel.tsx,src/components/adjustments/AdjustmentDetailPanel.tsx,src/components/budget/TemplateActions.tsx,src/pages/AccountsPage.tsx—await confirmActionsrc/components/settings/LicenseCard.tsx,src/hooks/useLicenseMachines.ts— confirmation asynchrone dansperformRemoveLicensesrc/i18n/locales/fr.json,en.json— libellés des boutons si absentsCHANGELOG.md,CHANGELOG.fr.md,docs/architecture.mdSurface de test
src/hooks/useLicenseMachines.test.ts(confirm synchrone, à passer en asynchrone).confirmService:askrésolutrue→true,false→false, rejet →false+logWarn(mock de@tauri-apps/plugin-dialog).performRemoveLicense: confirmation résolue àfalse→ aucunremoveLicenseappelé ; idem pour la seconde confirmation (ligne 391). Le test doit rougir si l'awaitest retiré (unePromiseest vraie).awaitd'un site, remplacerconfirmActionparwindow.confirm, rendre le rejet deask« vrai ».Critères d'acceptation
confirm/alertnatif ne reste danssrc/hors du helper, et un test le garantit.npm run buildetnpm testverts ; CHANGELOG FR/EN à jour.Complexité estimée
Simple à moyenne : 6 sites mécaniques, un helper, un changement de signature dans
performRemoveLicenseet ses tests, un test de garde.Correctif mergé par la PR #465 (avance rapide par l'API,
mainff9656d,check-frontendvert, 2297 tests ; revue APPROVE de niveau haut au commentaire 24953, suggestion 1 appliquée en tête, commentaire 25025). Suggestion 2 en suivi : #467.L'issue reste ouverte (
status:blocked) : elle attend la vérification manuelle de Max, sur un build demainou sur la prochaine release..db(sousapp_config_dir()) toujours là ; recommencer puis Confirmer → supprimés. Boutons « Confirmer » / « Annuler » en français, « Confirm » / « Cancel » en anglais. Observer au passage leprompt()du PIN (issue séparée si la saisie échoue).Vérification manuelle faite par Max le 2026-10-18 sur la v0.17.2 publiée, sous Linux, installée par la mise à jour automatique depuis la v0.17.1 : concluante. Windows non déroulé ; le détail des sites essayés n'est pas consigné.
Correctif publié dans la v0.17.2 (PR #465,
ff9656d). Fermeture à la main sur décision de Max, la PR portantRefs #421. Reste en suivi : #467 (tests de comportement des quatre sites tenus par la seule garde).