Hauptmenü

Syntax der Komplexsuche in KIX18

Begonnen von kerstin, 03.04.2023 14:47:20

⏪ vorheriges - nächstes ⏩

kerstin

Hallo,

Bei uns scheint die in der Doku beschrieben Syntax der Komplexsuche (https://docs.kixdesk.com/kix18Anwendung/kix-start/werkzeugleiste/komplexsuche) nicht zu funktionieren. Der Versuch zwei Begriffe zu verknüpfen führt in allen beschriebenen Varianten zu keinem Ergbnis, wobei es sowohl Tickets mit jedem einzelnen dieser Begriffe, als auch Tickets mit beiden Begriffen gibt und diese auch - wenn man nach den einzelnen Begriffen sucht - gefunden werden.

Wir haben "Full Text", "Body" und "Subject" ausprobiert und die Begriffe jeweils mit '+', '&' und '|' verbunden.

Was machen wir falsch?

Vielen Dank und schönen Gruß,
Kerstin

Torsten Thau

Hallo,

Die Doku ist da ggf. etwas leicht misszuverstehen. Die Operatoren '+', '&' und '|' stehen derzeit nur bei der Suche nach Kontakten zur Verfügung - daher finden sich diese auch nur im Bereich "Kontakte" auf der referenzierten Dokumentationsseite. 

Das gewünschte Verhalten wurde bereits als Erweiterungswunsch von Forennutzer "mplan" in unser Backlog aufgenommen.

CU, Torsten

kerstin

Hallo Torsten,

Alles klar. Danke für die info.

Gruß,
Kerstin

kerstin

Moin Torsten,

Ich muss da jetzt doch nochmal nachhaken, da unsere Agenten KIX 17 auch immer als eine Art "Knowledge Datenbank" genutzt haben um in vergangenen Tickets Hinweise auf Lösungen zu neuen Tickets (wieder-) zu finden und daher diese Suchmöglichkeit sehr vermissen.

Gibt es denn irgendeine andere Art, wie man die Tickets bzw. die Artikel in KIX18 Pro über das Webinterface nach einer Kombination von Begriffen durchsuchen kann? z.B. mit SQL-Statements direkt auf der Datenbank?

Eine Idee von uns war z.B. eine Report Definition zu erstellen, die mittels eines entsprechenden SQL Satements die Tickets (mit Nummer und Titel o.ä.) zu Artikeln findet deren Body und/oder Subject die entsprechenden Begriffe enthält. Das ist sicherlich nicht gerade elegant oder gar effizient, aber denkst Du man könnte so etwas als Notlösung umsetzen? Und falls ja, könntest Du uns vielleicht sogar einen Tipp für ein einigermaßen effizientes SQL Statement geben?

Oder gibt es einen anderen, sinnvolleren Weg?

Vielen Dank und schönen Gruß,
Kerstin