X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Fdokumentation.xml;h=0a61691068478450318eafb26cd0455da19231ae;hb=642c04d614c96555add111e983ef7a756a6362a1;hp=f0b0485166267baddfeb410905f329d005851b40;hpb=42dfa9a7030e7d06288385076e348d34ec809128;p=kivitendo-erp.git
diff --git a/doc/dokumentation.xml b/doc/dokumentation.xml
index f0b048516..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
@@ -140,6 +140,8 @@
FCGI (nicht Versionen 0.68 bis 0.71 inklusive; siehe )
+ File::Copy::Recursive
+
JSONList::MoreUtils
@@ -158,7 +160,7 @@
Rose::DB
- Rose::DB::Object
+ Rose::DB::Object Version 0.788 oder neuerTemplate
@@ -173,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.
@@ -211,7 +215,7 @@
librose-db-perl librose-object-perl libsort-naturally-perl \
libstring-shellquote-perl libtemplate-perl libtext-csv-xs-perl \
libtext-iconv-perl liburi-perl libxml-writer-perl libyaml-perl \
- postgresql
+ libfile-copy-recursive-perl postgresql
@@ -221,7 +225,7 @@
yum install httpd perl-Archive-Zip perl-Clone perl-DBD-Pg \
perl-DBI perl-DateTime perl-Email-Address perl-Email-MIME perl-FCGI \
- perl-JSON perl-List-MoreUtils perl-Net-SMTP-SSL perl-Net-SSLGlue \
+ perl-File-Copy-Recursive perl-JSON perl-List-MoreUtils perl-Net-SMTP-SSL perl-Net-SSLGlue \
perl-PDF-API2 perl-Params-Validate perl-Rose-DB perl-Rose-DB-Object \
perl-Rose-Object perl-Sort-Naturally perl-String-ShellQuote \
perl-Template-Toolkit perl-Text-CSV_XS perl-Text-Iconv perl-URI \
@@ -242,7 +246,7 @@ cpan Config::Stdzypper install apache2 perl-Archive-Zip perl-Clone \
perl-Config-Std perl-DBD-Pg perl-DBI perl-DateTime perl-Email-Address \
- perl-Email-MIME perl-FastCGI perl-JSON perl-List-MoreUtils \
+ perl-Email-MIME perl-FastCGI perl-File-Copy-Recursive perl-JSON perl-List-MoreUtils \
perl-Net-SMTP-SSL perl-Net-SSLGlue perl-PDF-API2 perl-Params-Validate \
perl-Sort-Naturally perl-Template-Toolkit perl-Text-CSV_XS perl-Text-Iconv \
perl-URI perl-XML-Writer perl-YAML postgresql-server
@@ -379,22 +383,20 @@ 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
angeben, der nach Erstellung der Rechnungen eine entsprechende E-Mail
mit Informationen über die erstellten Rechnungen bekommt.
- Nutzt man den Taskserver für wiederkehrende Rechnungen,
- muss unter [task_server] ein Login eines Benutzers
- angegeben werden, mit dem sich der Taskserver an kivitendo bei der
- Datenbank anmeldet, die dem Benutzer zugewiesen ist.
+ kivitendo bringt eine eigene Komponente zur zeitgesteuerten Ausführung bestimmter Aufgaben mit, den Taskserver. Er wird u.a. für Features wie die wiederkehrenden Rechnungen benötigt, erledigt aber auch andere erforderliche Aufgaben
+ und muss daher in Betrieb genommen werden. Der Taskserver benötigt zwei Konfigurationseinstellungen, die unter
+ [task_server] anzugeben sind: ein Mandant (entweder der Mandantenname oder eine Datenbank-ID, Variable
+ client), aus dem die Datenbankkonfiguration entnommen wird, sowie ein Login (Variable login)
+ eines Benutzers, der für gewisse Dinge wie die Rechnungserstellung als Verkäufer eingetragen wird.Für Entwickler finden sich unter [debug]
wichtige Funktionen, um die Fehlersuche zu erleichtern.
@@ -425,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:
@@ -450,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.
@@ -676,7 +673,7 @@ Alias /url/for/kivitendo-erp/ /path/to/kivitendo-erp/
Deny from All
</DirectoryMatch>
- Seit mod_fcgid-Version 2.6.3 gelten sehr kleine Grenzen für
+ Seit mod_fcgid-Version 2.3.6 gelten sehr kleine Grenzen für
die maximale GröÃe eines Requests. Diese sollte wie folgt
hochgesetzt werden:
@@ -728,12 +725,9 @@ Alias /url/for/kivitendo-erp-fcgid/ /path/to/kivitendo-erp/
Der Task-Server
- Der Task-Server ist ein Prozess, der im Hintergrund läuft, in
- regelmäÃigen Abständen nach abzuarbeitenden Aufgaben sucht und diese zu
- festgelegten Zeitpunkten abarbeitet (ähnlich wie Cron). Dieser Prozess
- wird bisher nur für die Erzeugung der wiederkehrenden Rechnungen
- benutzt, wird aber in Zukunft deutlich mehr Aufgaben übertragen
- bekommen.
+ Der Task-Server ist ein Prozess, der im Hintergrund läuft, in regelmäÃigen Abständen nach abzuarbeitenden Aufgaben sucht und
+ diese zu festgelegten Zeitpunkten abarbeitet (ähnlich wie Cron). Dieser Prozess wird u.a. für die Erzeugung der wiederkehrenden
+ Rechnungen und weitere essenzielle Aufgaben benutzt.Verfügbare und notwendige Konfigurationsoptionen
@@ -744,14 +738,25 @@ Alias /url/for/kivitendo-erp-fcgid/ /path/to/kivitendo-erp/
+
+ client
+
+
+ Name oder Datenbank-ID eines vorhandenen kivitendo-Mandanten, der benutzt wird, um die zu verwendende
+ Datenbankverbindung auszulesen. Der Mandant muss in der Administration angelegt werden. Diese Option muss angegeben
+ werden.
+
+ Diese Option kam mit Release v3.x.0 hinzu und muss daher in Konfigurationen, die von älteren Versionen aktualisiert
+ wurden, ergänzt werden.
+
+
+
login
- gültiger kivitendo-Benutzername, der benutzt wird, um die
- zu verwendende Datenbankverbindung auszulesen. Der Benutzer muss
- in der Administration angelegt werden. Diese Option muss
- angegeben werden.
+ gültiger kivitendo-Benutzername, der z.B. als Verkäufer beim Erzeugen wiederkehrender Rechnungen benötigt wird. Der
+ Benutzer muss in der Administration angelegt werden. Diese Option muss angegeben werden.
@@ -902,13 +907,11 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
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.
+ Beim Task-Server werden der zu verwendende Mandant und Login-Name des Benutzers, unter dem der Task-Server laufen soll, in die
+ Konfigurationsdatei geschrieben. Hat man mehrere Mandanten, muss 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.
+ Die Konfigurationsdatei ist eine Kopie der Datei kivitendo.conf, wo in der Kategorie [task_server] die
+ gewünschten Werte für client und login eingetragen werden.Der alternative Task-Server wird dann mit folgendem Befehl
gestartet:
@@ -1141,19 +1144,18 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
der folgenden URL erreichbar sein sollte:http://localhost/kivitendo-erp/admin.pl
+ url="http://localhost/kivitendo-erp/controller.pl?action=Admin/login">http://localhost/kivitendo-erp/controller.pl?action=Admin/login
- Benutzer- und Gruppenverwaltung
+ Mandanten-, Benutzer- und Gruppenverwaltung
- Nach der Installation müssen Benutzer, Gruppen und Datenbanken
- angelegt werden. Dieses geschieht im Administrationsmenü, das Sie unter
- folgender URL finden:
+ Nach der Installation müssen Mandanten, Benutzer, Gruppen und Datenbanken angelegt werden. Dieses geschieht im
+ Administrationsmenü, das Sie unter folgender URL finden:http://localhost/kivitendo-erp/admin.pl
+ url="http://localhost/kivitendo-erp/controller.pl?action=Admin/login">http://localhost/kivitendo-erp/controller.pl?action=Admin/login
Verwenden Sie zur Anmeldung das Password, dass Sie in der Datei
config/kivitendo.conf eingetragen haben.
@@ -1161,6 +1163,23 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
Zusammenhänge
+ kivitendo verwaltet zwei Sets von Daten, die je nach Einrichtung in einer oder zwei Datenbanken gespeichert werden.
+
+ Das erste Set besteht aus Anmeldeinformationen: welche Benutzer und Mandanten gibt es, welche Gruppen, welche BenutzerIn hat
+ Zugriff auf welche Mandanten, und welche Gruppe verfügt über welche Rechte. Diese Informationen werden in der
+ Authentifizierungsdatenbank gespeichert. Dies ist diejenige Datenbank, deren Verbindungsparameter in der Konfigurationsdatei
+ config/kivitendo.conf gespeichert werden.
+
+ Das zweite Set besteht aus den eigentlichen Verkehrsdaten eines Mandanten: Stammdaten (Kunden, Lieferanten, Waren), Belege
+ (Angebote, Liferscheine, Rechnungen), Einstellungen. Diese werden in einer Mandantendatenbank gespeichert. Die
+ Verbindungsinformationen einer solchen Mandantendatenbank werden im Administrationsbereich konfiguriert, indem man einen Mandanten
+ anlegt und dort die Parameter einträgt. Dabei hat jeder Mandant eine eigene Datenbank.
+
+ Aufgrund des Datenbankdesigns ist es für einfache Fälle möglich, die Authentifizierungsdatenbank und eine der
+ Mandantendatenbanken in ein und derselben Datenbank zu speichern. Arbeitet man hingegen mit mehr als einem Mandanten, wird
+ empfohlen, für die Authentifizierungsdatenbank eine eigene Datenbank zu verwenden, die nicht gleichzeitig für einen Mandanten
+ verwendet wird.
+
kivitendo verwendet eine Datenbank zum Speichern all seiner
Informationen wie Kundendaten, Artikel, Angebote, Rechnungen etc. Um
mit kivitendo arbeiten zu können, muss eine Person einen
@@ -1169,30 +1188,29 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
möglich und normal, dass mehreren Benutzern die selbe Datenbank
zugewiesen wird, sodass sie alle mit den selben Daten arbeiten
können.
+
+
+
+ Mandanten, Benutzer und Gruppen
+
+ kivitendos Administration kennt Mandanten, Benutzer und Gruppen, die sich frei zueinander zuordnen lassen.
+
+ kivitendo kann mehrere Mandaten aus einer Installation heraus verwalten. Welcher Mandant benutzt wird, kann direkt beim Login
+ ausgewählt werden. Für jeden Mandanten wird ein eindeutiger Name vergeben, der beim Login angezeigt wird. Weiterhin benötigt der
+ Mandant Datenbankverbindungsparameter für seine Mandantendatenbank. Diese sollte über die Datenbankverwaltung geschehen.
+
+ Ein Benutzer ist eine Person, die Zugriff auf kivitendo erhalten soll. Sie erhält einen Loginnamen sowie ein
+ Passwort. Weiterhin legt der Administrator fest, an welchen Mandanten sich ein Benutzer anmelden kann, was beim Login verifiziert
+ wird.
+
+ Gruppen dienen dazu, Benutzern innerhalb eines Mandanten Zugriff auf bestimmte Funktionen zu geben. Einer Gruppe werden dafür
+ vom Administrator gewisse Rechte zugeordnet. Weiterhin legt der Administrator fest, für welche Mandanten eine Gruppe gilt, und
+ welche Benutzer Mitglieder in dieser Gruppe sind. Meldet sich ein Benutzer dann an einem Mandanten an, so erhält er alle Rechte von
+ allen denjenigen Gruppen, die zum Einen dem Mandanten zugeordnet sind und in denen der Benutzer zum Anderen Mitglied ist,
- Die Basisdaten der Benutzer, die in der Administration
- eingegeben werden können, werden in einer zweiten Datenbank
- gespeichert, der bereits erwähnten Authentifizierungsdatenbank. Diese
- ist also den Produktivdaten enthaltenden Datenbanken vorgeschaltet.
- Pro kivitendo-Installation gibt es nur eine
- Authentifizierungsdatenbank, aber beliebig viele Datenbanken mit
- Firmendaten.
-
- kivitendo kann seinen Benutzern Zugriff auf bestimmte
- Funktionsbereiche erlauben oder verbieten. Wird der Zugriff nicht
- gestattet, so werden der entsprechenden Menüpunkte auch nicht
- angezeigt. Diese Rechte werden ebenfalls in der
- Authentifizierungsdatenbank gespeichert.
-
- Um Rechte verteilen zu können, verwendet kivitendo ein
- Gruppen-Prinzip. Einer Gruppe kann der Zugriff auf bestimmte Bereiche
- erlaubt werden. Ein Benutzer wiederum kann Mitglied in einer oder
- mehrerer Gruppen sein. Der Benutzer hat Zugriff auf alle diejenigen
- Funktionen, die mindestens einer Gruppe erlaubt sind, in der der
- Benutzer Mitglied ist.
-
- Die allgemeine Reihenfolge, in der Datenbanken, Gruppen und
- Benutzer angelegt werden sollten, lautet:
+ Die Reihenfolge, in der Datenbanken, Mandanten, Gruppen und Benutzer angelegt werden, kann im Prinzip beliebig gewählt
+ werden. Die folgende Reihenfolge beinhaltet die wenigsten Arbeitsschritte:
@@ -1204,11 +1222,11 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
- Benutzer anlegen
+ Benutzer anlegen und Gruppen als Mitglied zuordnen
- Benutzer den Gruppen zuordnen
+ Mandanten anlegen und Gruppen sowie Benutzer zuweisen
@@ -1219,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.
@@ -1239,72 +1247,45 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
Anlegen können Sie die verschiedenen Bereiche wählen, auf die
Mitglieder dieser Gruppe Zugriff haben sollen.
- Benutzergruppen sind unabhängig von Datenbanken, da sie in der
- Authentifizierungsdatenbank gespeichert werden. Sie gelten für alle
- Datenbanken, die in dieser Installation verwaltet werden.
+ Benutzergruppen werden zwar in der Authentifizierungsdatenbank gespeichert, gelten aber nicht automatisch für alle
+ Mandanten. Der Administrator legt vielmehr fest, für welche Mandanten eine Gruppe gültig ist. Dies kann entweder beim Bearbeiten der
+ Gruppe geschehen ("diese Gruppe ist gültig für Mandanten X, Y und Z"), oder aber wenn man einen Mandanten bearbeitet ("für diesen
+ Mandanten sind die Gruppen A, B und C gültig").
+
+ Wurden bereits Benutzer angelegt, so können hier die Mitglieder dieser Gruppe festgelegt werden ("in dieser Gruppe sind die
+ Benutzer X, Y und Z Mitglieder"). Dies kann auch nachträglich beim Bearbeiten eines Benutzers geschehen ("dieser Benutzer ist
+ Mitglied in den Gruppen A, B und C").Benutzer anlegen
- Beim Anlegen von Benutzern werden für viele Parameter
- Standardeinstellungen vorgenommen, die den Gepflogenheiten des
- deutschen Raumes entsprechen.
+ Beim Anlegen von Benutzern werden für viele Parameter Standardeinstellungen vorgenommen, die den Gepflogenheiten des deutschen
+ Raumes entsprechen.
- Zwingend anzugeben sind der Loginname sowie die komplette
- Datenbankkonfiguration. Wenn die Passwortauthentifizierung über die
- Datenbank eingestellt ist, so kann hier auch das Benutzerpasswort
- gesetzt bzw. geändert werden. Ist hingegen die LDAP-Authentifizierung
- aktiv, so ist das Passwort-Feld deaktiviert.
+ Zwingend anzugeben ist der Loginname. Wenn die Passwortauthentifizierung über die Datenbank eingestellt ist, so kann hier auch
+ das Benutzerpasswort gesetzt bzw. geändert werden. Ist hingegen die LDAP-Authentifizierung aktiv, so ist das Passwort-Feld
+ deaktiviert.
- In der Datenbankkonfiguration müssen die Zugriffsdaten einer der
- eben angelegten Datenbanken eingetragen werden.
+ Hat man bereits Mandanten und Gruppen angelegt, so kann hier auch konfiguriert werden, auf welche Mandanten der Benutzer
+ Zugriff hat bzw. in welchen Gruppen er Mitglied ist. Beide Zuweisungen können sowohl beim Benutzer vorgenommen werden ("dieser
+ Benutzer hat Zugriff auf Mandanten X, Y, Z" bzw. "dieser Benutzer ist Mitglied in Gruppen X, Y und Z") als auch beim Mandanten ("auf
+ diesen Mandanten haben Benutzer A, B und C Zugriff") bzw. bei der Gruppe ("in dieser Gruppe sind Benutzer A, B und C
+ Mitglieder").
-
- Gruppenmitgliedschaften verwalten
+
+ Mandanten anlegen
- Nach dem Anlegen von Benutzern und Gruppen müssen Benutzer den
- Gruppen zugewiesen werden. Dazu gibt es zwei Möglichkeiten:
-
-
-
- In der Gruppenverwaltung wählt man eine Gruppe aus. Im
- folgenden Dialog kann man dann einzeln die Benutzer der Gruppe
- hinzufügen.
-
-
-
- In der Gruppenverwaltung wählt man das Tool zur Verwaltung
- der Gruppenmitgliedschaft. Hier wird eine Matrix angezeigt, die
- alle im System angelegten Gruppen und Benutzer enthält. Durch
- Setzen der Häkchen wird der Benutzer in der ausgewählten Zeile der
- Gruppe in der ausgewählten Spalte hinzugefügt.
-
-
-
+ Ein Mandant besteht aus Administrationssicht primär aus einem eindeutigen Namen. Weiterhin wird hier hinterlegt, welche
+ Datenbank als Mandantendatenbank benutzt wird. Hier müssen die Zugriffsdaten einer der eben angelegten Datenbanken eingetragen
+ werden.
-
- Migration alter Installationen
-
- Wenn kivitendo 2.6.3 über eine ältere Version installiert wird,
- in der die Benutzerdaten noch im Dateisystem im Verzeichnis
- users verwaltet wurden, so bietet kivitendo die
- Möglichkeit, diese Benutzerdaten automatisch in die
- Authentifizierungsdatenbank zu übernehmen. Dies geschieht, wenn man
- sich nach dem Update der Installation das erste Mal im
- Administrationsbereich anmeldet. Findet kivitendo die Datei
- users/members, so wird der Migrationsprozess
- gestartet.
-
- Der Migrationsprozess ist nahezu vollautomatisch. Alle
- Benutzerdaten können übernommen werden. Nach den Benutzerdaten bietet
- kivitendo noch die Möglichkeit an, dass automatisch eine
- Benutzergruppe angelegt wird. Dieser Gruppe wird Zugriff auf alle
- Funktionen von kivitendo gewährt. Alle migrierten Benutzern werden
- Mitglied in dieser Gruppe. Damit wird das Verhalten von kivitendo bis
- Version 2.4.3 inklusive wiederhergestellt, und die Benutzer können
- sich sofort wieder anmelden und mit dem System arbeiten.
+ Hat man bereits Benutzer und Gruppen angelegt, so kann hier auch konfiguriert werden, welche Benutzer Zugriff auf den
+ Mandanten haben bzw. welche Gruppen für den Mandanten gültig sind. Beide Zuweisungen können sowohl beim Mandanten vorgenommen werden
+ ("auf diesen Mandanten haben Benutzer X, Y und Z Zugriff" bzw. "für diesen Mandanten sind die Gruppen X, Y und Z gültig") als auch
+ beim Benutzer ("dieser Benutzer hat Zugriff auf Mandanten A, B und C") bzw. bei der Gruppe ("diese Gruppe ist für Mandanten A, B und
+ C gültig").
@@ -1684,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
@@ -2041,7 +2015,7 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
Die Administrationsseite erreichen Sie unter:http://localhost/kivitendo-erp/admin.pl
+ url="http://localhost/kivitendo-erp/controller.pl?action=Admin/login">http://localhost/kivitendo-erp/controller.pl?action=Admin/login
@@ -2764,6 +2738,22 @@ ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
+
+ c_vendor_id
+
+
+ Lieferantennummer beim Kunden (nur Kunden)
+
+
+
+
+ v_customer_id
+
+
+ Kundennummer beim Lieferanten (nur Lieferanten)
+
+
+
cp_email
@@ -5086,7 +5076,7 @@ Beschreibung: <%description%>
überwiegend die Daten, die sich unter Programm
-> Einstellungen befinden, bzw. die
Informationen über den Benutzer die über die
- Administrator-Schnittstelle (admin.pl) eingegeben wurden.
+ Administrator-Schnittstelle eingegeben wurden.
@@ -5175,6 +5165,10 @@ $main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{
vom aktuellen User abhängen wird das Objekt aus
Geschwindigkeitsgründen nur einmal angelegt und dann nach jedem
Request kurz resettet.
+
+ Dieses Objekt kapselt auch den gerade aktiven Mandanten. Dessen Einstellungen können über
+ $::auth->client abgefragt werden; Rückgabewert ist ein Hash mit den Werten aus der Tabelle
+ auth.clients.
@@ -5457,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.
-
-
@@ -5481,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.charset
- Empfohlen. Gibt den Zeichensatz an, in dem das Script
- geschrieben wurde, z.B. "UTF-8". Aus
- Kompatibilitätsgründen mit alten Upgrade-Scripten wird bei
- Abwesenheit des Tags der Zeichensatz
- "ISO-8859-15" angenommen.
+ Empfohlen. Gibt den Zeichensatz an, in dem das Script geschrieben wurde, z.B. "UTF-8". Aus
+ Kompatibilitätsgründen mit alten Upgrade-Scripten wird bei Abwesenheit des Tags für SQL-Upgradedateien der Zeichensatz
+ "ISO-8859-15" angenommen. Perl-Upgradescripte hingegen müssen immer in UTF-8 encodiert sein und sollten
+ demnach auch ein "use utf8;" enthalten.
@@ -5624,6 +5590,48 @@ file = /tmp/kivitendo-debug.log
+
+ Format von in Perl geschriebenen Datenbankupgradescripten
+
+ In Perl geschriebene Datenbankscripte werden nicht einfach so ausgeführt sondern müssen sich an gewisse Konventionen
+ halten. Dafür bekommen sie aber auch einige Komfortfunktionen bereitgestellt.
+
+ Ein Upgradescript stellt dabei eine vollständige Objektklasse dar, die vom Elternobjekt
+ "SL::DBUpgrade2::Base" erben und eine Funktion namens "run" zur Verfügung stellen muss. Das
+ Script wird ausgeführt, indem eine Instanz dieser Klasse erzeugt und darauf die erwähnte "run" aufgerufen
+ wird.
+
+ Zu beachten ist, dass sich der Paketname der Datei aus dem Wert für "@tag" ableitet. Dabei werden alle
+ Zeichen, die in Paketnamen ungültig wären (gerade Bindestriche), durch Unterstriche ersetzt. Insgesamt sieht der Paketname wie folgt
+ aus: "SL::DBUpgrade2::tag".
+
+ Welche Komfortfunktionen zur Verfügung stehen, erfahren Sie in der Perl-Dokumentation zum oben genannten Modul; aufzurufen mit
+ "perldoc SL/DBUpgrade2/Base.pm".
+
+ Ein Mindestgerüst eines gültigen Perl-Upgradescriptes sieht wie folgt aus:
+
+ # @tag: beispiel-upgrade-file42
+# @description: Ein schönes Beispielscript
+# @depends: release_3_0_0
+package SL::DBUpgrade2::beispiel_upgrade_file42;
+
+use strict;
+use utf8;
+
+use parent qw(SL::DBUpgrade2::Base);
+
+sub run {
+ my ($self) = @_;
+
+ # hier Aktionen ausführen
+
+ return 1;
+}
+
+1;
+
+
+
Hilfsscript dbupgrade2_tool.pl
@@ -5723,6 +5731,13 @@ file = /tmp/kivitendo-debug.log
point.
+
+ Character set
+
+ All files included in a language pack must use UTF-8 as their encoding.
+
+
File structure
@@ -5759,27 +5774,6 @@ file = /tmp/kivitendo-debug.log
-
- 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
@@ -5950,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.
@@ -5958,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