3.7. Artikelklassifizierung

3.7.1. Ãbersicht

Die Klassifizierung von Artikeln dient einer weiteren + 3.7. Artikelklassifizierung

3.7. Artikelklassifizierung
ZurÃ¼ck	Kapitel 3. Features und Funktionen	Weiter

3.7. Artikelklassifizierung

3.7.1. Ãbersicht

Die Klassifizierung von Artikeln dient einer weiteren Gliederung, um zum Beispiel den Einkauf vom Verkauf zu trennen, gekennzeichnet durch eine Beschreibung (z.B. "Einkauf") und ein KÃ¼rzel (z.B. "E"). FÃ¼r jede Klassifizierung besteht eine Beschreibung und eine AbkÃ¼rzung die normalerweise aus einem Zeichen besteht, kann aber auf mehrere Zeichen erweitert werden, falls zur Unterscheidung - notwendig. Sinnvoll sind jedoch nur maximal 2 Zeichen.

3.7.2. Basisklassifizierung

Als Basisklassifizierungen gibt es

Einkauf
Verkauf
Handelsware
Produktion
- keine - (diese wird bei einer Aktualisierung fÃ¼r alle + notwendig. Sinnvoll sind jedoch nur maximal 2 Zeichen.

3.7.2. Basisklassifizierung

Als Basisklassifizierungen gibt es

Einkauf
Verkauf
Handelsware
Produktion
- keine - (diese wird bei einer Aktualisierung fÃ¼r alle existierenden Artikel verwendet und ist gÃ¼ltig fÃ¼r Verkauf und Einkauf)

Es kÃ¶nnen weitere Klassifizierungen angelegt werden. So kann es - z.B. fÃ¼r separat auszuweisende Artikel folgende Klassen geben:

Lieferung (Logistik, Transport) mit KÃ¼rzel L
Material (Verpackungsmaterial) mit KÃ¼rzel M

3.7.3. Attribute

Bisher haben die Klassifizierungen folgende Attribute, die auch + z.B. fÃ¼r separat auszuweisende Artikel folgende Klassen geben:

Lieferung (Logistik, Transport) mit KÃ¼rzel L
Material (Verpackungsmaterial) mit KÃ¼rzel M

3.7.3. Attribute

Bisher haben die Klassifizierungen folgende Attribute, die auch alle gleichzeitg gÃ¼ltig sein kÃ¶nnen

gÃ¼ltig fÃ¼r Verkauf - dieser Artikel kann im Verkauf genutzt werden
gÃ¼ltig fÃ¼r Einkauf - dieser Artikel kann im Einkauf genutzt werden
separat ausweisen - hierzu gibt es zur Dokumentengenerierung @@ -19,7 +19,7 @@ pro separat auszuweisenden Klassifizierungen die Variable< %separate_X_subtotal%>, wobei X das KÃ¼rzel der Klassifizierung ist.
Im obigen Beispiel wÃ¤re das fÃ¼r Lieferkosten <%separate_L_subtotal%> und fÃ¼r Verpackungsmaterial - <%separate_M_subtotal%>.

3.7.4. Zwei-Zeichen AbkÃ¼rzung

Der Typ des Artikels und die Klassifizierung werden durch zwei + <%separate_M_subtotal%>.

3.7.4. Zwei-Zeichen AbkÃ¼rzung

Der Typ des Artikels und die Klassifizierung werden durch zwei Buchstaben dargestellt. Der erste Buchstabe ist eine Lokalisierung des Artikel-Typs ('P','A','S'), deutsch 'W', 'E', und 'D' fÃ¼r Ware Erzeugnis oder Dienstleistung und ggf. weiterer Typen.

Der zweite Buchstabe (und ggf. auch ein dritter, falls nÃ¶tig) diff --git a/doc/html/ch03s08.html b/doc/html/ch03s08.html index 2407ec7e4..67f2781d5 100644 --- a/doc/html/ch03s08.html +++ b/doc/html/ch03s08.html @@ -1,10 +1,10 @@ - 3.8. Dateiverwaltung (Mini-DMS)

3.8. Dateiverwaltung (Mini-DMS)
ZurÃ¼ck	Kapitel 3. Features und Funktionen	Weiter

3.8. Dateiverwaltung (Mini-DMS)

3.8.1. Ãbersicht

Parallel zum alten WebDAV gibt es ein Datei-Management-System, + 3.8. Dateiverwaltung (Mini-DMS)

3.8. Dateiverwaltung (Mini-DMS)
ZurÃ¼ck	Kapitel 3. Features und Funktionen	Weiter

3.8. Dateiverwaltung (Mini-DMS)

3.8.1. Ãbersicht

Parallel zum alten WebDAV gibt es ein Datei-Management-System, das Dateien verschiedenen Typs verwaltet. Dies kÃ¶nnen

aus ERP-Daten per LaTeX Template erzeugte PDF-Dokumente,
zu bestimmten ERP-Daten gehÃ¶rende Anhangdateien unterschiedlichen Formats,
per Scanner eingelesene PDF-Dateien,
per E-Mail empfangene DateianhÃ¤nge unterschiedlichen - Formats,
sowie speziel fÃ¼r Artikel hochgeladene Bilder sein.

3.8.2. Struktur

Ãber eine vom Speichermedium unabhÃ¤ngige Zwischenschicht werden + Formats,

sowie speziel fÃ¼r Artikel hochgeladene Bilder sein.

3.8.2. Struktur

Ãber eine vom Speichermedium unabhÃ¤ngige Zwischenschicht werden die Dateien und ihre Versionen in der Datenbank verwaltet. Darunter kÃ¶nnen verschiedene Implementierungen (Backends) gleichzeitig existieren:

Dateisystem
WebDAV
Schnittstelle zu externen @@ -23,7 +23,7 @@ fÃ¼r "attachment" und "image" nur die Quelle "uploaded". FÃ¼r "document" gibt es auf jeden Fall die Quelle "created". Die Quellen "scanner" und "email" mÃ¼ssen derzeit in der Datenbank konfiguriert werden (siehe - Datenbank-Konfigurierung).

3.8.3. Anwendung

Die Daten werden bei den ERP-Objekten als extra Reiter + Datenbank-Konfigurierung).

