X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Fdokumentation.xml;h=801814342b362b6762a9c62d7ad5c5bd463746c7;hb=1cc72c5b3b422fcd5970b3072d0d922d89fffc13;hp=3635f6228746fe6c888efffa6069e7ff9c34be19;hpb=dbda14c263efd93aca3b7114015a47d86b8581e3;p=kivitendo-erp.git
diff --git a/doc/dokumentation.xml b/doc/dokumentation.xml
index 3635f6228..801814342 100644
--- a/doc/dokumentation.xml
+++ b/doc/dokumentation.xml
@@ -80,7 +80,7 @@
Debian
- 6.0 "Squeeze" (hier muss allerdings das Modul FCGI in der Version >= 0.72 compiled werden)
+ 6.0 "Squeeze" (hier muss allerdings das Modul FCGI in der Version >= 0.72 compiled werden, und Rose::DB::Object ist zu alt)
7.0 "Wheezy"
@@ -89,11 +89,11 @@
- Ubuntu 10.04 LTS "Lucid Lynx", 12.04 LTS "Precise Pangolin" und 12.10 "Oneiric Ocelot"`
+ Ubuntu 12.04 LTS "Precise Pangolin", 12.10 "Quantal Quetzal" und 13.04 "Precise Pangolin"
- openSUSE 12.1 und 12.2
+ openSUSE 12.2 und 12.3
@@ -101,7 +101,7 @@
- Fedora 16 und 17
+ Fedora 16 bis 19
@@ -110,7 +110,7 @@
Benötigte Perl-Pakete installieren
Zum Betrieb von kivitendo werden zwingend ein Webserver (meist
- Apache) und ein Datenbankserver (PostgreSQL, mindestens v8.2)
+ Apache) und ein Datenbankserver (PostgreSQL, mindestens v8.4)
benötigt.
Zusätzlich benötigt kivitendo einige Perl-Pakete, die nicht Bestandteil einer Standard-Perl-Installation sind. Um zu
@@ -160,7 +160,7 @@
Rose::DB
- Rose::DB::Object
+ Rose::DB::Object Version 0.788 oder neuer
Template
@@ -175,6 +175,8 @@
YAML
+ Seit v3.0.0 sind die folgenden Pakete hinzugekommen: File::Copy::Recursive.
+
Seit v2.7.0 sind die folgenden Pakete hinzugekommen: Email::MIME, Net::SMTP::SSL,
Net::SSLGlue.
@@ -439,10 +441,10 @@ exit
Andernfalls ist es notwendig, einen neuen Datenbankcluster mit
Unicode-Encoding anzulegen und diesen zu verwenden. Unter Debian und
- Ubuntu kann dies z.B. für PostgreSQL 8.2 mit dem folgenden Befehl
+ Ubuntu kann dies z.B. für PostgreSQL 9.3 mit dem folgenden Befehl
getan werden:
- pg_createcluster --locale=de_DE.UTF-8 --encoding=UTF-8 8.2 clustername
+ pg_createcluster --locale=de_DE.UTF-8 --encoding=UTF-8 9.3 clustername
Die Datenbankversionsnummer muss an die tatsächlich verwendete
Versionsnummer angepasst werden.
@@ -1619,7 +1621,7 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
Wenn sich das Problem nicht auf Grund der ausgabe im Webbrowser verifizieren lässt:
- editiere [kivitendo-home]/config/kivitendo.conf und ändere "keep_tmp_files" auf 1
+ editiere [kivitendo-home]/config/kivitendo.conf und ändere "keep_temp_files" auf 1
keep_temp_files = 1;
@@ -5458,29 +5460,17 @@ file = /tmp/kivitendo-debug.log
xreflabel="Einführung in die Datenbank-Upgradedateien">
Einführung
- Der alte Mechanismus für SQL-Upgradescripte, der auf einer
- Versionsnummer beruht und dann in sql/Pg-upgrade nach einem Script für
- diese Versionsnummer sucht, schränkt sehr ein, z.B. was die parallele
- Entwicklung im stable- und unstable-Baum betrifft.
-
- Dieser Mechanismus wurde für kivitendo 2.4.1 deutlich erweitert.
- Es werden weiterhin alle Scripte aus sql/Pg-upgrade ausgeführt.
- Zusätzlich gibt es aber ein zweites Verzeichnis, sql/Pg-upgrade2. In
- diesem Verzeichnis muss pro Datenbankupgrade eine Datei existieren,
- die neben den eigentlich auszuführenden SQL- oder Perl-Befehlen einige
- Kontrollinformationen enthält.
-
- Neu sind die Kontrollinformationen, die Abhängigkeiten und
- Prioritäten definieren können werden, sodass Datenbankscripte zwar in
- einer sicheren Reihenfolge ausgeführt werden (z.B. darf ein "ALTER
- TABLE" erst ausgeführt werden, wenn die Tabelle mit "CREATE TABLE"
- angelegt wurde), diese Reihenfolge aber so flexibel ist, dass man
- keine Versionsnummern mehr braucht.
-
- kivitendo merkt sich dabei, welches der Upgradescripte in
- sql/Pg-upgrade2 bereits durchgeführt wurde und führt diese nicht
- erneut aus. Dazu dient die Tabelle "schema_info", die bei der
- Anmeldung automatisch angelegt wird.
+ Datenbankupgrades werden über einzelne Upgrade-Scripte gesteuert, die sich im Verzeichnis sql/Pg-upgrade2
+ befinden. In diesem Verzeichnis muss pro Datenbankupgrade eine Datei existieren, die neben den eigentlich auszuführenden SQL- oder
+ Perl-Befehlen einige Kontrollinformationen enthält.
+
+ Kontrollinformationen definieren Abhängigkeiten und Prioritäten, sodass Datenbankscripte zwar in einer sicheren Reihenfolge
+ ausgeführt werden (z.B. darf ein ALTER TABLE erst ausgeführt werden, wenn die Tabelle mit CREATE
+ TABLE angelegt wurde), diese Reihenfolge aber so flexibel ist, dass man keine Versionsnummern braucht.
+
+ kivitendo merkt sich dabei, welches der Upgradescripte in sql/Pg-upgrade2 bereits durchgeführt wurde und
+ führt diese nicht erneut aus. Dazu dient die Tabelle "schema_info", die bei der Anmeldung automatisch angelegt
+ wird.
Alle Tests liegen im Unterverzeichnis t/.
- Ein Script (bzw. ein Test) in f/ enthält einen oder mehrere Testfälle.
+ Ein Script (bzw. ein Test) in t/ 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
+ Die Test-Suite besteht aus der Gesamtheit aller Tests, sprich aller Scripte in t/, deren
Dateiname auf .t endet.
@@ -5953,7 +5943,16 @@ filenames
Test::Harness 3.0.0 oder höher. Dieses Modul ist ab Perl 5.10.1 Bestandteil der
Perl-Distribution und kann für frühere Versionen aus dem CPAN bezogen
werden.
+ LWP::Simple aus dem Paket libwww-perl (Debian-Panetname:
+ libwww-perl; Fedora Core: perl-libwww-perl; openSUSE:
+ perl-libwww-perl)
+ URI::Find (Debian-Panetname: liburi-find-perl; Fedora Core:
+ perl-URI-Find; openSUSE: perl-URI-Find)
+
+ Weitere Voraussetzung ist, dass die Testsuite ihre eigene Datenbank anlegen kann, um Produktivdaten nicht zu gefährden. Dazu
+ müssen in der Konfigurationsdatei im Abschnit testing/database Datenbankverbindungsparameter angegeben
+ werden. Der hier angegebene Benutzer muss weiterhin das Recht haben, Datenbanken anzulegen und zu löschen.
@@ -5962,14 +5961,14 @@ filenames
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.
+ gezielt einzelne Scripte aus. Für beide Fälle gibt es das Helferscript t/test.pl.
- Will man die komplette Test-Suite ausführen, so muss man einfach nur t/test.sh ohne weitere Parameter aus
+ Will man die komplette Test-Suite ausführen, so muss man einfach nur t/test.pl 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:
+ Um einzelne Test-Scripte auszuführen, übergibt man deren Namen an t/test.pl. Beispielsweise:
- t/test.sh t/form/format_amount.t t/background_job/known_jobs.t
+ t/test.pl t/form/format_amount.t t/background_job/known_jobs.t
@@ -6006,7 +6005,7 @@ filenames
Ideen für neue Test-Scripte, die keine konkreten Funktionen testen
- Ideen, die abgesehen von Funktions noch nicht umgesetzt wurden:
+ Ideen, die abgesehen von Funktionen noch nicht umgesetzt wurden:
Ãberprüfung auf fehlende symbolische Links
@@ -6031,7 +6030,7 @@ filenames
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
+ Unterverzeichnisse sollten grob nach dem Themenbereich benannt sein, 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