May 2008 - otrs-de - OTRS mailing lists

Free Fields Multiline
by Lorenzo MUELLER 19 May '08

19 May '08

Hi an alle, Ich habe da ein Problem, Ich will ein zusätzliches "Free Field" anlegen -> So weit so gut - NUR: Diese Felder sind recht kurz und erlauben ausserdem keine Merhzeiligen Inhalte. Ist es daher möglich ein "Free Field" als "Multiline" darzustellen (nicht 1-zeilig, sondern eben mehrzeilig...). Vielen Dank im Voraus für Euer Feedback.. Lorenzo Müller

1 0

Antw: otrs-de Nachrichtensammlung, Band 55, Eintrag 16 (Abwesenheitsmeldung)
by André Meißner 17 May '08

17 May '08

** Reply Requested by 5/18/2008 (Sunday) ** Guten Tag, ich bin in der Woche vom 19.05.-23-05. nicht im Haus. Bitte haben Sie Verständnis, das ich mich erst danach bei Ihnen melden kann. Mit feundlichen Grüssen André Meißner >>> otrs-de 17.05.08 14:00 >>> Um e-Mails an die Liste otrs-de zu schicken, nutzen Sie bitte die Adresse otrs-de(a)otrs.org Um sich via Web von der Liste zu entfernen oder draufzusetzen: http://lists.otrs.org/mailman/listinfo/otrs-de oder, via Email, schicken Sie eine Email mit dem Wort 'help' in Subject/Betreff oder im Text an otrs-de-request(a)otrs.org Sie koennen den Listenverwalter dieser Liste unter der Adresse otrs-de-owner(a)otrs.org erreichen Wenn Sie antworten, bitte editieren Sie die Subject/Betreff auf einen sinnvollen Inhalt der spezifischer ist als "Re: Contents of otrs-de digest..." Meldungen des Tages: 1. Performance Kalender (Jürgen Schulz-Brüssel | Fotofinder GmbH) 2. Performance Kalender (Jürgen Schulz-Brüssel | Fotofinder GmbH) 3. Performance Kalender (Jürgen Schulz-Brüssel | Fotofinder GmbH) 4. Zugriffsrechte auf Firmentickets (Wetzel) 5. Zugriffsrechte auf Firmentickets (Wetzel) ---------------------------------------------------------------------- Message: 1 Date: Fri, 16 May 2008 13:44:09 +0200 From: Jürgen Schulz-Brüssel | Fotofinder GmbH <jsb(a)fotofinder.com> Subject: [otrs-de] Performance Kalender To: otrs-de(a)otrs.org Message-ID: <482D7389.7010800(a)fotofinder.com> Content-Type: text/plain; charset=ISO-8859-1 Hallo, wir beobachten seit einiger Zeit erhebliche Probleme mit dem OTRS Kalender (Version 1.7.1). Namentlich brauchen wir ca. 1 Sekunde, um einen Kalendereintrag im Webinterface darzustellen. Ansonsten rennt das OTRS nicht gerade, aber es hat eine durchaus zufriedenstellende Geschwindigkeit. Datenbankseitig habe ich keine großen Performance Probleme beobachten können. Die Tabellen 'calendar_event_involved' und 'calendar_event' haben 3395 bzw. 2252 Einträge und liefern auf der Commandline ein select in der Regel im Bereich von wenigen Millisekunden zurück (hier scheint das Problem also nicht zu liegen). Ich habe zurzeit darauf verzichtet Zeitmessungen mit Time::Hires innerhalb der Kalendermodule vorzunehmen (kann also nicht richtig sagen, wo wir wirklich die Zeit verlieren). Hat jemand schon ähnliche Probleme beobachtet und evtl. eine Lösung dafür gefunden? Folgende Rahmenbedingungen haben wir: bis zu 50 Kalendereinträge pro Woche (bei ca. 15 Nutzern) Folgende Maßnahmen habe ich derzeit ergriffen: - alle Kalendermodule ins Startup Script (apache2-perl-startup.pl) geschrieben. Zudem habe ich passend zum Interface eine Tagesansicht eingeführt (die schon in der Version 1.3 nicht verfügbar war) und die Useraktionen in aller Regel gegen die Tagesansicht ausgeführt, so dass nach einem Update möglichst wenig Termine neu geladen werden müssen. Darüberhinaus habe ich Knöpfe für gestern und morgen gemacht, damit möglichst wenige Aktionen dazu führen, dass eine Wochenansicht dargestellt wird. Was genau hat die aktuelle Version vom Kalender verbessert? (ein Changelog wäre schön). Im Einsatz ist bei uns ein OTRS 2.2.4 auf einem CentOS 4.6 mit einner Mysql DB. Es grüßt Euch Jürgen -- Fotofinder GmbH USt-IdNr. DE812854514 Software Entwicklung Web: http://www.fotofinder.com/ Potsdamer Str. 96 Tel: +49 30 25 79 28 90 10785 Berlin Fax: +49 30 25 79 28 999 Geschäftsführer: Ali Paczensky Amtsgericht: Berlin Charlottenburg (HRB 73099) Sitz: Berlin ------------------------------ Message: 2 Date: Fri, 16 May 2008 11:53:59 +0200 From: Jürgen Schulz-Brüssel | Fotofinder GmbH <jsb(a)fotofinder.com> Subject: [otrs-de] Performance Kalender To: otrs-de-request(a)otrs.org Message-ID: <482D59B7.7050906(a)fotofinder.com> Content-Type: text/plain; charset=ISO-8859-1 Hallo, wir beobachten seit einiger Zeit erhebliche Probleme mit dem OTRS Kalender (Version 1.7.1). Namentlich brauchen wir ca. 1 Sekunde, um einen Kalendereintrag im Webinterface darzustellen. Ansonsten rennt das OTRS nicht gerade, aber es hat eine durchaus zufriedenstellende Geschwindigkeit. Datenbankseitig habe ich keine großen Performance Probleme beobachten können. Die Tabellen 'calendar_event_involved' und 'calendar_event' haben 3395 bzw. 2252 Einträge und liefern auf der Commandline ein select in der Regel im Bereich von wenigen Millisekunden zurück (hier scheint das Problem also nicht zu liegen). Ich habe zurzeit darauf verzichtet Zeitmessungen mit Time::Hires innerhalb der Kalendermodule vorzunehmen (kann also nicht richtig sagen, wo wir wirklich die Zeit verlieren). Hat jemand schon ähnliche Probleme beobachtet und evtl. eine Lösung dafür gefunden? Folgende Rahmenbedingungen haben wir: bis zu 50 Kalendereinträge pro Woche (bei ca. 15 Nutzern) Folgende Maßnahmen habe ich derzeit ergriffen: - alle Kalendermodule ins Startup Script (apache2-perl-startup.pl) geschrieben. Zudem habe ich passend zum Interface eine Tagesansicht eingeführt (die schon in der Version 1.3 nicht verfügbar war) und die Useraktionen in aller Regel gegen die Tagesansicht ausgeführt, so dass nach einem Update möglichst wenig Termine neu geladen werden müssen. Darüberhinaus habe ich Knöpfe für gestern und morgen gemacht, damit möglichst wenige Aktionen dazu führen, dass eine Wochenansicht dargestellt wird. Was genau hat die aktuelle Version vom Kalender verbessert? (ein Changelog wäre schön). Im Einsatz ist bei uns ein OTRS 2.2.4 auf einem CentOS 4.6 mit einner Mysql DB. Es grüßt Euch Jürgen -- Fotofinder GmbH USt-IdNr. DE812854514 Software Entwicklung Web: http://www.fotofinder.com/ Potsdamer Str. 96 Tel: +49 30 25 79 28 90 10785 Berlin Fax: +49 30 25 79 28 999 Geschäftsführer: Ali Paczensky Amtsgericht: Berlin Charlottenburg (HRB 73099) Sitz: Berlin ------------------------------ Message: 3 Date: Fri, 16 May 2008 11:53:59 +0200 From: Jürgen Schulz-Brüssel | Fotofinder GmbH <jsb(a)fotofinder.com> Subject: [otrs-de] Performance Kalender To: otrs-de-request(a)otrs.org Message-ID: <482D59B7.7050906(a)fotofinder.com> Content-Type: text/plain; charset=ISO-8859-1 Hallo, wir beobachten seit einiger Zeit erhebliche Probleme mit dem OTRS Kalender (Version 1.7.1). Namentlich brauchen wir ca. 1 Sekunde, um einen Kalendereintrag im Webinterface darzustellen. Ansonsten rennt das OTRS nicht gerade, aber es hat eine durchaus zufriedenstellende Geschwindigkeit. Datenbankseitig habe ich keine großen Performance Probleme beobachten können. Die Tabellen 'calendar_event_involved' und 'calendar_event' haben 3395 bzw. 2252 Einträge und liefern auf der Commandline ein select in der Regel im Bereich von wenigen Millisekunden zurück (hier scheint das Problem also nicht zu liegen). Ich habe zurzeit darauf verzichtet Zeitmessungen mit Time::Hires innerhalb der Kalendermodule vorzunehmen (kann also nicht richtig sagen, wo wir wirklich die Zeit verlieren). Hat jemand schon ähnliche Probleme beobachtet und evtl. eine Lösung dafür gefunden? Folgende Rahmenbedingungen haben wir: bis zu 50 Kalendereinträge pro Woche (bei ca. 15 Nutzern) Folgende Maßnahmen habe ich derzeit ergriffen: - alle Kalendermodule ins Startup Script (apache2-perl-startup.pl) geschrieben. Zudem habe ich passend zum Interface eine Tagesansicht eingeführt (die schon in der Version 1.3 nicht verfügbar war) und die Useraktionen in aller Regel gegen die Tagesansicht ausgeführt, so dass nach einem Update möglichst wenig Termine neu geladen werden müssen. Darüberhinaus habe ich Knöpfe für gestern und morgen gemacht, damit möglichst wenige Aktionen dazu führen, dass eine Wochenansicht dargestellt wird. Was genau hat die aktuelle Version vom Kalender verbessert? (ein Changelog wäre schön). Im Einsatz ist bei uns ein OTRS 2.2.4 auf einem CentOS 4.6 mit einner Mysql DB. Es grüßt Euch Jürgen -- Fotofinder GmbH USt-IdNr. DE812854514 Software Entwicklung Web: http://www.fotofinder.com/ Potsdamer Str. 96 Tel: +49 30 25 79 28 90 10785 Berlin Fax: +49 30 25 79 28 999 Geschäftsführer: Ali Paczensky Amtsgericht: Berlin Charlottenburg (HRB 73099) Sitz: Berlin ------------------------------ Message: 4 Date: Fri, 16 May 2008 15:58:11 +0200 From: Wetzel, Rüdiger <Ruediger.Wetzel(a)eurodok.de> Subject: [otrs-de] Zugriffsrechte auf Firmentickets To: <otrs-de(a)otrs.org> Message-ID: <D1DF6BEF7FBA1847BD36F45B6451EB3A0AE24B(a)server-x.de.eurodok.org> Content-Type: text/plain; charset="iso-8859-1" Hallo, ich bekomme immer noch die gleiche Meldung (Keine Zugriffsrechte!) wenn ein Kunden-Benutzer auf ein Firmen-Tickte zugreift welches von einem anderem Kunden-Benutzer angelegt wurde. Die Einstellungen habe ich entsprechend der Hinweise in der Bugliste (http://bugs.otrs.org/show_bug.cgi?id(70) im System geändert. CustomerTicket::Permission###2-CustomerIDCheck to Granted = 1 CustomerTicket::Permission###1-CustomerUserIDCheck to Granted = 1 Hat vielleicht jemand eine Idee an was das sonst noch liegen könnte ? Wir setzen OTRS 2.2.6 ein. Vielen Dank schon mal für eure Hinweise! Rüdiger Wetzel ------------------------------ Message: 5 Date: Fri, 16 May 2008 16:08:54 +0200 From: Wetzel, Rüdiger <Ruediger.Wetzel(a)eurodok.de> Subject: [otrs-de] Zugriffsrechte auf Firmentickets To: <otrs-de(a)otrs.org> Message-ID: <D1DF6BEF7FBA1847BD36F45B6451EB3A0AE24C(a)server-x.de.eurodok.org> Content-Type: text/plain; charset="iso-8859-1" Hallo, ich bekomme immer noch die gleiche Meldung (Keine Zugriffsrechte!) wenn ein Kunden-Benutzer auf ein Firmen-Tickte zugreift welches von einem anderem Kunden-Benutzer angelegt wurde. Die Einstellungen habe ich entsprechend der Hinweise in der Bugliste (http://bugs.otrs.org/show_bug.cgi?id(70) im System geändert. CustomerTicket::Permission###2-CustomerIDCheck to Granted = 1 CustomerTicket::Permission###1-CustomerUserIDCheck to Granted = 1 Hat vielleicht jemand eine Idee an was das sonst noch liegen könnte ? Wir setzen OTRS 2.2.6 ein. Vielen Dank schon mal für eure Hinweise! Rüdiger Wetzel ------------------------------ _______________________________________________ otrs-de mailing list otrs-de(a)otrs.org http://lists.otrs.org/mailman/listinfo/otrs-de Ende otrs-de Nachrichtensammlung, Band 55, Eintrag 16 *****************************************************

