Erstellt vor 13 Monaten

Geschlossen vor 13 Monaten

Zuletzt geändert vor 13 Monaten

#2445 closed Fehler (works-for-me)

Speicher von Lieferanten erzeugt Fehler

Erstellt von: hli@… Verantwortlicher:
Priorität: sehr hoch Meilenstein: 3.1.0
Komponente: kivitendo ERP Version: 3.0.0 unstable
Schweregrad: schwerwiegend Stichworte:
Beobachter:

Beschreibung

Beim Speichern eines Lieferanten wird folgender Fehler geworfem:

do_transaction() failed - get_objects() - SL::DB::Vendor: Value for user_password() is too long. Maximum length is 12 characters. Value is 15 characters: 6BC81BEA7175EF0 at /usr/share/perl5/Rose/Object.pm line 25

at /var/www/kivitendo-erp/SL/DB/Vendor.pm line 38

Das Feld passwort ist aber leer.

Änderungshistorie (14)

comment:1 Geändert vor 13 Monaten durch jbueren

Kann ich so nicht reproduzieren:

Stammdaten -> Lieferant erfassen -> Name: 21 a speichern -> i.O.

Stammdaten -> Lieferant erfassen -> Name: 21 b Passwort: 123456789012345 speichern -> n.i.O. (Fehlermeldung wie oben)

Stammdaten -> Lieferant erfassen -> Name: 21 b Passwort: 123456789012 speichern -> i.O.

15 Leerzeichen oder so?

comment:2 Geändert vor 13 Monaten durch hli@…

Nein, Passwort ist leer. Habe auch schon Passwort X versucht
Git: 5012e90

Ausser dem:

user_password | character(20)

comment:3 Geändert vor 13 Monaten durch jbueren

  • Lösung auf works-for-me gesetzt
  • Status von new nach closed geändert

Sorry.
Ich hab die Revision auch ausgecheckt und den apache nochmal neugestartet (ggf. fcgi).

Kontenrahmen SKR04 neuer Mandant.
Da muss noch ein anderer Parameter abweichen.

comment:4 Geändert vor 13 Monaten durch hli@…

Und welcher bitte? Woher kommt 6BC81BEA7175EF0?
Die Maske enthält nur das Nötigste.

Postgresql + Apache sind neu gestartet. Das Statement selber kommt, lt DB-Log, in der DB nicht an.

comment:5 Geändert vor 13 Monaten durch jbueren

Sorry Holger,
hast Du noch einen anderen Server zum Testen oder kannst Du es in der nächtlichen Beta reproduzieren:

https://demo.kivitendo.de/beta/

Ich leider nicht .. :-(

comment:6 Geändert vor 13 Monaten durch m.bunkus@…

Ein rekursives grep nach dem Wert 6BC81BEA7175EF0 liefert nichts (= nicht die Schuld vom offiziellen Entwicklungszweig). Hast du in deiner Datenbank evtl. einen Default-Wert auf der Spalte?

comment:7 Geändert vor 13 Monaten durch m.bunkus@…

Oder dein Webbrowser füllt das Feld automatisch oder oder oder…

Ganz davon ab: eine (so geringe) Maximallänge auf einem Passwortfeld ist sicherheitstechnisch absoluter Unsinn und sollte kivitendo-seitig geändert werden.

comment:8 Geändert vor 13 Monaten durch hli@…

Nein, der Browser macht nichts. Habe einen anderen getestet.
Ein Grep im einem aktuellen DB-Dump findet die Zeichenfolge nicht.

Ausserdem wird auf max 12 Zeichen geprüft, das Feld hat aber 20 Zeichen. Und dieser komische Wert hat 16 Zeichen.

Der Installcheck gibt für alle Libs grün.

comment:9 Geändert vor 13 Monaten durch hli@…

Distriupdate durchgeführt. Debian 6.

Um die DB-Version auszuschließen, habe ich nun neben der 8.4 eine 9.1 aus den Backports installiert.
Hier tritt das gleiche Problem auf.

comment:10 Geändert vor 13 Monaten durch hli@…

Ich kann das Problem nun etwas eingrenzen.
Die Instanz, ist eine lange gepflegte Instanz. D.h. sie kommt von der 2.6, 2.7 auf die aktuelle GIT.

Ich habe diese DB nun mal in der Entwicklungsumgebung eingespielt. Und mit dieser DB kommt der Fehler auch da.
Ist das mglw. bei den Migrationsscripten irgend etwas faul?

comment:11 Geändert vor 13 Monaten durch m.bunkus@…

Hast du irgendwelche Trigger in der Datenbank, die etwas mit Tabelle vendor machen? Ist ja schon verdächtig, dass dein Dantenbankschema (das Feld hat aber 20 Zeichen) vom offiziellen Schema abweicht. Denn das offizielle Schema legt die Spalte mit 12 Zeichen an, und das ist auch z.B. in meiner langlebigen Entwickler-DB weiterhin so.

comment:12 Geändert vor 13 Monaten durch m.bunkus@…

So nochmal. Du hast Scheiße in deiner Datenbank stehen.

Die Fehlermeldung verrät, dass das Problem nicht beim Speichern, sondern beim Auslesen von Lieferanten auftritt (get_objects()). Dein Datenbankschema (…Spalte mit 20 Zeichen…) weicht von dem ab, was kivitendos Rose-Schema-Dateien erwarten (user_password hat Maximallänge 12).

Beim Auslesen prüft nun Rose, ob die von der DB gelieferten Werte mit den eigenen Schemata übereinstimmt. Das ist bei dir aber für mindestens eine Zeile nicht der Fall.

Mach doch mal Scherze wie SELECT id, name, user_password FROM vendor WHERE LENGTH(user_password) > 12.

Ein kurzes grep auf das Verzeichnis sql verrät, dass vendor.user_password initial mit Länge 12 angelegt und seitdem in keinem einzigen Upgradescript auch nur angefasst wurde.

Ergo: du hast deine Datenbank verfriemelt.

comment:13 Geändert vor 13 Monaten durch hli@…

Hi, soweit bin ich inzwischen auch. Und es gibt tatsächlich ein Passwort mit der Länge 15.
Wenn ich mir den Lieferanten ansehe, weiß ich auch, dass ich das Feld vergrößert habe, da dass Passwort länger als 12 war.
Hmm, bin ich der einzige? Oder wird das nun noch erst aufkommen?
Das Passwort kommt somit nun nach note und alles tut. Sinnvoll?

comment:14 Geändert vor 13 Monaten durch m.bunkus@…

Wie ich oben schon geschrieben habe, ist eine Längenbeschränkung auf einem Passwortfeld unsinnig. In der Tabelle customer hat das Feld auch keine solche Beschränkung. Das in der Tabelle vendor entsprechend zu erweitern ist kein Problem aber kein Bug sondern ein Feature-Wunsch, der sinnvollerweise in einem neuen Ticket unterzubringen ist.

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.