Update vom Freitag hat Benutzerdefinierte Variablen/Kundenverwaltung geschossen

[roman.karuschka@…]

Die benutzerdefineirten Variablen (zu den Kunden/Lieferanten?) sind nach dem Update vom Freitag auf mehreren Installationen nicht mehr verfuegbar, die Namen werden zwar auf der Seite der benutzerdefinierten Variablen in den Stammdaten noch angezeigt, aber es gibt keine Eingabefelder mehr.

Versucht man aus den ERP-Stammdaten nun einen Auftrag o.Ae. anzulegen:

Fehler!

SELECT COUNT(*) FROM custom_variables_validity WHERE config_id = ? AND trans_id = ? (1, 892)
FEHLER: Relation »custom_variables_validity« existiert nicht

Das Problem zieht sich wohl noch weiter als gedacht. Drucken ist aus Lieferscheinen nicht mehr meoglich (selbe Fehlermeldung) und auch an anderen Stellen sind wohl Dinge zerbrochen.

Ausloggen, einloggen, wie immer wenn neue Datenbank upgrades dabei sind.

Die Datei sql/Pg-upgrade2/custom_variables_valid.sql ist in commit 3e2892b1ac262d0dfd2679e254cc979a1b8405b8 enthalten, erstellt die benötigte Tabelle, und wird bei der ersten Anmeldung nach dem Upgrade automatisch ausgeführt.

die anderen ecken auch noch mal getestet, funktioniert bei mir alles einwandfrei,
bitte jemand mit einer gepatchten version durchtesten.

Sven, du hast Recht, bin jetzt beim Kunden. Mit dem Update geht es, aber aus irgendeinem Grund starten
zwei Installationen das Update nicht automatisch. Bei zwei Weiteren half der
neue Logon, mea culpa, den hatte ich bei denen nicht mehr durchgefuehrt, weil
ich den Fehler eigentlich nur noch erwartet hatte, da er vorher schon bei den
ersten beiden auftrat :-/

Updates bei den beiden per Hand nachgezogen.
Sieht ok aus.