1 0

Zugriffsrechte auf Firmentickets
by Wetzel, Rüdiger 16 May '08

16 May '08

Hallo, ich bekomme immer noch die gleiche Meldung (Keine Zugriffsrechte!) wenn ein Kunden-Benutzer auf ein Firmen-Tickte zugreift welches von einem anderem Kunden-Benutzer angelegt wurde. Die Einstellungen habe ich entsprechend der Hinweise in der Bugliste (http://bugs.otrs.org/show_bug.cgi?id=2870) im System geändert. CustomerTicket::Permission###2-CustomerIDCheck to Granted = 1 CustomerTicket::Permission###1-CustomerUserIDCheck to Granted = 1 Hat vielleicht jemand eine Idee an was das sonst noch liegen könnte ? Wir setzen OTRS 2.2.6 ein. Vielen Dank schon mal für eure Hinweise! Rüdiger Wetzel

1 0

Zugriffsrechte auf Firmentickets
by Wetzel, Rüdiger 16 May '08

16 May '08

Hallo, ich bekomme immer noch die gleiche Meldung (Keine Zugriffsrechte!) wenn ein Kunden-Benutzer auf ein Firmen-Tickte zugreift welches von einem anderem Kunden-Benutzer angelegt wurde. Die Einstellungen habe ich entsprechend der Hinweise in der Bugliste (http://bugs.otrs.org/show_bug.cgi?id=2870) im System geändert. CustomerTicket::Permission###2-CustomerIDCheck to Granted = 1 CustomerTicket::Permission###1-CustomerUserIDCheck to Granted = 1 Hat vielleicht jemand eine Idee an was das sonst noch liegen könnte ? Wir setzen OTRS 2.2.6 ein. Vielen Dank schon mal für eure Hinweise! Rüdiger Wetzel

1 0

Performance Kalender
by Jürgen Schulz-Brüssel | Fotofinder Gmb H 16 May '08

16 May '08

Hallo, wir beobachten seit einiger Zeit erhebliche Probleme mit dem OTRS Kalender (Version 1.7.1). Namentlich brauchen wir ca. 1 Sekunde, um einen Kalendereintrag im Webinterface darzustellen. Ansonsten rennt das OTRS nicht gerade, aber es hat eine durchaus zufriedenstellende Geschwindigkeit. Datenbankseitig habe ich keine großen Performance Probleme beobachten können. Die Tabellen 'calendar_event_involved' und 'calendar_event' haben 3395 bzw. 2252 Einträge und liefern auf der Commandline ein select in der Regel im Bereich von wenigen Millisekunden zurück (hier scheint das Problem also nicht zu liegen). Ich habe zurzeit darauf verzichtet Zeitmessungen mit Time::Hires innerhalb der Kalendermodule vorzunehmen (kann also nicht richtig sagen, wo wir wirklich die Zeit verlieren). Hat jemand schon ähnliche Probleme beobachtet und evtl. eine Lösung dafür gefunden? Folgende Rahmenbedingungen haben wir: bis zu 50 Kalendereinträge pro Woche (bei ca. 15 Nutzern) Folgende Maßnahmen habe ich derzeit ergriffen: - alle Kalendermodule ins Startup Script (apache2-perl-startup.pl) geschrieben. Zudem habe ich passend zum Interface eine Tagesansicht eingeführt (die schon in der Version 1.3 nicht verfügbar war) und die Useraktionen in aller Regel gegen die Tagesansicht ausgeführt, so dass nach einem Update möglichst wenig Termine neu geladen werden müssen. Darüberhinaus habe ich Knöpfe für gestern und morgen gemacht, damit möglichst wenige Aktionen dazu führen, dass eine Wochenansicht dargestellt wird. Was genau hat die aktuelle Version vom Kalender verbessert? (ein Changelog wäre schön). Im Einsatz ist bei uns ein OTRS 2.2.4 auf einem CentOS 4.6 mit einner Mysql DB. Es grüßt Euch Jürgen -- Fotofinder GmbH USt-IdNr. DE812854514 Software Entwicklung Web: http://www.fotofinder.com/ Potsdamer Str. 96 Tel: +49 30 25 79 28 90 10785 Berlin Fax: +49 30 25 79 28 999 Geschäftsführer: Ali Paczensky Amtsgericht: Berlin Charlottenburg (HRB 73099) Sitz: Berlin

1 0

Performance Kalender
by Jürgen Schulz-Brüssel | Fotofinder Gmb H 16 May '08

16 May '08

Hallo, wir beobachten seit einiger Zeit erhebliche Probleme mit dem OTRS Kalender (Version 1.7.1). Namentlich brauchen wir ca. 1 Sekunde, um einen Kalendereintrag im Webinterface darzustellen. Ansonsten rennt das OTRS nicht gerade, aber es hat eine durchaus zufriedenstellende Geschwindigkeit. Datenbankseitig habe ich keine großen Performance Probleme beobachten können. Die Tabellen 'calendar_event_involved' und 'calendar_event' haben 3395 bzw. 2252 Einträge und liefern auf der Commandline ein select in der Regel im Bereich von wenigen Millisekunden zurück (hier scheint das Problem also nicht zu liegen). Ich habe zurzeit darauf verzichtet Zeitmessungen mit Time::Hires innerhalb der Kalendermodule vorzunehmen (kann also nicht richtig sagen, wo wir wirklich die Zeit verlieren). Hat jemand schon ähnliche Probleme beobachtet und evtl. eine Lösung dafür gefunden? Folgende Rahmenbedingungen haben wir: bis zu 50 Kalendereinträge pro Woche (bei ca. 15 Nutzern) Folgende Maßnahmen habe ich derzeit ergriffen: - alle Kalendermodule ins Startup Script (apache2-perl-startup.pl) geschrieben. Zudem habe ich passend zum Interface eine Tagesansicht eingeführt (die schon in der Version 1.3 nicht verfügbar war) und die Useraktionen in aller Regel gegen die Tagesansicht ausgeführt, so dass nach einem Update möglichst wenig Termine neu geladen werden müssen. Darüberhinaus habe ich Knöpfe für gestern und morgen gemacht, damit möglichst wenige Aktionen dazu führen, dass eine Wochenansicht dargestellt wird. Was genau hat die aktuelle Version vom Kalender verbessert? (ein Changelog wäre schön). Im Einsatz ist bei uns ein OTRS 2.2.4 auf einem CentOS 4.6 mit einner Mysql DB. Es grüßt Euch Jürgen -- Fotofinder GmbH USt-IdNr. DE812854514 Software Entwicklung Web: http://www.fotofinder.com/ Potsdamer Str. 96 Tel: +49 30 25 79 28 90 10785 Berlin Fax: +49 30 25 79 28 999 Geschäftsführer: Ali Paczensky Amtsgericht: Berlin Charlottenburg (HRB 73099) Sitz: Berlin

1 0

Test Message
by Shawn Beasley 16 May '08

16 May '08

This is a test of the list -- Shawn Beasley ((otrs)) :: OTRS AG :: Norsk-Data-Straße 1 :: 61352 Bad Homburg Fon: +49 (0) 9421 56818 0 :: Fax: +49 (0) 9421 56818 18 http://www.otrs.com/ :: Communication with success! Geschäftssitz: Bad Homburg Amtsgericht Bad Homburg, HRB 10751 Steuernummer: 003/240/97521 Aufsichtsratsvorsitzender: Burchard Steinbild Vorstandsvorsitzender: André Mindermann

1 0

richtext/html editor für otrs antwort
by it-news (Josef Lahmer) 16 May '08

16 May '08

hallo liste, hatte jemand von euch schon erfahrung bzw den wunsch nach optischer gestaltung von antwortemails? grad ein paar funktionen wie das text einfärben/fett/kursiv, aufzählungszeichen wäre für agents interessant. lg josy --------------------------------------- 400 Tonnen! Diese Menge an CO2 haben unsere Kunden bis heute durch klimaneutrales Drucken ausgeglichen. Zeigen auch Sie Ihr Engagement in Sachen Klimaschutz. Mit dem greenprint*-Label auf Ihren Druckprodukten. http://www.greenprint.at

1 0

adressprüfung bei der antwort, feature request
by it-news (Josef Lahmer) 16 May '08

16 May '08

hallo liste, hab einen wunsch/feature request: automatische adressbuch bzw emailadressenprüfung bei der antwort (wenn ich noch zusätzliche empfänger ins cc nehmen möchte) (also wenn ich emailadress nicht vollständig oder korrekt eingebe wird im adressbuch nach einer übereinstimmung gesucht. wer findet so ein feature für sinnvoll? lg josy --------------------------------------- 400 Tonnen! Diese Menge an CO2 haben unsere Kunden bis heute durch klimaneutrales Drucken ausgeglichen. Zeigen auch Sie Ihr Engagement in Sachen Klimaschutz. Mit dem greenprint*-Label auf Ihren Druckprodukten. http://www.greenprint.at

1 0

rechtschreibkorrektur aspell dictonary erweitern
by it-news (Josef Lahmer) 16 May '08

16 May '08

hallo liste, hat jemand schon erfahrung mit der rechtschreibkorrektur? ich hab aspell installiert und im otrs aktiviert. wie kann ich schlüsselwörter ins wörterbuch mitaufnehmen bzw weitere sprachen festlegen? (eventuell Framework -> Core::SpellChecker ausnahmen definieren) => aber schöner wäre es fast über aspell direkt? hat jemand ideen? lg josy --------------------------------------- 400 Tonnen! Diese Menge an CO2 haben unsere Kunden bis heute durch klimaneutrales Drucken ausgeglichen. Zeigen auch Sie Ihr Engagement in Sachen Klimaschutz. Mit dem greenprint*-Label auf Ihren Druckprodukten. http://www.greenprint.at

1 0