3.8.3. Anwendung

Die Daten werden bei den ERP-Objekten als extra Reiter dargestellt. Eine Verkaufsrechnung z.B. hat die Reiter "Dokumente" und "DateianhÃ¤nge".

Bei den DateianhÃ¤ngen wird immer nur die aktuelle Version einer Datei angezeigt. Wird eine Datei mit gleichem Namen hochgeladen, so @@ -39,13 +39,13 @@ so sind diese z.B. bei Einkaufsrechnungen sichtbar:

Statt des LÃ¶schens wird hier die Datei zurÃ¼ck zur Quelle verschoben. Somit kann die Datei anschlieÃend an ein anderes ERP-Objekt angehÃ¤ngt werden.

Derzeit sind "Titel" und "Beschreibung" noch nicht genutzt. Sie - sind bisher nur bei Bildern relevant.

3.8.4. Konfigurierung

3.8.4.1. Mandantenkonfiguration

3.8.4.1.1. Reiter "Features"

Unter dem Reiter Features + sind bisher nur bei Bildern relevant.

3.8.4. Konfigurierung

3.8.4.1. Mandantenkonfiguration

3.8.4.1.1. Reiter "Features"

Unter dem Reiter Features im Abschnitt Dateimanagement ist neben dem "alten" WebDAV das Dateimangement generell zu- und abschaltbar, sowie die Zuordnung der Dateitypen zu Backends. Die LÃ¶schbarkeit von Dateien, sowie die maximale UploadgrÃ¶Ãe sind Backend-unabhÃ¤ngig

Die einzelnen Backends sind einzeln einschaltbar. Spezifische Backend-Konfigurierungen sind hier noch - ergÃ¤nzbar.

