Config UI: Add data management
Ref #6029, #13541
💾 download backup after typing in the password 🔄 restore previous downloaded backup 🔙 reset database
NOTE: Die evcc.yaml wird nicht berücksichtigt, es geht hier allein um die Datenbank.
TODO:
- [ ] add descriptions
- [ ] change filename to include UTC time for searching/filtering purposes (?)
- [ ] add tests
\cc @naltatis
Wow, das ist ja grossartig! Super Idee!
@Maschga habe die Beschreibungen hinzugefügt und ein bisschen was am Style gedreht: danger buttons, input-field style (anstatt btn) für den file upload.
Screenshot oben ist aktualisiert.
Mein erster manueller Test war auch erfolgreich. Hier werde ich aber auch noch mal intensiver testen, damit wir hier wirklich "solid" sind.
for searching/filtering purposes (?)
Only for uniqueness. We could also do a counter or something else. Just wanted to ensure, that we dont overwrite an existing file. Creation date in the os file system should be enough for later analysis.
@naltatis Die Komponenten für das Einloggen/Bestätigen sind jetzt aufgeteilt und der Backup-Dateiname wurde zu evcc-backup-YYYY-MM-DD--hh-mm.db geändert.
Am UI und an der Funktionalität hat sich nichts geändert.
@andig @naltatis Ich habe mich für die DELETE /system/cache Variante entschieden.
Jetzt wird auch beim Resetten auf / redirected, wenn die der Benutzer die EInstellungen zurückgesetzt hat.
Vorher gab es dadurch Überlappungen mit dem Set Password Modal.
Und das Confirm Modal wird nun auch nach dem Restore immer richtig geschlossen.
Struktur des Confirm Dialogs:
Eigener Titel je nach Aktion. Hier können wir einfach die Titel aus dem anderen Modal verwenden. Der Button ist aktuell immer "Login". Das ist vmtl. aus copy und paste :D
- Title: "Backup", Button (primary): "Download backup"
- Title: "Restore", Button (danger): "Restore & restart"
- Title: "Reset", Button (danger): "Reset & restart"
Den & restart Nachsatz finde ich gut weil der Nutzer dann weiß was passiert. Allerdings reicht es wenn wir den erst im Confirm Dialog haben. Im Hauptdialog kann der eigentlich raus. Macht es dort auch etwas übersichtlicher.
Die Tatsache, dass es eine Confirm Aktion ist wird von der Interaktion aus aus dem Beschreibungstext klar.
Ich würd auch noch einen "Cancel" Button (links) mit aufnehmen. Dann ist das symmetrisch zu "Restart Confirm" and "Delete Session Confirm".
Und das Confirm Modal wird nun auch nach dem Restore immer richtig geschlossen.
Das konnte ich in meinem Test nicht bestätigen. Ich habe restored. Der Layer blieb stehen und es gab Fehler in der Browser Console. Ähnlich wie bei Reset würde ich hier auch auf die Startseite springen.
Generelles Confirm-Pattern:
Unter macOS gibts das Muster, dass ein Button, der die Aktion noch nicht direkt ausführt mit … endet.
https://apple.stackexchange.com/a/459608
Wir haben noch nicht so viele stellen wo das relevant ist, aber wir könnten das Muster jetzt einführen. Also "Download Backup…" Button (öffnet confirm) im Datamanagement Dialog und "Download backup" (echte Aktion) im Confirm.
Update: Sehe gerade, dass das auch eine W3C ARIA Empfehlung ist: https://www.w3.org/WAI/ARIA/apg/patterns/button/
Zwischenstand:
✅ Komponenten vereinen
✅ showRestarting() bei restore und reset aufrufen
✅ Passworteingabe bei Reset
✅ Eigener Titel je nach Aktion
✅ Eigener Button je nach Aktion
✅ & restart erst im Confirm Dialog
✅ Cancel Button hinzufügen
✅ Confirm-Pattern umgesetzte
✅ Screenshots aktualisiert
Noch zu tun: ~~❌ Ausführlich getestet~~ ✅ ~~❌ SQLite: Ladevorgänge~~ ✅
Habe ich etwas vergessen?
Habe ich etwas vergessen?
Hab jetzt nur über die Code geschaut (noch nicht wieder getestet), aber sieht gut aus.
fyi @Maschga Ich hab jetzt angefangen e2e tests für die Funktionen zu schreiben.
I find "data management" a bit confusing/unusual. How about "Configuration Backup/Restore"?
How about adding the "Backup" button in the Reset dialog, too or link to Backup modal?
In terms of backup restore: do we want to allow selective action for charging sessions only? May be separate PR.
In terms of backup restore: do we want to allow selective action for charging sessions only? May be separate PR.
You mean only restore sessions and keep config. Would be tricky with our current db-file-based approach.
How about adding the "Backup" button in the Reset dialog, too or link to Backup modal?
Dont know what you mean here. What Reset Dialog? The reset confirm modal? I would prefer keeping the modal nesting as flat as possible.
I find "data management" a bit confusing/unusual. How about "Configuration Backup/Restore"?
I had a similar first reaction. We did a little bit of brainstorming, discussed different names and settled on this one. Mainly because we wanted something that describes all three actions. However I also like "Backup & Restore" / "Sichern & Wiederherstellen" because it is a very concrete and less generic term. It does not directly cover the "Reset" action, but it's not to unexpected to have it in there.
Dont know what you mean here. What Reset Dialog? The reset confirm modal? I would prefer keeping the modal nesting as flat as possible.
The one from the screenshot above. It asks to create a backup- why not simplify this?
Ok, we've agreed (Slack) to rename to "Backup & Restore".