I’m trying to locate where the hangup is with regard to the tickets.
I can see them under my OTRSv6 dashboard, but they’re blank under OTOBO.
I have these:
[Wed Feb 10 20:30:34.250263 2021] [mpm_prefork:notice] [pid 2406121] AH00169: caught SIGTERM, shutting down
[Wed Feb 10 20:30:35.073474 2021] [mpm_prefork:notice] [pid 2416610] AH00163: Apache/2.4.41 (Ubuntu) mod_perl/2.0.11 Perl/v5.30.0 configured — resuming normal operations
[Wed Feb 10 20:30:35.073582 2021] [core:notice] [pid 2416610] AH00094: Command line: ‚/usr/sbin/apache2‘
[Wed Feb 10 20:32:19 2021] -e: Use of uninitialized value within %Queues in hash element at /opt/otobo/Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm line 171.
[Wed Feb 10 20:32:19 2021] -e: Use of uninitialized value within %Queues in hash element at /opt/otobo/Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm line 171.
[Wed Feb 10 20:32:19 2021] -e: Use of uninitialized value within %Queues in hash element at /opt/otobo/Kernel/Output/HTML/Dashboard/TicketQueueOverview.pm line 171.
But syslog and journalctl -r doesn’t show anything.
I can’t connect to the admin portal, but reverting to OTRS v6 I can.
When I try the admin portal in Otobo, I get kicked out and permission denied.
The error above the webservices could lead to some trouble. Invalid sysconfig settings have to be resolved by hand (and it’s better done before migration). But I’m not 100% sure that it won’t work, just from the logs. As mentioned in the other post, you should be able to just restart the migration where you left, after replacing the file.
(If you run into errors regarding the Sysconfig, please try /opt/otrs/bin/otrs.Console.pl Admin::Config::ListInvalid on the source system. You can try fixing things on the otobo side, later, too – for me this worked in more than one cases, but I’m not sure about docker e.g.)
Hello, I just finished doing a migration of a system with about 65000 tickets and I get the exact same issue. Everything seems to be there but not permissions are applied.
I migrated from latest OTRS 6 to OTOBO 10.1 latest. I fixed all invalid configs and stuff early during first migration attempt.
Should I migrate to OTOBO 10.0 and the to OTOBO 10.1? Is it ok to migrate directly to 10.1?
In fact I did follow the instructions several times until I got a successfull migration message, but it had what I described.
Afterwards I decided to go back and install 10.0 first and did the migration to that version firs, it indeed went a little bit smooth, but at the end, even though I can see all the roles, the data, the menus, still don’t have the groups, so what you said makes sense, I will redo the process again hopefully this afternoon and find out where the error is.
I can look into the database and all is there, the groups, the roles, the queues, the role_groups table, but it just can’t be seen in the interface.
I’ll let you guys know if I identify where the issue is.
In regards of what Stephan mentioned we reviewed the list of tables and found that in fact the groups_table existed and had all the new groups, but the ones coming from otrs where not inserted into this one, instead, the groups table from otrs was kept.
So we moved all the contents from groups into groups_table and it seems to be ok now.
Question? Should there be something into the migration script that merges those tables instead of keeping the old one?
Autor
Beiträge
Ansicht von 7 Antwort-Themen
Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Wir verwenden Cookies, um diese Website optimal gestalten und laufend verbessern zu können. Für Analyse und Statistik nutzen wir Google Analytics (anonymisiert).
Unsere Website verwendet Cookies. Cookies sind kleine Textdateien, die beim Aufruf von Websites im Internetbrowser bzw. vom Internetbrowser auf Ihrem Endgerät gespeichert werden. Diese Cookies enthalten eine charakteristische Zeichenfolge, die eine eindeutige Identifizierung des Browsers beim erneuten Aufrufen der Website ermöglichen.
Sie können das Setzen von Cookies jederzeit über eine entsprechende Einstellung in Ihrem Internetbrowser verhindern. Bereits gesetzte Cookies können jederzeit manuell oder automatisiert gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Wird das Setzen von Cookies im Browser deaktiviert, sind unter Umständen nicht alle Funktionen der Website vollumfänglich nutzbar.
Wir gehen grundsätzlich sehr sparsam mit Cookies um.
Detaillierte Informationen finden Sie in Abschnitt 4 unserer Hinweise zum Datenschutz.
Technisch erforderliche Cookies
Diese Cookies sind erforderlich, um die Darstellung dieser Website und einiger ihrer Features zu gewährleisten.
Deshalb bieten wir hier auch keine Möglichkeit an, diese Cookies zu deaktivieren.
Dessen ungeachtet können Sie jederzeit durch entsprechende Einstellungen in Ihrem Browser alle Cookies deaktivieren. Unter Umständen stehen Ihnen dann nicht mehr alle Funktionalitäten dieser Website zur Verfügung.
Weitere Informationen zu den gesetzten Cookies und zur Speicherdauer finden Sie in Abschnitt 4 unserer Hinweise zum Datenschutz.
Cookies von Google Analytics
Beim Besuch der Website werden Cookies von Google Analytics gesetzt, die eine Analyse der Benutzung unserer Website durch Sie ermöglichen. Ihre IP-Adresse wird dabei durch technische Vorkehrungen pseudonymisiert (IP-Anonymisierung und Deaktivierung der User-ID). Eine Zuordnung der Daten zum aufrufenden Nutzer ist daher nicht mehr möglich. Die Daten werden nicht gemeinsam mit anderen personenbezogenen Daten der Nutzer gespeichert.
Wenn Sie nicht möchten, dass wir Ihren Besuch auf unserer Website verfolgen, können Sie das Tracking in Ihrem Browser hier deaktivieren:
Hinweise zum Datenschutz
Detaillierte Informationen zum Einsatz von Cookies sowie unsere Datenschutzerklärung finden Sie hier: