Hallo Rene, hab ich gemacht.
Die Log-Files schicke ich dir separat, nicht hier über die Liste. Gruß Peter Am 10.02.2011 14:13, schrieb Rene Böhm: > Hi Peter, > > sofern es kein Produktivsystem ist, setze mal bitte ein > > use Data::Dumper; > print STDERR Dumper(\%Param); > > in die Funktion TicketSearch in Kernel/System/Ticket.pm, unterhalb der > Zeile > > my ( $Self, %Param ) = @_; > > Dann schauen wir mal, was an Suchparametern übergeben wird. Die Ausgabe > des Ganzen steht dann im Apache error.log. > > Viele Grüße > Rene > > > On 02/10/2011 01:51 PM, Peter Wohlers wrote: >> Hallo Rene. >> >> Am 10.02.2011 12:30, schrieb Rene Böhm: >>> Hi Peter, >>> >>> ok, dann war's in deinem Fall leider nicht dieser Punkt. >>> >>> Die SQL-Anweisung wird Schritt für Schritt anhand der Suchkriterien >>> aufgebaut. Den einzelnen "Abschnitten" ist ein möglicher Widerspruch zu >>> späteren Einschränkungen dabei egal. Die Status 14 und 6 kommen von >> >> Hm, >> >> AND st.ticket_state_id IN (6) >> AND st.ticket_state_id IN (14) >> >> ergibt aber was anderes als >> >> AND st.ticket_state_id IN (14, 6) >> >> Wenn in der Abfrage 2-mal nach dem gleichen Feld gefragt wird, aber mit >> unterschiedlichen Werten und beide mit "AND" verknüpft, dann kann es >> doch keine Ergebnis geben. >> >>> einer separaten Behandlung, falls zur Ermittlung der Wartezeiten gesucht >>> wird. >>> >>> Man müsste wissen welche Suchkriterien tatsächlich an TicketSearch >>> übergeben werden, um den Aufbau des SQL-Statements nachzuvollziehen. >>> >>> Gibt es eine bestimmte Aktion die du ausführst, woraufhin der Fehler im >>> Log erscheint ? >> >> Nein, die Meldung taucht schon beim Aufruf des Dashboards auf sowie auch >> bei anderen Unterseiten. >> >> Vielleicht hängt es mit den kleinen "Icons" oben rechts über dem Menü >> zusammen, da werden ja u. a. auch die gesperrten Tickets gezählt. >> >> Gruß >> Peter >> >>> >>> Viele Grüße >>> Rene Böhm >>> >>> >>> On 02/10/2011 12:12 PM, Peter Wohlers wrote: >>>> Hallo Rene, >>>> >>>> das Plugin war schon deaktiviert. Habe es mal aktiviert und wieder >>>> abgeschaltet, keine Besserung. >>>> >>>> Ist aber glaube ich, die falsche Richtung, in der du suchst. >>>> >>>> Die beiedn Status, nach denen er sucht (14, 6) sind beide vom Typ >>>> "pending auto". Wenn jetzt noch nach weiteren Stati gesucht wird, dann >>>> würden sich die beiden Bedingungen im SQL-Statement ja widersprechen und >>>> das Ergebnis wäre immer leer. Kann ja eigentlich nicht Sinn der Abfrage >>>> sein, denn dann wäre sie ja nicht mehr als eine performance-Bremse ;) >>>> >>>> Gruß >>>> Peter >>>> >>>> Am 10.02.2011 11:55, schrieb Rene Böhm: >>>>> Hi Peter, >>>>> >>>>> OTRS geht leider beim Aufbau der Ticketsuche immer davon aus, dass es >>>>> mind. einen Status von einen bestimmten Typ gibt, nach dem gesucht wird. >>>>> Gibt es keinen erfolgt an der entsprechenden Stelle leider keine saubere >>>>> Behandlung und es wird eine leere Liste zum Aufbau des SQL-Statements >>>>> verwendet. >>>>> >>>>> Der Fehler wird u.a. durch das Dashboard-Plugin "TicketPendingReminder" >>>>> verursacht. Einfach das Modul über den SysConfig-Schlüssel >>>>> "DashboardBackend###0100-TicketPendingReminder" deaktivieren. Wenn du >>>>> keine "pending reminder"-Status im System hast, nützt dir das Plugin >>>>> auch nicht viel. >>>>> >>>>> Viele Grüße >>>>> Rene >>>>> >>>>> >>>>> On 02/10/2011 11:31 AM, Peter Wohlers wrote: >>>>>> Hallo, >>>>>> >>>>>> einen Status mit Typ "pending reminder" habe ich nicht im System. >>>>>> >>>>>> Gruß >>>>>> Peter >>>>>> >>>>>> Am 10.02.2011 11:22, schrieb Rene Böhm: >>>>>>> Hallo, >>>>>>> >>>>>>> bitte überprüfe mal, ob es noch valide(!) Ticketstatus vom Statustyp >>>>>>> "pending reminder" gibt. Das könnte die Ursache sein. >>>>>>> >>>>>>> Viele Grüße >>>>>>> Rene >>>>>>> >>>>>>> >>>>>>> On 02/10/2011 10:42 AM, Peter Wohlers wrote: >>>>>>>> Hallo allerseits, >>>>>>>> >>>>>>>> ich erhalte massig diese Fehlermeldung im Log: >>>>>>>> >>>>>>>> Message: You have an error in your SQL syntax; check the manual that >>>>>>>> corresponds to your MySQL server version for the right syntax to use >>>>>>>> near ') AND st.ticket_lock_id IN (2) AND st.user_id IN (2) AND >>>>>>>> st.ticket_state_id IN ' at line 1, SQL: 'SELECT DISTINCT count(*) FROM >>>>>>>> ticket st, queue sq WHERE sq.id = st.queue_id AND st.ticket_state_id >>>>>>>> IN >>>>>>>> ( ) AND st.ticket_lock_id IN (2) AND st.user_id IN (2) AND >>>>>>>> st.ticket_state_id IN (14, 6) AND st.until_time <= 1297328162 LIMIT >>>>>>>> 10000' >>>>>>>> >>>>>>>> Hier die Abfrage alleine: >>>>>>>> >>>>>>>> 'SELECT DISTINCT count(*) FROM ticket st, queue sq >>>>>>>> WHERE sq.id = st.queue_id >>>>>>>> AND st.ticket_state_id IN ( ) >>>>>>>> AND st.ticket_lock_id IN (2) >>>>>>>> AND st.user_id IN (2) >>>>>>>> AND st.ticket_state_id IN (14, 6) >>>>>>>> AND st.until_time <= 1297328162 LIMIT 10000' >>>>>>>> >>>>>>>> Beim genaueren Nachforschen, soll diese Abfrage die Anzahl der >>>>>>>> gesperrten Tickets "st.ticket_lock_id IN (2)" des aktuellen Benutzers >>>>>>>> "st.user_id IN (2)", die sich in einem "Warten-Status" befinden >>>>>>>> "st.ticket_state_id IN (14, 6)" und deren "Warten bis" Zeitpunkt >>>>>>>> überschritten ist "st.until_time <= 1297328162" (ist der aktuelle >>>>>>>> Zeitpunkt, an dem die Abfrage gestellt wurde) addieren (und damit wohl >>>>>>>> etwas machen). >>>>>>>> >>>>>>>> Interessant ist, dass "AND st.ticket_state_id IN ( )" 2-mal in der >>>>>>>> Abfrage steht, einmal mit Werten und einmal ohne Werte?!? lösche ich >>>>>>>> das, geht die Abfrage problemlos durch. >>>>>>>> >>>>>>>> Ist das evtl. ein Fehler im Programm? Habe dazu nichts passendes auf >>>>>>>> http://bugs.otrs.org finden können. >>>>>>>> >>>>>>>> Oder muss ich da was anpassen? >>>>>>>> >>>>>>>> Aktuell mit OTRS 3.0.5, upgedatet von 2.4.7 >>>>>>>> >>>>>>>> Gruß >>>>>>>> Peter --------------------------------------------------------------------- OTRS mailing list: otrs-de - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs-de To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de
