avenel / firstapp Goto Github PK

Beginnen mit Großbuchstaben

Alle Attribute werden nun groß geschrieben.

D) Tabelleninhalte in DB
Die erforderlichen Änderungen in A bis C betreffen die Tabelleninhalte m.E. nicht.

• Tabelle Buchung: Überschriften für die Spalten Punkte und PSaldoAcc sind noch nicht vertauscht, sonst o.k.
• Tabelle Buergschaft: Daten o.k. Der Primary Index is Pnr_B+Mnr_G+GueltigVon+SichEndDatum, d.h. die Tabellen sind noch nicht mit den create tables aus B) generiert. Hier muss die Konsistenz noch hergestellt werden. Bei anderen Tabellen habe ich das nicht im einzelnen nachgeprüft. Wie können wir sicherstellen, dass nur e i n Master verwendet wird und nicht x Versionen im Umlauf sind?
  -EEKonto: Die (stochastische) Reihenfolge der Spalten zeigt, dass die Tabelle nicht mit den create tables (Anhang zu B)) generiert wurde. Dateninhalte der Tabelle richtig migriert.
• Partner: Die Spalten Mnr und MnrO müssen vertauscht werden.
• Tabellen Teilnahme und Veranstaltung sind leer, d.h. sie wurden nicht migriert und müssen im Migrationstool ergänzt werden.
• Tabelle ZEKonto: Daten richtig migriert. Reihenfolge der Spalten entspricht nicht den aktuellen create table Anweisungen B)

#20

Komplette Validierung fehlt -> muss implementiert werden.

Switch "Punkte" and "PSaldoAcc"

Es werden nun grundsätzlich alle Attribute GROß geschrieben.
Keine Lust mehr auf das durcheinander...

Es wird ein Test benötigt, der jedes Modell testet, welches das HistoricRecord implementiert. Es soll dabei sichergestellt werden, dass die Historisierung funktioniert.

Modelle:

Adresse [x]
Bankverbindung [x]
Buergschaft [x]
EEKonto [x]
Foerdermitglied [x]
Gesellschafter [x]
Mitglied [x]
OZBKonto [x]
Partner [x]
Person [x]
Student [x]
ZEKonto [x]

#20

1. KKLAbDatum war als PK-Bestandteil auskommentiert.
   Gefundene Begründung (SS12): "Nach Datenbankschema besitzt die Tabelle kklverlauf zwei Primärschlüssel, wobei jedoch
   leider - aufgrund von Problemen mit dem gem composite_primary_keys - auf den zweiten
   Primärschlüssel KKLAbDatum verzichtet werden muss. Hier wäre evtl. ein before_save Callback möglich, der beim Ändern eines Datensatzes, nur einen neuen Datensatz hinzufügt,
   statt den alten zu löschen. "

Habe ich wieder einkommentiert und genutzt.

[ERLEDIGT]2) KklVerlauf is invalid with an not existing OZBKonto
Failure/Error: expect(FactoryGirl.create(:kklverlauf_with_kontenklasse, :KtoNr => 98792)).to be_invalid
expected invalid? to return true, got false

Muss noch untersucht werden

3. Methode destroy_historic_records (after_destroy):
   Use-Case ist unklar, weshalb ältere Verläufe der Kontenklasse mitgelöscht werden sollen?

Ein sehr häufiger Testfall ist der Vergleich von Kontenanzeigen auf dem Testsystem mit den gleichen auf dem produktiven System. Ein einfaches und überschaubares Beispiel wäre der Vergleich der Kontenanzeigen 70073 (S. 7-9), sowie 10073 (S. 10-12) in beigefügtem Testbericht IV vom 11.04.13 (die Punkterechnungen auf dem Testsystem sind übrigens immer noch auf diesem Stand, wie ich vorhin festgestellt habe). Der Testbericht enthält Kontenvergleich für Mitglied 38, 7 und 73.

Aufgrund der Tatsache das im Webimport die Buchungen ohne Punktberechnungen abgespeichert werden, bevor diese stattfinden, muss der NOT NULL Constraing im SQL Schema erst einmal weichen. Dieser Constraint kann dann im Model "Buchung" hinzugefügt werden.

Dieser Test ersetzt die Tests für die Historisierung in den Model specs selbst.

[x] Person
[x] Adresse
[x] OZBPerson
[x] Mitglied
[x] Gesellschafter
[x] Student
[x] Foerdermitglied
[x] Veranstaltungsart
[x] Veranstaltung
[x] Teilnahme
[x] Partner
[x] Telefon
[x] Tanliste
[x] Tan
[x] Bank
[x] Bankverbindung
[x] OZBKonto
[x] EEKonto
[x] ProjektGruppe
[x] ZEKonto
[x] Buergschaft
[x] KontenKlasse
[x] KKLVerlauf
[x] Buchung
[x] BuchungOnline
[x] Sonderberechtigung
[x] Geschaeftsprozess
[x] Umlage

Angepasst != komplett!

Units [angepasst]:

• Person [x]
• OZBPerson [x]
• OZBKonto [x]
• Bankverbindung [x]
• Bank [x]
• ZEKonto [x]
• EEKonto [x]
• KKLVerlauf [x]
• Buchung [x]
• Kontenklasse [x]
• Projektgruppe [x]
• Buergschaft [x]

https://www.ruby-toolbox.com/categories/code_metrics

• Deployment Process: What is "Deployment"? What do we use? (Apache, Passenger, Capistrano)
• Versioncontrol Management: What is it? What do we use? (Git)
• Workflow: How do we deploy?

TinyIntegers should be unsigned.

Den aktuellen Stand auf das OZBTestsystem ausrollen und Herrn Kienle benachrichtigen.

We use passenger with apache as Application/Webserver
Use touch .../tmp/restart.txt to restart the app
We use git instead of mercurial
...

B) Bei den create table Anweisungen gibt es ebenfalls nur Kleinigkeiten zu ändern (s. meine Kommentare im Anhang, am beten mit Wordpad editieren):

• Primary Key immer vor Foreign Key
• Foreign Key Klauseln ergänzen bei den Tabellen Gesellschafter, Partner, Mitglied und Student
• Primary Key bei Tabelle Umlage ergänzen
• Konsistenz der Schreibweise (Großschreibung) herstellen.

Rename foreign key "vid" -> "VANr" in table "Veranstaltung"

Es soll ein extra Model für einen Login geben, um auch Nicht-OZB Mitgliedern (wie z.B. dem OZB Partner) die Gelegenheit zu geben, sich bei der Anwendung anmelden zu können.

=> Technische und Fachliche Attribute trennen.
=> Neues Model "Login", dass Devise umsetzt.