3.8.4.1.2. Reiter "Allgemeine DokumentenanhÃ¤nge"

Unter dem Reiter Allgemeine + ergÃ¤nzbar.

3.8.4.1.2. Reiter "Allgemeine DokumentenanhÃ¤nge"

Unter dem Reiter Allgemeine DokumentenanhÃ¤nge kann fÃ¼r alle ERP-Dokumente ( Angebote, AuftrÃ¤ge, Lieferscheine, Rechnungen im Verkauf und Einkauf ) allgemeingÃ¼ltige AnhÃ¤nge hochgeladen werden.

Diese AnhÃ¤nge werden beim Generieren von PDF-Dateien an die diff --git a/doc/html/ch03s09.html b/doc/html/ch03s09.html index 141fff9ff..6aeaf0346 100644 --- a/doc/html/ch03s09.html +++ b/doc/html/ch03s09.html @@ -1,13 +1,13 @@ - 3.9. Webshop-Api

3.9. Webshop-Api
ZurÃ¼ck	Kapitel 3. Features und Funktionen	Weiter

3.9. Webshop-Api

Das Shopmodul bietet die MÃ¶glichkeit Onlineshopartikel und + 3.9. Webshop-Api

3.9. Webshop-Api
ZurÃ¼ck	Kapitel 3. Features und Funktionen	Weiter

3.9. Webshop-Api

Das Shopmodul bietet die MÃ¶glichkeit Onlineshopartikel und Onlineshopbestellungen zu verwalten und zu bearbeiten.

Es ist MultishopfÃ¤hig, d.h. Artikel kÃ¶nnen mehreren oder unterschiedlichen Shops zugeordnet werden. Bestellungen kÃ¶nnen aus mehreren Shops geholt werden.

Zur Zeit bietet das Modul nur einen Connector zur REST-Api von Shopware. Weitere Connectoren kÃ¶nnen dazu programmiert und eingerichtet - werden.

3.9.1. Rechte fÃ¼r die Webshopapi

In der Administration kÃ¶nnen folgende Rechte vergeben - werden

Webshopartikel anlegen und bearbeiten
Shopbestellungen holen und bearbeiten
Shop anlegen und bearbeiten

3.9.2. Konfiguration

Unter System->Webshops kÃ¶nnen Shops angelegt und konfiguriert - werden

3.9.3. Webshopartikel

3.9.3.1. Shopvariablenreiter in Artikelstammdaten

Mit dem Recht "Shopartikel anlegen und bearbeiten" und des + werden.

3.9.1. Rechte fÃ¼r die Webshopapi

In der Administration kÃ¶nnen folgende Rechte vergeben + werden

Webshopartikel anlegen und bearbeiten
Shopbestellungen holen und bearbeiten
Shop anlegen und bearbeiten

3.9.2. Konfiguration

Unter System->Webshops kÃ¶nnen Shops angelegt und konfiguriert + werden

3.9.3. Webshopartikel

3.9.3.1. Shopvariablenreiter in Artikelstammdaten

Mit dem Recht "Shopartikel anlegen und bearbeiten" und des Markers "Shopartikel" in den Basisdaten zeigt sich der Reiter "Shopvariablen" in den Artikelstammdaten. Hier kÃ¶nnen jetzt die Artikel mit @@ -16,11 +16,11 @@ Stelle kÃ¶nnen auch beliebig viele Bilder dem Shopartikel zugeordnet werden. Artikelbilder gelten fÃ¼r alle Shops.

Die Artikelgruppen werden direkt vom Shopsystem geholt somit ist es mÃ¶glich einen Artikel auch mehreren Gruppen - zuzuordenen

3.9.3.2. Shopartikelliste

Unter dem Menu Webshop->Webshop Artikel hat man nochmal + zuzuordenen

3.9.3.2. Shopartikelliste

