"Christopher Kuhn" on Mittwoch, 28. Dezember 2005 at 19:31 +0100 wrote:

Die Verwendung der Header birgt die Gefahr, dass manche Email-Clients Schindluder mit den Headern treiben und die X-Header vermurksen. Daher hat sich die Übergabe der Ticket-ID per Subject bewährt. :-)

Lieber Christopher, d'accord, aber doppelt gemoppelt (Header plus Subject) hielte vermutlich besser. Muesste man doch eigentlich per ausgehendem Postmaster-Filter auch selbst hinbasteln koennen, dass das OTRS einen entsprechenden Header erzeugt. Gelingt das, sollte es IMHO kein Problem darstellen, bei einer Mail mit einem solchen Header den Betreff dann entsprechend umzuschreiben. Eine anderer Ansatz zur Erhoehung der Robustheit waere das Starten der E-Mail mit automatisch eingefuegten Ticket-ID, die dann wieder ausgelesen wuerde. Wie ersteres erzeugt werden kann, wurde entweder auf der otrs.de- oder der englischsprachigen Anwender-Mailingliste bereits gezeigt (bitte selbst googeln, habe keinen Link parat). Ausserdem verfuegt OTRS ueber die Moeglichkeit, einen Zusammenhang zwischen Tickets per Message-ID herzustellen. Ich kann mich jedenfalls daran erinnern, vor Urzeiten meine config.pm (OTRS 1.3.2) entsprechend angepasst zu haben. Im Uebrigen kann ich nicht sagen, dass sich die Uebergabe per Subject richtig gut bewaehrt. Trotz diverser Hinweise schreiben immer wieder Kunden den Betreff um. Eine Anpassung des Tickethooks und Vergleich der Message-IDs bringt's auch nur teilweise. Hier faende ich es gut, wenn die Nennung der Ticketnummer ausreichte und nicht noch ein Tickethook gefordert waere. Oder habe ich da was uebersehen? Guten Rutsch, Soenke

Hallo Liste, ich bekomme seit ca. einer halben Std. folgende Meldung wenn ich eine bestimmte Queue im OTRS aufrufe: Software error: Got no ArticleID! at /opt/otrs/bin/cgi-bin/../../Kernel/Output/HTML/ArticleCheckPGP.pm line 32. For help, please send mail to the webmaster.... Kann dies damit zusammenhängen, daß auf der MySQL DB die Tabelle "article_attachment" vollgelaufen ist? Eine Abfrage der Tabelle mit otrs # myisamchk -dv article_attachment gibt mir folgendes aus: -------------------------------------------------------------snip------------------------------------------------------------------------------------ MyISAM file: article_attachment Record format: Packed Character set: latin1_swedish_ci (8) File-version: 1 Creation time: 2005-12-22 16:58:37 Recover time: 2005-12-28 20:19:34 Status: open,changed Auto increment key: 1 Last value: 312196 Data records: 201473 Deleted blocks: 0 Datafile parts: 201513 Deleted data: 0 Datafile pointer (bytes): 4 Keyfile pointer (bytes): 2 Datafile length: 4031040108 Keyfile length: 4926464 Max datafile length: 4294967294 Max keyfile length: 67107839 Recordlength: 585 table description: Key Start Len Index Type Rec/key Root Blocksize 1 2 8 unique longlong 1 2461696 1024 2 10 8 multip. longlong 2 4923392 1024 ----------------------------------------------------------------------snip---------------------------------------------------------------------------- Ebenso sagt mir ein Autocheck mit: "mysqlcheck --auto-repair --databases otrs -p", daß ich hier in der Tabelle ein Problem habe: otrs.article OK otrs.article_attachment warning : Datafile is almost full, 4031045324 of 4294967294 used status : OK ........ Eine Recherche meinerseits ergab, daß ich die Möglichkeit habe mit einem MySQL Statement die Tabelle zu erweitern: mysql> alter table article_attachment MAX_ROWS = "WERT"; Ich habe verschiedene Werte gesetzt (1000000 - 100000000), jedoch reagiert die Datenbank in keinster Weise darauf. Da ich ein absoluter Newbie bin was MySQL Datenbanken betrifft, so muß ich gestehen, daß ich hier nicht mehr weiter weiß und hoffe, daß jemand von euch einen Tipp hat, wie ich die Tabelle "aufblasen" kann, bzw. wie ich zu einem Lösungsergebnis komme. Ganz lieben Dank im Voraus. Beste Grüße, Christian Pirthauer