To do: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 70: Zeile 70:
[[Keepcon.todo|todo keepcon]]<br>
[[Keepcon.todo|todo keepcon]]<br>
[[todo HTML-Vorlagen]]<br>
[[todo HTML-Vorlagen]]<br>
== 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

Version vom 15. Februar 2008, 18:21 Uhr

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