Todo.md
habe mit chat einwenig gebrainstormd fuer aufgarben die wir dan uns zuteilen koennen um sie abzuarbeiten 👍
This commit is contained in:
167
todos.md
Normal file
167
todos.md
Normal file
@@ -0,0 +1,167 @@
|
||||
# DefektTrack – Development TODO Roadmap
|
||||
|
||||
Ziel: Aufbau eines sicheren, rollenbasierten Defekt- und Retouren-Management-Systems für Lager, Service und Management.
|
||||
|
||||
---
|
||||
|
||||
# PRIORITY 1 – CORE SECURITY & ACCESS
|
||||
|
||||
## 1. Login-Gate vor dem Laden der App
|
||||
Die eigentliche Anwendung darf erst geladen werden, nachdem sich ein Nutzer erfolgreich authentifiziert hat.
|
||||
|
||||
## 2. Session-System (Login bleibt bis Browser geschlossen wird)
|
||||
Der Login bleibt aktiv, bis der Browser geschlossen wird, damit Mitarbeiter nicht ständig neu einloggen müssen.
|
||||
|
||||
## 3. Benutzerverwaltung (Admin)
|
||||
Ein Administrator muss neue Benutzer anlegen, deaktivieren und verwalten können.
|
||||
|
||||
## 4. Rollen-System
|
||||
Jeder Benutzer erhält intern eine Rolle (z.B. Lager, Service, Filialleiter, Firmenleiter), die bestimmt, welche Funktionen und Ansichten sichtbar sind.
|
||||
|
||||
## 5. Startpasswort-System
|
||||
Neue Benutzer erhalten ein Standardpasswort (z.B. 0000), das nach dem ersten Login geändert werden muss.
|
||||
|
||||
## 6. Passwort-Änderungspflicht
|
||||
Startpasswörter müssen innerhalb von 24 Stunden geändert werden, sonst wird eine Warnung oder Benachrichtigung ausgelöst.
|
||||
|
||||
## 7. PIN-Login-System
|
||||
Login erfolgt über Benutzername + 4-stelligen PIN, den der Benutzer nach dem ersten Login selbst festlegt.
|
||||
|
||||
## 8. Passwort-Hashing
|
||||
Passwörter oder PINs dürfen niemals im Klartext gespeichert werden, sondern müssen gehasht gespeichert werden.
|
||||
|
||||
## 9. Zugriffskontrolle (Role Based Access Control)
|
||||
Das Backend muss prüfen, ob ein Benutzer berechtigt ist, eine Aktion auszuführen.
|
||||
|
||||
## 10. Audit-Log
|
||||
Alle wichtigen Aktionen (Login, Statusänderung, Löschen, Benutzeränderungen) müssen protokolliert werden.
|
||||
|
||||
---
|
||||
|
||||
# PRIORITY 2 – USER EXPERIENCE & DASHBOARDS
|
||||
|
||||
## 11. Rollenbasierte Startseiten
|
||||
Nach dem Login erhält jeder Benutzer eine andere Startseite abhängig von seiner Rolle.
|
||||
|
||||
## 12. Lagerkraft-Startseite
|
||||
Zeigt primär offene Artikel und operative Aufgaben.
|
||||
|
||||
## 13. Service-Startseite
|
||||
Zeigt Artikel in Bearbeitung, technische Prüfungen und Kommentare.
|
||||
|
||||
## 14. Filialleiter-Dashboard
|
||||
Zeigt Statistiken und Übersicht über alle Defektfälle der Filiale.
|
||||
|
||||
## 15. Firmenleiter-Dashboard
|
||||
Zeigt Gesamtstatistiken über alle Filialen und Unternehmensdaten.
|
||||
|
||||
## 16. Automatische Filter je Rolle
|
||||
Standardfilter werden automatisch gesetzt (z.B. Lager sieht offene Fälle zuerst).
|
||||
|
||||
---
|
||||
|
||||
# PRIORITY 3 – DEFECT MANAGEMENT CORE
|
||||
|
||||
## 17. Defektfall-System
|
||||
Das zentrale Objekt der App ist ein Defektfall mit Artikel-, Serien- und Fehlerinformationen.
|
||||
|
||||
## 18. Status-Workflow
|
||||
Statussystem für Fälle (Offen → In Bearbeitung → Erledigt → Entsorgt).
|
||||
|
||||
## 19. Prioritätssystem
|
||||
Fälle erhalten Prioritäten (niedrig, mittel, hoch, kritisch).
|
||||
|
||||
## 20. Verantwortlichkeits-System
|
||||
Jeder Defektfall muss einem Mitarbeiter zugewiesen werden.
|
||||
|
||||
## 21. Kommentar-System
|
||||
Interne Kommentare und technische Notizen zu jedem Defektfall.
|
||||
|
||||
## 22. Defekt-Historie
|
||||
Alle Änderungen eines Falls müssen nachvollziehbar gespeichert werden.
|
||||
|
||||
---
|
||||
|
||||
# PRIORITY 4 – SEARCH & FILTERING
|
||||
|
||||
## 23. Erweiterte Suche
|
||||
Suche nach ERL-Nummer, Seriennummer, Artikelnummer oder Beschreibung.
|
||||
|
||||
## 24. Statusfilter
|
||||
Filter für offene, in Bearbeitung befindliche, erledigte oder entsorgte Artikel.
|
||||
|
||||
## 25. Prioritätsfilter
|
||||
Filter für kritische oder wichtige Fälle.
|
||||
|
||||
## 26. Mitarbeiterfilter
|
||||
Anzeige der Fälle nach zuständigem Mitarbeiter.
|
||||
|
||||
---
|
||||
|
||||
# PRIORITY 5 – STATISTICS & ANALYTICS
|
||||
|
||||
## 27. Mitarbeiterstatistiken
|
||||
Eigene offenen, erledigten und überfälligen Fälle eines Mitarbeiters.
|
||||
|
||||
## 28. Filialstatistiken
|
||||
Übersicht über Defektfälle und Bearbeitungsstatus innerhalb einer Filiale.
|
||||
|
||||
## 29. Unternehmensstatistiken
|
||||
Gesamtübersicht aller Filialen mit Vergleich der Leistungskennzahlen.
|
||||
|
||||
## 30. Bearbeitungszeit-Analyse
|
||||
Durchschnittliche Dauer vom Anlegen bis zur Lösung eines Defektfalls.
|
||||
|
||||
## 31. Häufigste Defekte
|
||||
Statistik über häufig auftretende Fehlerarten oder Artikelprobleme.
|
||||
|
||||
---
|
||||
|
||||
# PRIORITY 6 – ORGANISATION STRUCTURE
|
||||
|
||||
## 32. Filial-System
|
||||
Unterstützung mehrerer Standorte innerhalb eines Unternehmens.
|
||||
|
||||
## 33. Standortzuweisung für Benutzer
|
||||
Benutzer gehören zu einer bestimmten Filiale.
|
||||
|
||||
## 34. Standortfilter für Daten
|
||||
Filialleiter sehen nur Daten ihrer Filiale, Firmenleiter sehen alle Daten.
|
||||
|
||||
---
|
||||
|
||||
# PRIORITY 7 – SYSTEM FEATURES
|
||||
|
||||
## 35. Export-Funktion
|
||||
Datenexport für Berichte oder Archivierung.
|
||||
|
||||
## 36. Import-Funktion
|
||||
Import von Datensätzen für Migration oder Synchronisation.
|
||||
|
||||
## 37. Druckansicht
|
||||
Optimierte Druckansicht für Berichte oder Listen.
|
||||
|
||||
## 38. Benachrichtigungen
|
||||
Systemmeldungen bei kritischen oder überfälligen Defektfällen.
|
||||
|
||||
---
|
||||
|
||||
# PRIORITY 8 – FUTURE FEATURES
|
||||
|
||||
## 39. Datei-Uploads
|
||||
Anhänge wie Fotos von Schäden oder Dokumente zu Defektfällen.
|
||||
|
||||
## 40. Mobile Optimierung
|
||||
Optimierte Nutzung für Tablets oder mobile Geräte im Lager.
|
||||
|
||||
## 41. API-Schnittstellen
|
||||
Möglichkeit zur Integration mit anderen Systemen.
|
||||
|
||||
## 42. Automatische Eskalationen
|
||||
Fälle werden automatisch markiert, wenn sie zu lange unbearbeitet bleiben.
|
||||
|
||||
---
|
||||
|
||||
# PROJECT GOAL
|
||||
|
||||
Ein sicheres, rollenbasiertes System zur Verwaltung defekter Artikel in Lager, Service und Management mit klaren Verantwortlichkeiten, Nachverfolgbarkeit und statistischen Auswertungen.
|
||||
Reference in New Issue
Block a user