Topic Resolution: Resolved
Ansicht von 14 Antwort-Themen
  • Autor
    Beiträge
    • #12047
      Jan Eckhardt
      Teilnehmer

        Guten Tag,

        ich habe ein Problem mit dem OTOBO System.

        Nachdem ich mein OTRS 6 System nach OTOBO einwandfrei migrieren konnte, haben in den letzten Tests die eintreffenden Tickets nicht erstellt werden können. Der Versand funktionierte mit dem Daemon / Cron Job oder einem erzwungenen TicketSend Befehl via Konsole.

        Mein Problem:
        Eintreffende Tickets erscheinen nicht – und unter dem “Communication Log” bekomme ich folgende Aussage:

         

        Die von OTOBO angegebene Bug-Reporting Seite existiert nicht mehr (404).

        Mein OTOBO: 10.0.13, Ubuntu 20, MariaDB
        Mein altes ORTS: OTRS 6.0.30, CentOS 7, MariaDB

      • #12049
        Stefan Rother
        Administrator

          Guten Morgen Herr Eckhardt,

          dieses Verhalten ist absolut unüblich und ich denke auf den ersten Blick, dass es sich nicht um einen Bug handelt, sondern um ein Konfigurationsproblem oder um einen Bug in einem Zusatzpaket (Welche Pakete sind bei Ihnen installiert?)

          Bitte öffnen sie eine Konsole und pipen Sie eine gespeicherte Nachricht die nicht importiert werden konnte nochmal ins System:

          root> su - otobo

          otobo> /opt/otobo/var/spool/problem-email-irgendeine | bin/otobo.Console.pl Maint::PostMaster::Read

          Anschließend posten Sie hier bitte nochmal den Fehler und die gesamte Ausgabe.

          Die OTOBO Bugs finden Sie nun unter https://github.com/RotherOSS/otobo/issues, gibt es irgendwo noch einen veralteten Link den wir anpassen müssen?

          Vielen Dank,

          Stefan

          Team OTOBO

           

        • #12050
          Jan Eckhardt
          Teilnehmer

            Hallo Herr Rother,

            hier ist der Report, den ich aus der Konsole auslesen konnte.

             

            Ansonsten konnte ich keine weiteren Links finden, die ins Leere gehen.
            Ich habe keine Addons installiert, wie es bei OTRS6 der Fall war (Znuny QuickClose + Repo)

            Des Weiteren ist dies die liste per Ausgage durch: bin/otobo.CheckModules.pl –all

             

            Ich bedanke mich noch einmal für die schnelle Antwort!

             

            Gruß

            Jan

            • #12055
              Sven Oesterling
              Administrator

                Bei dem Console-Befehl steht ein “permission denied” – da müssten Sie erstmal überprüfen, wie die Rechte genau gesetzt sind, bitte.

            • #12052
              Renée Bäcker
              Teilnehmer

                Ist im Systemprotokoll noch etwas zu finden, *warum* die Tickets nicht erstellt werden?

                 

                @Stefan: Hier ist der Link zu finden: https://github.com/RotherOSS/otobo/blob/79b86ace5c3fa6bdaf949bcf371cc23f5443c0a1/Kernel/System/PostMaster/NewTicket.pm#L600

              • #12054
                Jan Eckhardt
                Teilnehmer

                  Hallo Renèe,

                  in welchem Systemprotokoll kann ich denn nachgucken für die Informationen, die du gerne haben möchtest?

                  Unter “System Log” habe ich noch das hier, was essenziell ähnlich zu dem Report von oben ist.

                  Die Message ist CommunicationLog(ID:12,AccountType:-,AccountID:-,Direction:Incoming,Transport:Email,ObjectLogType:Connection,ObjectLogID:33)::Kernel::System::Console::Command::Maint::PostMaster::Read => Got no email on STDIN!

                   

                  Gruß

                  Jan

                • #12058
                  Renée Bäcker
                  Teilnehmer

                    Hallo Jan,

                    das ist prinzipiell die richtige Stelle an der Du schauen solltest. Aber erstmal musst Du das “permission denied”-Problem beheben.

                  • #12059
                    Jan Eckhardt
                    Teilnehmer

                      Ich bin mir leider nicht sicher, wie ich das “Permission Denied” Problem beheben kann.
                      Die Unterordner und auch die Spool Mails sind mit den Rechten eigentlich richtig vergeben, oder nicht?

                    • #12060
                      Renée Bäcker
                      Teilnehmer

                        setz mal noch ein “cat ” vor die Mail, also

                        cat /opt/otobo/var/spool/mail-…. | perl bin/otobo.Console.pl Maint::PostMaster::Read

                      • #12061
                        Jan Eckhardt
                        Teilnehmer

                          Das kommt dabei heraus!

                           

                        • #12062
                          Renée Bäcker
                          Teilnehmer

                            Die Spalte ‘ticket_answered’ die da angemeckert wird gibt es originär in der Tabelle ticket nicht. Hattest Du irgendwelche Anpassungen im OTRS? Vielleicht nicht über Addons sondern über eigene Änderungen direkt in irgendwelchen Dateien?

                          • #12063
                            Jan Eckhardt
                            Teilnehmer

                              Ich kann das nicht wirklich nachvollziehen.

                              Ich habe das damalige OTRS nicht aufgesetzt, jedoch die komplette Migration von 3.36 auf 6.0.30 getätigt und überwacht.
                              Was für Anpassungen alles gemacht wurden davor, kann ich nicht ganz in Erfahrung bringen.

                              Letztlich ist dann wohl ein Eintrag in der MySQL / Datenbank kaputt.
                              Ich weiß, dass wir in der Vergangenheit Probleme mit Anhängen von Datenbanksätzen aus 2014 hatten, bspw. Dort haben einfach Inhalte irgendwann gefehlt scheinbar.

                              Was könnte man nun tun? Gibt es eine Möglichkeit die SQL Einträge nachzuholen oder wieder aufzubauen?
                              Nach meines Erachtens wurde die damalige OTRS-Lösung nach Dokumentation aufgebaut. Leider bin ich gezwungen diese uralte Datenbank immer wieder mitzuziehen. Zumindest gab es keine Probleme diesbezüglich von OTRS 5.0.42 auf OTRS 6.0.30, was der letzte Schritt ja war, bevor ich zu OTOBO wechseln könnte. Nun verbleiben wir auf dem funktionsfähigen OTRS 6 für den Moment, bis OTOBO vielleicht doch bei uns noch laufen könnte.

                            • #12064
                              Renée Bäcker
                              Teilnehmer

                                Du könntest in der Datenbank einfach einen Default setzen.

                                Schau Dir mal mit

                                DESCRIBE ticket

                                die Tabelle an. Dann könntest Du mit

                                ALTER TABLE ticket MODIFY ticket_answered … DEFAULT 0;

                                einen Standardwert setzen. Das “…” musst Du durch die Spaltendefinition (bsp. “NOT NULL INTEGER”, deswegen erst das DESCRIBE) ersetzen. Löschen würde ich die Spalte nicht, da die ja vermutlich mal eine Funktion hatte.

                                Du solltest mal in dem /opt/otrs/-Verzeichnist (auf dem OTRS 6) einfach mal ein

                                grep -r ticket_answered /opt/otrs/Kernel/*

                                und

                                grep -r ticket_answered /opt/otrs/Custom/*

                                machen. Vielleicht findest Du dann heraus wo das herkommt und welche Funktion das hat. Vielleicht wird die Spalte auch in GenericAgents o.ä. verwendet.

                              • #12067
                                Jan Eckhardt
                                Teilnehmer

                                  So, ich habe jetzt mit:

                                  ALTER TABLE ticket ALTER COLUMN ticket_answered SET DEFAULT 0;

                                  einen Default value gesetzt.
                                  Nachdem ich ein Test-Ticket reingeschickt und manuell ge-fetched habe im Adminbreich.

                                  Nun sagt das Communication Log immer noch, dass das Ticket nicht erstellt werden kann, …

                                  allerdings sagt das Error log jetzt NICHT mehr, dass ticket_answered auf einen Fehler läuft, sondern Folgendes:

                                • #12068
                                  Jan Eckhardt
                                  Teilnehmer

                                    Das hier ist noch einmal die Einsicht in das
                                    DESCRIBE ticket;

                                    bezüglich der “ticket_answered” Sache von oben, das sich jetzt wohl gefixt hat.

                                  • #12069
                                    Jan Eckhardt
                                    Teilnehmer

                                      Ich habe dasselbe ebenfalls mit “group_id” gemacht, dass ich den Default Wert auf 0 gesetzt habe, denn meine Error Logs spuckten ab jetzt “group_id” aus und nicht mehr “ticket_answered”.
                                      Als ich das tat, klappte plötzlich alles wieder!

                                       

                                      Ich bedanke mich für alle Hilfe soweit!

                                       

                                      [SOLVED]

                                  Ansicht von 14 Antwort-Themen
                                  • Du musst angemeldet sein, um auf dieses Thema antworten zu können.