** 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
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
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
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
Subject: [otrs-de] Zugriffsrechte auf Firmentickets
To:
Message-ID:
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
Subject: [otrs-de] Zugriffsrechte auf Firmentickets
To:
Message-ID:
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
*****************************************************
