X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=sidebyside;f=doc%2Fdokumentation.xml;h=25b52d39ecf6d037c0c2e32362857409cc6b3be6;hb=d00e1b28dc8b03abfebf5c7be9305f01dc968ebc;hp=b053c3f1b2309d691811d689ce8f2edcf01e3d07;hpb=5fa26f9a276487b08665bcefe36986bb66b9a3d7;p=kivitendo-erp.git
diff --git a/doc/dokumentation.xml b/doc/dokumentation.xml
index b053c3f1b..25b52d39e 100644
--- a/doc/dokumentation.xml
+++ b/doc/dokumentation.xml
@@ -415,14 +415,17 @@ dbcharset = UTF-8
Zeichensätze/die Verwendung von UTF-8
- kivitendo kann komplett mit UTF-8 als Zeichensatz verwendet
- werden. Dabei gibt es zwei Punkte zu beachten: PostgreSQL muss in
- Version 8.2 oder neuer benutzt werden, und der
- PostgreSQL-Datenbankcluster muss ebenfalls mit UTF-8 als Locale
- angelegt worden sein.
+ Bei aktuellen Serverinstallationen braucht man hier meist nicht
+ eingreifen
+
+ Dieses kann überprüft werden: ist das Encoding der Datenbank
+ âtemplate1â âUTF8â, so braucht man nichts weiteres diesbezueglich
+ unternehmen. Zum Testen:
+
+ su postgres
+echo '\l' | psql
+exit
- Dieses ist kann überprüft werden: ist das Encoding der Datenbank
- âtemplate1â âUTF8â, so kann auch kivitendo mit UTF-8 betrieben werden.
Andernfalls ist es notwendig, einen neuen Datenbankcluster mit
UTF-8-Encoding anzulegen und diesen zu verwenden. Unter Debian und
Ubuntu kann dies z.B. für PostgreSQL 8.2 mit dem folgenden Befehl
@@ -460,14 +463,9 @@ dbcharset = UTF-8
In der Datei pg_hba.conf, die im gleichen
Verzeichnis wie die postgresql.conf zu finden
sein sollte, müssen die Berichtigungen für den Zugriff geändert
- werden. Hier gibt es mehrere Möglichkeiten. Eine besteht darin, lokale
- Verbindungen immer zuzulassen:
-
- local all all trust
-host all all 127.0.0.1 255.0.0.0 trust
-
- Besser ist es, für eine bestimmte Datenbank Zugriff nur per
- Passwort zuzulassen. Beispielsweise:
+ werden. Hier gibt es mehrere Möglichkeiten. sinnvoll ist es nur die
+ nögiten Verbindungen immer zuzulassen, für eine lokal laufenden
+ Datenbank zum Beispiel:
local all kivitendo password
host all kivitendo 127.0.0.1 255.255.255.255 password
@@ -478,10 +476,14 @@ host all kivitendo 127.0.0.1 255.255.255.255 password
In der Datenbank template1 muss die
Unterstützung für servergespeicherte Prozeduren eingerichet werden.
- Melden Sie sich dafür als Benutzer âpostgresâ an der Datenbank an, und
+ Melden Sie sich dafür als Benutzer âpostgresâ an der Datenbank an:
+ su - postgres
+psql template1
+
führen Sie die folgenden Kommandos aus:
- create language 'plpgsql';
+ create language 'plpgsql';
+\q
@@ -492,7 +494,9 @@ host all kivitendo 127.0.0.1 255.255.255.255 password
anlegen. Ein Beispiel, wie Sie einen neuen Benutzer anlegen
können:
- su - postgres createuser -d -P kivitendo
+ su - postgres
+createuser -d -P kivitendo
+exit
Wenn Sie später einen Datenbankzugriff konfigurieren, verändern
Sie den evtl. voreingestellten Benutzer âpostgresâ auf âkivitendoâ bzw.
@@ -861,6 +865,22 @@ insserv kivitendo-task-server
Dieselben Optionen können auch für die SystemV-basierenden
Runlevel-Scripte benutzt werden (siehe oben).
+
+ Task-Server mit mehreren Mandanten
+
+ Beim Task-Server wird der Login-Name des Benutzers, unter dem der
+ Task-Server laufen soll, in die Konfigurationsdatei geschrieben. Hat
+ man mehrere Mandanten muà man auch mehrere Konfigurationsdateien
+ anlegen.
+
+ Die Konfigurationsdatei ist eine Kopie der Datei kivitendo.conf,
+ wo in der Kategorie [task_server] der gewünschte "login" steht.
+
+ Der alternative Task-Server wird dann mit folgendem Befehl
+ gestartet:
+
+ ./scripts/task_server.pl -c config/DATEINAME.conf
+
@@ -2193,6 +2213,14 @@ insserv kivitendo-task-server
dem Kürzel das im Dateinamen verwendetet wird.
+
+
+ template_meta.tmpfile
+
+
+ Datei-Prefix für temporäre Dateien.
+
+
@@ -4077,7 +4105,7 @@ insserv kivitendo-task-server
Mittels != anstelle von ==
würde auf Ungleichheit getestet.
- %if var1 == var2%>
+ <%if var1 == var2%>
Testet die Variable var1 auf
übereinstimmung mit der Variablen var2. Mittel
@@ -5401,6 +5429,148 @@ filenames
+
+ Die kivitendo-Test-Suite
+
+
+ Einführung
+
+ kivitendo enthält eine Suite für automatisierte Tests. Sie basiert auf dem Standard-Perl-Modul Test::More.
+
+ Die grundlegenden Fakten sind:
+
+
+ Alle Tests liegen im Unterverzeichnis t/.
+
+ Ein Script (bzw. ein Test) in f/ enthält einen oder mehrere Testfälle.
+
+ Alle Dateinamen von Tests enden auf .t. Es sind selbstständig ausführbare Perl-Scripte.
+
+ Die Test-Suite besteht aus der Gesamtheit aller Tests, sprich aller Scripte in f/, deren
+ Dateiname auf .t endet.
+
+
+
+
+ Voraussetzungen
+
+ Für die Ausführung werden neben den für kivitendo eh schon benötigten Module noch weitere Perl-Module benötigt. Diese sind:
+
+
+ Test::Deep (Debian-Paketname: libtest-deep-perl; Fedora Core:
+ perl-Test-Deep; openSuSE: perl-Test-Deep)
+
+
+
+
+
+ Existierende Tests ausführen
+
+
+ Es gibt mehrere Möglichkeiten zum Ausführen der Tests: entweder, man lässt alle Tests auf einmal ausführen, oder man führt
+ gezielt einzelne Scripte aus. Für beide Fälle gibt es das Helferscript t/test.sh.
+
+ Will man die komplette Test-Suite ausführen, so muss man einfach nur t/test.sh ohne weitere Parameter aus
+ dem kivitendo-Basisverzeichnis heraus ausführen.
+
+ Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an t/test.sh. Beispielsweise:
+
+ t/test.sh t/form/format_amount.t t/background_job/known_jobs.t
+
+
+
+
+
+ Bedeutung der verschiedenen Test-Scripte
+
+
+ Die Test-Suite umfasst Tests sowohl für Funktionen als auch für Programmierstil. Einige besonders zu erwähnende, weil auch
+ während der Entwicklung nützliche Tests sind:
+
+
+ t/001compile.t -- compiliert alle Quelldateien und bricht bei Fehlern sofort ab
+ t/002goodperl.t -- überprüft alle Perl-Dateien auf Anwesenheit von 'use strict'-Anweisungen
+ t/003safesys.t -- überprüft Aufrufe von system() und exec() auf Gültigkeit
+ t/005no_tabs.t -- überprüft, ob Dateien Tab-Zeichen enthalten
+ t/006spelling.t -- sucht nach häufigen Rechtschreibfehlern
+ t/011pod.t -- überprüft die Syntax von Dokumentation im POD-Format auf Gültigkeit
+
+
+ Weitere Test-Scripte überprüfen primär die Funktionsweise einzelner Funktionen und Module.
+
+
+
+
+ Neue Test-Scripte erstellen
+
+
+ Es wird sehr gern gesehen, wenn neue Funktionalität auch gleich mit einem Test-Script abgesichert wird. Auch bestehende
+ Funktion darf und soll ausdrücklich nachträglich mit Test-Scripten abgesichert werden.
+
+
+
+ Ideen für neue Test-Scripte, die keine konkreten Funktionen testen
+
+
+ Ideen, die abgesehen von Funktions noch nicht umgesetzt wurden:
+
+
+ Ãberprüfung auf fehlende symbolische Links
+ Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit gewissen Einschränkungen wie das Erlauben von deutschen Umlauten)
+ Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)
+ Ãberprüfung auf Leerzeichen am Ende von Zeilen
+ Test, ob alle zu übersetzenden Strings in locale/de/all vorhanden sind
+ Test, ob alle Webseiten-Templates in templates/webpages mit vom Perl-Modul Template compiliert werden können
+
+
+
+
+
+ Konvention für Verzeichnis- und Dateinamen
+
+
+ Es gibt momentan eine wenige Richtlinien, wie Test-Scripte zu benennen sind. Bitte die folgenden Punkte als Richtlinie betrachten und ihnen soweit es geht folgen:
+
+
+ Die Dateiendung muss .t lauten.
+
+ Namen sind englisch, komplett klein geschrieben und einzelne Wörter mit Unterstrichten getrennt (beispielsweise
+ bad_function_params.t).
+
+ Unterverzeichnisse sollten grob nach dem Themenbereich benannt sind, mit dem sich die Scripte darin befassen
+ (beispielsweise background_jobs für Tests rund um Hintergrund-Jobs).
+
+ Test-Scripte sollten einen überschaubaren Bereich von Funktionalität testen, der logisch zusammenhängend ist
+ (z.B. nur Tests für eine einzelne Funktion in einem Modul). Lieber mehrere Test-Scripte schreiben.
+
+
+
+
+
+ Minimales Skelett für eigene Scripte
+
+
+ Der folgenden Programmcode enthält das kleinstmögliche Testscript und kann als Ausgangspunkt für eigene Tests verwendet werden:
+
+ use Test::More tests => 0;
+
+use lib 't';
+
+use Support::TestSetup;
+
+Support::TestSetup::login();
+
+ Wird eine vollständig initialisierte kivitendo-Umgebung benötigt (Stichwort: alle globalen Variablen wie
+ $::auth, $::form oder $::lxdebug), so muss in der Konfigurationsdatei
+ config/kivitendo.conf im Abschnitt testing.login ein gültiger Login-Name eingetragen
+ sein. Dieser wird für die Datenbankverbindung benötigt.
+
+ Wir keine vollständig initialisierte Umgebung benötigt, so kann die letzte Zeile Support::TestSetup::login();
+ weggelassen werden, was die Ausführungszeit des Scripts leicht verringert.
+
+
+
+
Stil-Richtlinien