X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=sidebyside;f=doc%2Fdokumentation.xml;h=0a61691068478450318eafb26cd0455da19231ae;hb=3bb283ad739b95704f8df9a55c1ed0b86f617f23;hp=1c5f93ca785b7ffd1eaa451ed2afb524965975f6;hpb=854c9a6232e12ef7f54ed97c5065c19a1d9ab5f1;p=kivitendo-erp.git
diff --git a/doc/dokumentation.xml b/doc/dokumentation.xml
index 1c5f93ca7..0a6169106 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"
@@ -93,7 +93,7 @@
- openSUSE 12.1 und 12.2
+ openSUSE 12.2 und 12.3
@@ -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.
@@ -381,10 +383,7 @@ host = localhost
port = 5432
db = kivitendo_auth
user = postgres
-password =
-
-[system]
-dbcharset = UTF-8
+password =
Nutzt man wiederkehrende Rechnungen, kann man unter
[periodic_invoices] den Login eines Benutzers
@@ -428,21 +427,20 @@ dbcharset = UTF-8
PostgreSQL muss auf verschiedene Weisen angepasst werden.
- Zeichensätze/die Verwendung von UTF-8
+ Zeichensätze/die Verwendung von Unicode/UTF-8
- Bei aktuellen Serverinstallationen braucht man hier meist nicht
- eingreifen
+ kivitendo setzt zwingend voraus, dass die Datenbank Unicode/UTF-8 als Encoding einsetzt. Bei aktuellen Serverinstallationen
+ braucht man hier meist nicht einzugreifen.
- Dieses kann überprüft werden: ist das Encoding der Datenbank
- âtemplate1â âUTF8â, so braucht man nichts weiteres diesbezüglich
- unternehmen. Zum Testen:
+ Das Encoding des Datenbankservers kann überprüft werden. Ist das Encoding der Datenbank "template1" "Unicode" bzw. "UTF-8", so
+ braucht man nichts weiteres diesbezüglich unternehmen. Zum Testen:
su postgres
echo '\l' | psql
exit
- Andernfalls ist es notwendig, einen neuen Datenbankcluster mit
- UTF-8-Encoding anzulegen und diesen zu verwenden. Unter Debian und
+ 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
getan werden:
@@ -453,10 +451,6 @@ exit
Unter anderen Distributionen gibt es ähnliche Methoden.
- Wurde PostgreSQL nicht mit UTF-8 als Encoding initialisiert und
- ist ein Neuanlegen eines weiteren Clusters nicht möglich, so kann
- kivitendo mit ISO-8859-15 als Encoding betrieben werden.
-
Das Encoding einer Datenbank kann in psql mit
\l geprüft werden.
@@ -1243,16 +1237,6 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
Zuerst muss eine Datenbank angelegt werden. Verwenden Sie für
den Datenbankzugriff den vorhin angelegten Benutzer (in unseren
Beispielen ist dies âkivitendoâ).
-
- Wenn Sie für die kivitendo-Installation nicht Unicode (UTF-8) sondern den europäischen Schriftsatz ISO-8859-15 benutzen
- wollen, so müssen Sie vor dem Anlegen der Datenbank in der Datei config/kivitendo.conf die Variable
- dbcharset im Abschnitt system auf den Wert âISO-8859-15â setzen.
-
- Bitte beachten Sie, dass alle Datenbanken den selben Zeichensatz
- verwenden müssen, da diese Einstellungen momentan global in kivitendo
- vorgenommen wird und nicht nach Datenbank unterschieden werden kann.
- Auch die Authentifizierungsdatenbank muss mit diesem Zeichensatz
- angelegt worden sein.
@@ -1681,13 +1665,6 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
print_templates auf â1â stehen.
Dieses ist die Standardeinstellung.
- Weiterhin muss in der Datei
- config/kivitendo.conf die Variable
- dbcharset im Abschnitt system auf
- die Zeichenkodierung gesetzt werden, die auch bei der Speicherung der
- Daten in der Datenbank verwendet wird. Diese ist in den meisten Fällen
- "UTF-8".
-
Während die Erzeugung von reinen OpenDocument-Dateien keinerlei
weitere Software benötigt, wird zur Umwandlung dieser Dateien in PDF
OpenOffice.org benötigt. Soll dieses Feature genutzt werden, so muss
@@ -5474,21 +5451,6 @@ file = /tmp/kivitendo-debug.log
Mit FastCGI ist die neuste Version auf 0,26 Sekunden selbst in
den kritischen Pfaden, unter 0,15 sonst.
-
-
- Bekannte Probleme
-
-
- Encoding Awareness
-
- UTF-8 kodierte Installationen sind sehr anfällig gegen
- fehlerhfate Encodings unter FCGI. latin9 Installationen behandeln
- falsch kodierte Zeichen eher unwissend, und geben sie einfach
- weiter. UTF-8 verweigert bei fehlerhaften Programmpfaden kurzerhand
- das Ausliefern. Es wird noch daran gearbeitet, alle Fehler da zu
- beseitigen.
-
-
@@ -5498,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.
+
+ Character set
+
+ All files included in a language pack must use UTF-8 as their encoding.
+
+
File structure
@@ -5817,27 +5774,6 @@ sub run {
-
- charset
-
-
- This file should be present.
-
- The charset file describes which
- charset a language package is written in and applies to all
- other language files in the package. It is possible to write
- some language packages without an explicit charset, but it is
- still strongly recommended. You'll never know in what
- environment your language package will be used, and neither
- UTF-8 nor Latin1 are guaranteed.
-
- The whole content of this file is a string that can be
- recognized as a valid charset encoding. Example:
-
- UTF-8
-
-
-
all
@@ -6008,6 +5944,10 @@ filenames
Perl-Distribution und kann für frühere Versionen aus dem CPAN bezogen
werden.
+
+ 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.
@@ -6016,14 +5956,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