To do
Bugs (bekannte Fehler)
Bugs (Codegear)
Baseupdate
// // todo // // * Jede Metadata Modifikation sollte kurz prüfen, ob das Statement selbst // in der Datenbank schon realisiert wurde oder nicht - es wäre cool, wenn eine // Wissensdatenbank 'Quell-Satements' automatisiert in Ziel-Statements umwandeln // könnte. Dazu könnten bestimmte Klassen (list TABLEs , list Fields ,list FK_Check) usw. // Oder man könnte mal schnell das Metadatenextract nach den passenden stellen // durchsuchen lassen! // * autoupdate sollte das "Schild" Symbol von Windows XP bekommen // * autoupdate sollte mehr unter der Haube funktionieren. Nicht so viele // Admin-Schalter die sollten auf die rechner Verwaltung verschoben werden. // * No-MetaDatachange (neues Feld in der Revisionstabelle): Soll anzeigen ob der aktuelle // Release-Sprung ohne Meta-Data Änderung möglichch war? Dann gelten "ältere" Releases // als "auch lauffähig" da sie zumindest in der Datenbank keinen Schaden anrichten. // // * Wenn OrgaMon von aussen beendet wird: wait "OrgaMon" to be down! OrgaMon sollte // einen "InsideTRN" Flag pflegen, damit erkannt werden kann, ob gerade eine wichtige // längere Aktion vorliegt. Er muss gewartet werden bis zu Ende gebucht ist. So dass // das Beenden von aussen nicht "kritisch" ist. Zumindest das eCommerce-Modul sollte so // etwas haben. // * Noch cooler, neben dem check auf ein Undo - also ein "extern" rollback // "one single step" <do it statement>: // -> check-statement:boolean; true: "schon erledigt", false "muss ich noch machen" // -> do-it-statement:boolean; wie gehabt // -> undo-it-statement:boolean; // * ./Updates Verzeichnis leeren! // * Released: Ein Flag das gesetzt wird, wenn es diese Version aus einem der Standard // Release-Medien stammt. (Developer releases setzen dieses Flag nicht) // * Problem: Der Entwickler hat in die Rev-Tabelle schon eine neuere Rev Nummer eingetragen // diese aber noch nicht released, in so einem Fall sollte sich baseupdate mit einer // Release drunter begnügen. Der entwickler muss eine release machen, damit andere // weiterarbeiten können. //
todo Versand
todo System
todo Kunden
todo Belege
todo Artikel
todo Sonstiges
todo Lager
todo Konten
todo WebShop
Todo Qualitaetssicherung
todo Musikverlag
todo Resourcemanagement
todo ErgoPrax
todo IT-Freiberufler
todo IT-Dienstleister
todo Landschaftspflege
todo Schlosserei
todo MonDa
todo JonDa
todo Geolokalisierung
todo Buchhaltung
todo Mailing
todo i18n
todo SQL
todo amerikanischer Kunde
todo keepcon
todo HTML-Vorlagen
Caretaker
* Zwang zur einer De-Escalationsmassnahme ist absolut notwendig, ev. sollte das System stoppen und "Top 5" Massnahmen müssen ergriffen werden.
Qualität
- gewisse Zustände gehen ein in die Q-Zahl.
- Die neutrale Froderung ist 100% (besser>100, schlechter<100)
- Es gibt Q-Rubriken, diese bilden die Gesatm Q mit gewisser Gewichtung
- Jede Q-Komponenete sollte anklickbar (und löschbar sein)
- überfällige Mahnungen
- überfällige Zusagen