Category Archives: Update

kivitendo 3.0 ubuntu 10.04 -> kivitendo 3.1 ubuntu 12.04

1 Reply

Als Ergänzung zum letzten Post, hier nochmal eine aktuellere Anleitung, da debian in der Tat schhon etwas intelligenter ist, als ich ;-).

Problem: kivi 3.0 mit Erweiterungen im eigenen Branch (Druckvorlagen, DATEV.pm, Defaulthaken in Berichten).

Als erstes “verheiraten” wir den branch mit der aktuellen Version. Die für uns am Besten geeignete Methode (Dank an Geoff, der das damals auf der 2011er-Schulung kurz erklärt hat), ist hier “rebasing”:

$ git checkout master
$ git pull
$ git checkout kundenbranch
$ git status -uno
$ git rebase master

Git Status -uno ist auch sehr schön, um direkt zu sehen, ob man Arbeitsverzeichnis “sauber” ist, d.h. es liegen keine nicht eingecheckten Änderungen “herum”.
So, es gibt einen Konflikt in der DATEV.pm, weil hier in Abstimmung mit dem Steuerberater ein Standard-DATEV-Feld als Personenkonto-Nummer umgewandelt wurde. Bei diesem Kunden (wie eigentlich auch bei den meisten Kunden) haben wir den gutartigen Fall: Kunden / Lieferantennummer == Personenkontonummer.

$ git mergetool
$ git add SL/DATEV.pm
$ git rebase –continue

Da die locale/de/all nervig zum “Rebasen” ist, wenn man hier viele Änderungen hat, deswegen hier noch mein Trick:
alle Änderungen, welche die all betreffen ignorieren (skip) und dann am Schluss nur die vier fehlenden Felder:

$ git checkout master — locale/de/all
$ git commit -m “wirkliche revision”

Damit ist das soweit abgehakt und das DB-Upgrade für den eigentlichen Mandanten kann durchgeführt werden. Ah, ok, es gibt eine Rose Client.Auth-Objekt Fehlermeldung wenn ich mich anmelde. Hier war ich etwas schlampig. wahrscheinlich fehlen Module für die 3.1

$ scripts/installation_check.pl -v
$ apt-get install libfile-copy-recursive-perl

Ok, leider fehlt noch rose-db in einer neueren Version, da hilft nur ein ubuntu-Upgrade und hier die Ergänzung zum vorherigen Post: Ja, ubuntu kann automagisch und sicher das Postgres-Cluster aktualisieren:

$ do-release-upgrade
$ pg_dropcluster –stop 9.1 main # 9.1 wieder deinstallieren
$ pg_upgradecluster
Starting target cluster on the original port… Success. Please check that the upgraded cluster works. If it does, you can remove the old cluster with pg_dropcluster 8.4 main

Sehr schön, damit ist alles erledigt. Ein Hoch auf das stressfreie Debian / Ubuntu

Upgrade auf die aktuelle Unstable – ein kleiner Erfahrungsbericht

W

Mit dem ersten Kunden sind wir vor zwei Wochen auf die aktuelle Unstable von kivitendo migriert, da endlich die Mandantenfähigkeit benutzt werden sollte.

Abgesehen vom Rebase für die kundenspezifischen Anpassungen gab es ein paar Hürden zu meistern:

Die neue Version setzt eine neuere Rose-Version voraus, hierfür mußte die Ubuntu Installation auf die Version 12.04 hochgezogen werden, womit sich auch gleich PostgreSQL von Version 8.4 auf 9.1 verbessert hat.

Mit diesem Update müssen ab sofort alle Artikelnummern eindeutig sein. Man kann nicht mehr z.B. einen Artikel und eine Dienstleistung beide mit der Nummer 1 haben. Im Laufe des Updateprozesses wird dies geprüft, und bei doppelten Artikeln erhält man die Möglichkeit, diese entsprechend zu ändern.

Aus dem Freitextfeld für Standardlagerplatz in der Artikelverwaltung werden nun zwei Dropdownfelder, wo man bestehende Lager und Lagerplätze auswählen kann. Dies ermöglicht es Lieferscheine bei entsprechend vorhandener Menge mit einem Knopfdruck komplett auszulagern, sofern für alle Artikel der hinterlegte Standardlagerplatz benutzt werden soll. Das Upgradeskript versucht hier das Freitextfeld vorhandenen Lagerplätzen automatisch zuzuweisen, bei Nichteindeutigkeit hat man aber noch die Chance, manuell auszuwählen.

Einige der Upgradeskripte laufen bei großen Datenbanken sehr lange, das hat bei mir auch schon mal 15 Minuten pro Mandant gedauert. Man sollte insbesondere bei Verwendung von fcgi darauf achten, daß die Timeouts entsprechend lang genug konfiguriert sind, sonst bricht das Upgrade zwischendurch ab. Bei mir war das der Parameter FcgidIOTimeout in der fcgid.conf.

Nach der Installation sind relativ schnell neue Fehler entdeckt worden, schließlich ist das ja noch eine kundenangepasste Unstableversion.

Insbesondere die Kundenanpassungen im Kundenbereich mußten umgeschrieben werden, da hier der Unterbau komplett ausgetauscht worden ist. Die Neuerungen machen dies aber insgesamt einfacher als vorher.

Es wurden auch gleich ein paar Bugs im Standard gefixed, siehe Tickets 2386, 2384 und 2381.

Bei der neuen Mandantenfähigkeit gab es dann noch eine Enttäuschung, und zwar sind die Benutzereinstellungen noch nicht mandantenfähig. Hat man dem Benutzer Schmitz den Mandanten FirmaA und FirmaB zugeordnet ist es noch nicht möglich, dem Benutzer in den beiden Mandanten unterschiedliche E-Mailadressen oder Signaturen zu geben.

Insgesamt überwiegt aber der positive Eindruck, die neue Einlagerungsfunktionalität mit Partpicker ist sehr schick, und auch die verküpften Belege sind eine feine Sache.

Mit der Mandantenfähigkeit kann jetzt auch endlich die WebDAV-Funktionalität mit unterschiedlichen Mandanten innerhalb einer Installation umgehen.

Wer nicht die Möglichkeit hat, schnell auf auftauchende Bugs zu reagieren, sollte jetzt zwar noch nicht unbedingt auf die Unstable migrieren, möglich ist es aber.

Die oben genannten Punkte gilt es aber spätestens bei der nächsten Stableversion zu beachten und sind hiermit schonmal als kleiner Erfahrungsbericht dokumentiert.

Auf jeden Fall sollte man das Upgrade erst in einer Testumgebung durchführen, und hierfür auch die lxerp_auth sichern.

Ich habe das Update auch in zwei Schritten durchgeführt, erst Ubuntu mit Postgres, und erst zwei Wochen später das kivitendo Update.