Unter dem Menu Webshop->Webshop Artikel hat man nochmal eine GesamtÃ¼bersicht. Von hier aus ist es mÃ¶glich Artikel im Stapel unter verschiedenen Kriterien <alles><nur Preis><nur Bestand><Preis und Bestand> an die jeweiligen Shops - hochzuladen.

3.9.4. Bestellimport

Unter dem Menupunkt Webshop->Webshop Import Ã¶ffnet sich die + hochzuladen.

3.9.4. Bestellimport

Unter dem Menupunkt Webshop->Webshop Import Ã¶ffnet sich die Bestellimportsliste. Hier ist sind MÃ¶glichkeiten gegeben Neue Bestellungen vom Shop abzuholen, geholte Bestellungen im Stapel oder einzeln als Auftrag zu transferieren. Die Liste kann nach @@ -52,7 +52,7 @@ auch der Grund fÃ¼r die Auftragssperre sein.

Die Buttons "Auftrag erstellen" und "Kunde mit Rechnungsadresse Ã¼berschreiben" zeigen sich erst, wenn ein Kunde aus dem Listing ausgewÃ¤hlt ist.

Es ist aber mÃ¶glich die Shopbestellung zu lÃ¶schen.

Ist eine Bestellung schon Ã¼bernommen, zeigen sich an dieser - Stelle, die dazugehÃ¶rigen BelegverknÃ¼pfungen.

3.9.5. Mapping der Daten

Das Mapping der kivitendo Daten mit den Shopdaten geschieht in + Stelle, die dazugehÃ¶rigen BelegverknÃ¼pfungen.

3.9.5. Mapping der Daten

Das Mapping der kivitendo Daten mit den Shopdaten geschieht in der Datei SL/ShopConnector/<SHOPCONNECTORNAME>.pm z.B.:SL/ShopConnector/Shopware.pm

In dieser Datei gibt es einen Bereich wo die Bestellpostionen, die Bestellkopfdaten und die Artikeldaten gemapt werden. In dieser diff --git a/doc/html/ch04.html b/doc/html/ch04.html index b01e27138..35b3be885 100644 --- a/doc/html/ch04.html +++ b/doc/html/ch04.html @@ -1,6 +1,6 @@ - Kapitel 4. Entwicklerdokumentation

Kapitel 4. Entwicklerdokumentation
ZurÃ¼ck		Weiter

Kapitel 4. Entwicklerdokumentation

4.1. Globale Variablen

4.1.1. Wie sehen globale Variablen in Perl aus?

Globale Variablen liegen in einem speziellen namespace namens + Kapitel 4. Entwicklerdokumentation

Kapitel 4. Entwicklerdokumentation
ZurÃ¼ck		Weiter

Kapitel 4. Entwicklerdokumentation

4.1. Globale Variablen

4.1.1. Wie sehen globale Variablen in Perl aus?

Globale Variablen liegen in einem speziellen namespace namens "main", der von Ã¼berall erreichbar ist. DarÃ¼ber hinaus sind bareword globs global und die meisten speziellen Variablen sind... speziell.

Daraus ergeben sich folgende Formen:

@@ -25,7 +25,7 @@ $PACKAGE::form.
local $form: Alle Ãnderungen an $form werden am Ende - des scopes zurÃ¼ckgesetzt

4.1.2. Warum sind globale Variablen ein Problem?

Das erste Problem ist FCGIâ¢.

+ des scopes zurÃ¼ckgesetzt

4.1.2. Warum sind globale Variablen ein Problem?

Das erste Problem ist FCGIâ¢.

SQL-Ledgerâ¢ hat fast alles im globalen namespace abgelegt, und erwartet, dass es da auch wiederzufinden ist. Unter FCGIâ¢ mÃ¼ssen diese Sachen aber wieder @@ -39,7 +39,7 @@ dies hat, seit der EinfÃ¼hrung, u.a. schon so manche langwierige Bug-Suche verkÃ¼rzt. Da globale Variablen aber implizit mit Package angegeben werden, werden die nicht geprÃ¼ft, und somit kann sich - schnell ein Tippfehler einschleichen.

