** 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@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@otrs.org Sie koennen den Listenverwalter dieser Liste unter der Adresse otrs-de-owner@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@fotofinder.com> Subject: [otrs-de] Performance Kalender To: otrs-de@otrs.org Message-ID: <482D7389.7010800@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@fotofinder.com> Subject: [otrs-de] Performance Kalender To: otrs-de-request@otrs.org Message-ID: <482D59B7.7050906@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@fotofinder.com> Subject: [otrs-de] Performance Kalender To: otrs-de-request@otrs.org Message-ID: <482D59B7.7050906@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@eurodok.de> Subject: [otrs-de] Zugriffsrechte auf Firmentickets To: <otrs-de@otrs.org> Message-ID: <D1DF6BEF7FBA1847BD36F45B6451EB3A0AE24B@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@eurodok.de> Subject: [otrs-de] Zugriffsrechte auf Firmentickets To: <otrs-de@otrs.org> Message-ID: <D1DF6BEF7FBA1847BD36F45B6451EB3A0AE24C@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@otrs.org http://lists.otrs.org/mailman/listinfo/otrs-de Ende otrs-de Nachrichtensammlung, Band 55, Eintrag 16 *****************************************************