(In reply to comment #4)

Sven, du hast Recht, bin jetzt beim Kunden. Mit dem Update geht es, aber aus
irgendeinem Grund starten
zwei Installationen das Update nicht automatisch. Bei zwei Weiteren half der
neue Logon, mea culpa, den hatte ich bei denen nicht mehr durchgefuehrt, weil
ich den Fehler eigentlich nur noch erwartet hatte, da er vorher schon bei den
ersten beiden auftrat :-/

Ich vermute da arbeiten Installationen auf der gleichen Datenbank. Der Status der Datenbankupgrades wird in der Datenbank selbst gespeichert, und wenn ein Upgrade eingespielt wurde, merkt sich die DB das. Die Lx-Office Installation stellt nur die Upgrades bereit.

Oder auch doch nicht.
Nachdem die Updates durch sind, geht das Ganze zwar wieder fuer bestehende Alt-Datensaetze..aber Neukundenanlage macht insofern Aerger, als das dort keine benutzerdefinierten Variablen beschreibbar sind.

Das habe ich jetzt etwas ausfuehrlicher getestet, aber kann das jemand verifizieren?

...und sobald man Alt-Datensaetze anfasst, verschwinden nun die Werte der benutzerdefinierten Variablen aus der Maske beim Speichern

ahjo, da schient noch ein bug zu sein.

Probier mal mit commit a5a7ff06d7ed7396e2efbe778c961e2784cb771b.

Ich konnte die Probleme in der Art nicht so nachvollziehen.

Was aber Ärgerlich ist, das nach einem "Erneuern" die angekreuzten, vorher noch nicht aktiven, Variablen wieder deaktiviert sind. Das bedeutet, man muß Variablen markieren und den Satz speichern. Wieder öffnen zum Bearbeiten und dann die vorbelegten Werte eintragen und noch einmal speichern.

Schöner wäre es, aktivieren, erneuern, vorbelegen, speichern.

(In reply to comment #11)

Ich konnte die Probleme in der Art nicht so nachvollziehen.

Was aber Ärgerlich ist, das nach einem "Erneuern" die angekreuzten, vorher noch
nicht aktiven, Variablen wieder deaktiviert sind. Das bedeutet, man muß
Variablen markieren und den Satz speichern. Wieder öffnen zum Bearbeiten und
dann die vorbelegten Werte eintragen und noch einmal speichern.

Schöner wäre es, aktivieren, erneuern, vorbelegen, speichern.

Das der gesamte Block um die benutzerdefinierten Variablen nicht erneuerbar ist, ist das sogar besser so, denn ungespeicherte Variablen gehen beim Erneuern auch verloren.

Irgendwann(tm) wird das sicher nochmal jemand richtig machen.

Hallo Sven. Bei bestandskunden nun besser, bei der Neukundenanlage existiert das Problem leider noch.

(In reply to comment #13)

Hallo Sven. Bei bestandskunden nun besser, bei der Neukundenanlage existiert
das Problem leider noch.

Welches Problem genau? Ich habe gerade einen neuen Kunden angelegt und das einmal durchgeklickert und das scheint alles zu funktionieren.

So kurzer nachtrag, eben schon mit Sven besprochen:
Die BDVs funktionieren in Kundendatensaetzen nun erst nach dem ersten Abspeichern des Datensatzes, nicht mehr bei der direkten Kundenneuanlage (was aber vorher moeglich war).

Interner Name ist CVar, kurz für custom variables, falls Dir die andere Abkürzung zu verwegen vorkommt.

Allerdings nur wenn Dir ETLAs nicht zu lang sind.

Und wie eben am Telefon besprochen werde ich schauen ob ich das irgendwie wieder auf das vorherige Verhalten biegen kann.

Funktioniert in den meisten Faellen wieder. Einige Datensaetze, die allerdings nun seit Freitag angefasst wurden scheinen immer noch imn alten Zustand zu stecken und auch durch erneutes Abspeichern die CVars in der Maske trotz des juengsten Updates nicht wieder freizugeben.

(In reply to comment #17)

Funktioniert in den meisten Faellen wieder. Einige Datensaetze, die allerdings
nun seit Freitag angefasst wurden scheinen immer noch imn alten Zustand zu
stecken und auch durch erneutes Abspeichern die CVars in der Maske trotz des
juengsten Updates nicht wieder freizugeben.

Das kann durchaus sein. In diesem Fall lösche bitte einmal manuell alles aus der Tabelle custom_variables_validity zum Beispiel mit:

DELETE FROM custom_variables_validity;

Das sollte den Zustand wieder resetten.

Und ein weiterer Versuch in 29b7a6417d94d11e0f07c595fafa1cc93aff362b.

CVar Inputs sollten jetzt bei neu anlegen Masken angezeigt und korrekt gehandhabt werden.

(ich mag dieses feature nicht....)

Du magst das Feature nicht? Bringt alle bei allen Kunden moeglicherweise notwendigen variablen fest rein, und wir brauchen es nicht mehr ;-)

Zumindest Kreditkartendaten (schonmal in einem anderen bug als verbesserung vorgeschlagen, ist noch offen) wuerde die Situation und Notwendigkeit bei einigen unserer Kunden deutlich entspannen.

Die Standardinstallation von LX eignet sich mit ihren Feldbenennungen vor allem fuer B2B-Einsaetze, das geht schon mit der Benennung des Namensfeldes "Firmenname" in den Stammdaten los, denn bei nicht-B2B kommen Firmen offensichtlich an der Stelle nicht vor und das Feld ist fehlbenannt.

In selber Manier sind auch benutzerdefinierte Variablen ein gewisser Segen, um sich da an die Realitaet vieler einsetzender Betriebe anzupassen.

Auch wenn's programmiertechnisch ein Fluch ist :-)

Von unserer Seite aus sieht das nach den letzten Updates recht gut aus, hoffentlich hab' ich nichts uebersehen ;-)

Ich schliesse den Bug damit ab, falls noch jemand Einwaende hat, dafuer gibt's ja "Reopened" :-)

Das Problem ist in der 2.6.1 und der 2.6.2-unstable vorhanden.
In der Online-Demo kann man es bei den Projekten schön beobachten.

Die CVars sind "ungültig" siehe Forum
​http://forum.lx-office.org/index.php?id=9839

Bei der unstable habe ich in Zeile 237 SL/CVars.pm

$act_var->{valid} = 1; # workaround, could not find the source of the error

geschrieben und es funktioniert. :-o

Das Löschen der Einträge in "custom_variables_validity" brachte keinen reproduzierbaren Erfolg. Woodoo? ;-)

Da sieht man die CVar noch.

Da sind die CVars unsichtbar.

Patch dazu in 4555e1300f7ddd26d4548156360f4988d5b835ff.

Testet das mal bitte, ob da _wieder_ irgendwas fehlt.

Danke für die schnelle Arbeit! :-)

Für neu angelegte Projekte funktioniert es.
Bei den vorhandenen Projekten versteckten sich die CVars noch, bis ich alle Einträge aus "custom_variables_validity" gelöscht hatte.
Bei Kunden und Lieferanten funktioniert es nach wie vor.
Bei den Waren, Dienstleistungen und Erzeugnissen habe ich es nicht bis zum Schluss durchgetestet, scheint zu gehen.

Das Problem sollte nur die Projekte betroffen haben, Waren und Kunden hatten die Validity flags korrekt gesetzt (das war auch der Grund warum ich den Bug letztes Jahr nicht nachvollzihen konnte, ich hab ihn bei Waren gesucht).

Das Update fixt natürlich keine bestehenden falschen Datenbankeinträge, beim nächsten Speichern des Projekts wird es aber korrekt abgespeichert, und dann ist alles in Butter.

Ein Datenbankupgrade was das behebt sähe etwa so aus, wenn sich jemand dransetzen möchte:

DELETE FROM custom_variables_validity cvv
LEFT JOIN custom_variable_configs cvc ON (cvc.id = cvv.config_id)
WHERE cvc.module = 'Project';

...irgendwie sowas.

ich betrachte das Ding mal als erledigt