Feature #5805
open
TypeAHead SQL value instead of key stored
0%
Description
Ich habe ein Textfeld mit folgenden Parametern:
typeAheadSql = SELECT shortname AS 'id', CONCAT(firstname, ' ', lastname, ', ', shortname) AS 'value' FROM _right_to_confer_phd WHERE lastname LIKE ? OR firstname LIKE ? or shortname LIKE ? ORDER BY lastname
typeAheadSqlPrefetch = SELECT CONCAT(firstname, ' ', lastname, ', ', shortname) AS value FROM _right_to_confer_phd WHERE shortname=?
typeAheadMinLength = 1
typeAheadLimit = 20
typeAheadPedantic = 0
Die Suche funktioniert, aber beim Speichern wird der Value (firstname lastname, shortname) statt der id (shortname) gespeichert.
Problem scheint, dass JS im hidden Feld den Value statt der id einfügt...
Related issues
Updated by Nicola Chiapolini about 6 years ago
Scheint typeAheadPedantic = 1 löst das Problem
Evtl. könnte das in der Dokumentation besser erklärt werden...
Updated by Nicola Chiapolini about 6 years ago
- Status changed from New to Ready to sync (develop)
Updated by Carsten Rose about 6 years ago
- Status changed from Ready to sync (develop) to In Progress
- Target version set to 55
In Doku besser beschreiben
Updated by Carsten Rose about 6 years ago
- Related to Bug #5444: typeahead: Nach einem Save wird der key angezeigt statt dem Value added
Updated by Carsten Rose over 5 years ago
- Tracker changed from Support to Feature
Updated by Carsten Rose over 4 years ago
- Status changed from New to Some day maybe
Updated by Carsten Rose over 4 years ago
- Target version changed from 55 to next9
Updated by Nicola Chiapolini over 1 year ago
- Prio Planung set to No
Wir sind eben wieder in das Problem gelaufen (v23.1.1), deshalb ein Update
typeAheadPedantic = 1 löst das Problem jetzt nicht, gut möglich dass es das auch früher nicht gelöst hat.
Das Problem tritt auf in einem Textfeld mit dynamic update und typeAhead.
typeAheadSql = SELECT id AS 'id', PC_Stufe3 AS 'value' FROM org_units_fv WHERE PC_Stufe3 LIKE ? typeAheadSqlPrefetch = SELECT id AS 'id', PC_Stufe3 AS 'value' FROM org_units_fv WHERE id=? typeAheadMinLength = 3 typeAheadLimit = 40 typeAheadPedantic = 1
(PC_Stufe3 beginnt mit zahlen)
- Wenn ich das Feld das erste Mal speichere, landet die ID in der DB.
- Wenn ich das Formular wieder öffne, ein anderes Feld verändere und wieder speichere, landen die Ziffern aus PC_Stufe3 in der DB
Die Lösung, die wohl auch letztes Mal funktioniert hat, war die Daten gar nicht via Text-Feld sondern via separate afterSave Action zu speichern.
Puzzeling Fact: Die funktionierende Lösung hat ein DB-Feld origin und zwei FormElement nodb_origin (text, mit dem Inhalt oben) und nodb_safe_origin (afterSafe-Action). Wenn ich im sqlBefore-Query von nodb_safe_origin einen Fehler habe, schafft es QFQ irgendwie wieder die Ziffern aus PC_Stufe3 in die DB zu schreiben - obwohl das Formular gar kein entsprechendes Element hat...
Updated by Nicola Chiapolini over 1 year ago
PS: eine zusätzlicher, positiver Effekt der Lösung mit separatem afterSafe ist, dass ich so den Inhalt des Feldes löschen kann, wenn es ausgeblendet wird...
Updated by Carsten Rose over 1 year ago
- Status changed from Some day maybe to New
- Target version changed from next9 to 24.9.0
Updated by Nicola Chiapolini over 1 year ago
Und noch ein Hinweis, die Lösung hat doch nicht ganz funktioniert. Das Probelm bestand weiterhin, wen nodb_origin ausgeblendet war. Dann wurde das Fomular immer als verändert betrachtet und die entsprechende Browserwarnung ausgelöst (letztes Mal war wurde das Formular wohl nur zum Erstellen genutzt, dann scheint alles zu funktionieren). Das Problem wurde (hoffentlich) gelöst, indem das wir doch wieder direkt origin bearbeiten, das Feld immer angezeigen aber den Inhalt via sqlValidate prüfen... Nicht besonders elegant.
(Alles in allem scheint es hier zu viele bewegliche Teile mit unerwarteten Interaktionen zu haben. Evtl. könnte die Dokumentation hier weiterhelfen: Wie mache ich ein nur manchmal angezeigtes Formularfeld mit TypeAHead-SQL?)