4.1.3. Kanonische globale Variablen

Um dieses Problem im Griff zu halten gibt es einige wenige + schnell ein Tippfehler einschleichen.

4.1.3. Kanonische globale Variablen

Um dieses Problem im Griff zu halten gibt es einige wenige globale Variablen, die kanonisch sind, d.h. sie haben bestimmte vorgegebenen Eigenschaften, und alles andere sollte anderweitig umhergereicht werden.

Diese Variablen sind im Moment die folgenden neun:

@@ -62,7 +62,7 @@ $::request

Damit diese nicht erneut als MÃ¼llhalde missbraucht werden, im Folgenden eine kurze ErlÃ¤uterung der bestimmten vorgegebenen - Eigenschaften (Konventionen):

4.1.3.1. $::form

Ist ein Objekt der Klasse + Eigenschaften (Konventionen):
4.1.3.1. $::form
- Ist ein Objekt der Klasse "Form"
- Wird nach jedem Request gelÃ¶scht
- Muss auch in Tests und Konsolenscripts vorhanden sein.
- EnthÃ¤lt am Anfang eines Requests die Requestparameter vom User
- Kann zwar intern Ã¼ber Requestgrenzen ein Datenbankhandle @@ -110,7 +110,7 @@ push @{ $form->{TEMPLATE_ARRAYS}{number} }, $form->{"partnumber_$i"}; push @{ $form->{TEMPLATE_ARRAYS}{description} }, $form->{"description_$i"}; # ... -}
4.1.3.2. %::myconfig
- Das einzige Hash unter den globalen Variablen
- Wird spÃ¤testens benÃ¶tigt wenn auf die Datenbank +}
4.1.3.2. %::myconfig
Das einzige Hash unter den globalen Variablen
Wird spÃ¤testens benÃ¶tigt wenn auf die Datenbank zugegriffen wird
Wird bei jedem Request neu erstellt.
EnthÃ¤lt die Userdaten des aktuellen Logins
Sollte nicht ohne Filterung irgendwo gedumpt werden oder extern serialisiert werden, weil da auch der Datenbankzugriff fÃ¼r diesen user drinsteht.
EnthÃ¤lt unter anderem Datumsformat dateformat und @@ -122,10 +122,10 @@ Ã¼berwiegend die Daten, die sich unter Programm -> Einstellungen befinden, bzw. die Informationen Ã¼ber den Benutzer die Ã¼ber die - Administrator-Schnittstelle eingegeben wurden.
4.1.3.3. $::locale
Objekt der Klasse "Locale"
Wird pro Request erstellt
Muss auch fÃ¼r Tests und Scripte immer verfÃ¼gbar + Administrator-Schnittstelle eingegeben wurden.
4.1.3.3. $::locale
Objekt der Klasse "Locale"
Wird pro Request erstellt
Muss auch fÃ¼r Tests und Scripte immer verfÃ¼gbar sein.
Cached intern Ã¼ber Requestgrenzen hinweg benutzte Locales
Lokalisierung fÃ¼r den aktuellen User. Alle Ãbersetzungen, - Zahlen- und Datumsformatierungen laufen Ã¼ber dieses Objekt.
4.1.3.4. $::lxdebug
Objekt der Klasse "LXDebug"
Wird global gecached
Muss immer verfÃ¼gbar sein, in nahezu allen + Zahlen- und Datumsformatierungen laufen Ã¼ber dieses Objekt.
4.1.3.4. $::lxdebug
Objekt der Klasse "LXDebug"
Wird global gecached
Muss immer verfÃ¼gbar sein, in nahezu allen Funktionen
$::lxdebug stellt Debuggingfunktionen bereit, wie "enter_sub" und @@ -135,7 +135,7 @@ "message" und "dump" mit denen man flott Informationen ins Log (tmp/kivitendo-debug.log) packen kann.
Beispielsweise so:
$main::lxdebug->message(0, 'Meine Konfig:' . Dumper (%::myconfig)); -$main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{vc});
4.1.3.5. $::auth
Objekt der Klasse "SL::Auth"
Wird global gecached
Hat eine permanente DB Verbindung zur Authdatenbank
Wird nach jedem Request resettet.
+$main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{vc});
4.1.3.5. $::auth
Objekt der Klasse "SL::Auth"
Wird global gecached
Hat eine permanente DB Verbindung zur Authdatenbank
Wird nach jedem Request resettet.
$::auth stellt Funktionen bereit um die Rechte des aktuellen Users abzufragen. Obwohl diese Informationen vom aktuellen User abhÃ¤ngen wird das Objekt aus @@ -144,7 +144,7 @@ $main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{ Dessen Einstellungen kÃ¶nnen Ã¼ber $::auth->client abgefragt werden; RÃ¼ckgabewert ist ein Hash mit den Werten aus der Tabelle - auth.clients.
4.1.3.6. $::lx_office_conf
Objekt der Klasse + auth.clients.
4.1.3.6. $::lx_office_conf
Objekt der Klasse "SL::LxOfficeConf"
Global gecached
ReprÃ¤sentation der config/kivitendo.conf[.default]-Dateien
Globale Konfiguration. Configdateien werden zum Start gelesen und danach nicht mehr angefasst. Es ist derzeit nicht geplant, dass @@ -154,16 +154,16 @@ $main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{ file_name = /tmp/kivitendo-debug.log
ist der Key file im Programm als $::lx_office_conf->{debug}{file} erreichbar.
Warnung
Zugriff auf die Konfiguration erfolgt im Moment Ã¼ber - Hashkeys, sind also nicht gegen Tippfehler abgesichert.
4.1.3.7. $::instance_conf
Objekt der Klasse + Hashkeys, sind also nicht gegen Tippfehler abgesichert.
4.1.3.7. $::instance_conf
Objekt der Klasse "SL::InstanceConfiguration"
wird pro Request neu erstellt
Funktioniert wie $::lx_office_conf, speichert aber Daten die von der Instanz abhÃ¤ngig sind. Eine Instanz ist hier eine Mandantendatenbank. Beispielsweise Ã¼berprÃ¼ft
$::instance_conf->get_inventory_system eq 'perpetual'
- ob die berÃ¼chtigte Bestandsmethode zur Anwendung kommt.
4.1.3.8. $::dispatcher
Objekt der Klasse + ob die berÃ¼chtigte Bestandsmethode zur Anwendung kommt.
4.1.3.8. $::dispatcher
Objekt der Klasse "SL::Dispatcher"
wird pro Serverprozess erstellt.
enthÃ¤lt Informationen Ã¼ber die technische Verbindung zum Server
Der dritte Punkt ist auch der einzige Grund warum das Objekt global gespeichert wird. Wird vermutlich irgendwann in einem anderen - Objekt untergebracht.
4.1.3.9. $::request
Hashref (evtl spÃ¤ter Objekt)
Wird pro Request neu initialisiert.
Keine Unterstruktur garantiert.
+ Objekt untergebracht.
4.1.3.9. $::request
Hashref (evtl spÃ¤ter Objekt)
Wird pro Request neu initialisiert.
Keine Unterstruktur garantiert.
$::request ist ein generischer Platz um Daten "fÃ¼r den aktuellen Request" abzulegen. Sollte nicht fÃ¼r action at a distance benutzt werden, sondern um lokales memoizing zu @@ -176,20 +176,20 @@ file_name = /tmp/kivitendo-debug.log
ist der Key f $::request
Muss ich von anderen Teilen des Programms lesend drauf zugreifen? Dann $::request, aber Zugriff Ã¼ber - Wrappermethode

	Warnung
Zugriff auf die Konfiguration erfolgt im Moment Ã¼ber - Hashkeys, sind also nicht gegen Tippfehler abgesichert.

`4.1.4. Ehemalige globale Variablen`

Die folgenden Variablen waren einmal im Programm, und wurden - entfernt.

`4.1.4.1. $::cgi`

war nÃ¶tig, weil cookie Methoden nicht als + Wrappermethode

`4.1.4. Ehemalige globale Variablen`

Die folgenden Variablen waren einmal im Programm, und wurden + entfernt.

`4.1.4.1. $::cgi`

war nÃ¶tig, weil cookie Methoden nicht als Klassenfunktionen funktionieren
Aufruf als Klasse erzeugt Dummyobjekt was im Klassennamespace gehalten wird und Ã¼ber Requestgrenzen leaked
liegt jetzt unter $::request->{cgi} -

`4.1.4.2. $::all_units`

war nÃ¶tig, weil einige Funktionen in Schleifen zum Teil +

`4.1.4.2. $::all_units`

war nÃ¶tig, weil einige Funktionen in Schleifen zum Teil ein paar hundert mal pro Request eine Liste der Einheiten brauchen, und de als Parameter durch einen Riesenstack von Funktionen geschleift werden mÃ¼ssten.
Liegt jetzt unter $::request->{cache}{all_units}
Wird nur in AM->retrieve_all_units() gesetzt oder - gelesen.

`4.1.4.3. %::called_subs`

wurde benutzt um callsub deep recursions + gelesen.

`4.1.4.3. %::called_subs`

wurde benutzt um callsub deep recursions abzufangen.
Wurde entfernt, weil callsub nur einen Bruchteil der mÃ¶glichen Rekursioenen darstellt, und da nie welche auftreten.
komplette recursion protection wurde entfernt.

ZurÃ¼ck		Weiter
3.9. Webshop-Api	Zum Anfang	4.2. Entwicklung unter FastCGI

\ No newline at end of file diff --git a/doc/html/ch04s05.html b/doc/html/ch04s05.html index ee4fb33da..6d8c5dc04 100644 --- a/doc/html/ch04s05.html +++ b/doc/html/ch04s05.html @@ -44,10 +44,14 @@ 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. Der so angegebene Benutzer muss nicht zwingend Ã¼ber Super-User-Rechte verfÃ¼gen. Allerdings gibt es einige Datenbank-Upgrades, - die genau diese Rechte benÃ¶tigen. FÃ¼r den Fall kann man in diesem Konfigurationsabschnitt einen weiteren Benutzeraccount angeben, - der dann Ã¼ber Super-User-Rechte verfÃ¼gt, und mit dem die betroffenen Upgrades durchgefÃ¼hrt werden. In der - Beispiel-Konfigurationsdatei finden Sie die benÃ¶tigten Parameter.

`4.5.3. Existierende Tests ausfÃ¼hren`

Es gibt mehrere MÃ¶glichkeiten zum AusfÃ¼hren der Tests: entweder, + Recht haben, Datenbanken anzulegen und zu lÃ¶schen.

Der so angegebene Benutzer muss nicht zwingend Ã¼ber + Super-User-Rechte verfÃ¼gen. Allerdings gibt es einige + Datenbank-Upgrades, die genau diese Rechte benÃ¶tigen. FÃ¼r den Fall + kann man in diesem Konfigurationsabschnitt einen weiteren + Benutzeraccount angeben, der dann Ã¼ber Super-User-Rechte verfÃ¼gt, und + mit dem die betroffenen Upgrades durchgefÃ¼hrt werden. In der + Beispiel-Konfigurationsdatei finden Sie die benÃ¶tigten + Parameter.

`4.5.3. 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.pl.

Will man die komplette Test-Suite ausfÃ¼hren, so muss man einfach diff --git a/doc/html/index.html b/doc/html/index.html index d88dec005..c224ca6c2 100644 --- a/doc/html/index.html +++ b/doc/html/index.html @@ -1,7 +1,9 @@ - kivitendo 3.5.1-beta: Installation, Konfiguration, Entwicklung