wir haben eine Testmigration von OTRS 6 nach OTOBO 10 (Apache nicht Docker) durchgeführt. Die Migration hat verhältnismäßig lange gedauert (knapp 10h), lief aber schlussendlich doch durch.
Nach der Migration konnten sich die User zwar am System per LDAP anmelden, allerdings fehlen die bisherigen Gruppen- und Rollenzuordnungen aus dem alten OTRS. Somit sehen diese auch keine Tickets.
Kurze Zusammenfassung:
Im Adminmenü Benutzer, Gruppen & Rollen
Agenten: In der Action=AdminUser werden alle User angezeigt, in der Subaction=Change;UserID= wird unter Gruppenberechtigungen Dieser Agent besitzt keine Gruppenberechtigungen. angezeigt
Agenten<->Gruppen: In der Action=AdminUserGroup werden die Agenten aufgelistet, allerdings gibt es nur drei Standardgruppen (admin,stats,users). Die restlichen Gruppen fehlen. In der Action=AdminUserGroup;Subaction=User;ID= werden auch keine Haken angezeigt (Zumindest user hatte jeder Benutzer)
Agenten<->Rollen: In der Action=AdminRoleUser werden alle User und die alten Rollen angezeigt. In der Action=AdminRoleUser;Subaction=User;ID= stehen die Gruppen auch drin, allerdings fehlt wieder die Zuordnung zum User (nichts angehakt)
Auf Datenbankebene sind in den Tabellen users, role_user, group_user, groups_table keine wirkliche Auffälligkeiten im Vergleich zu OTRS zu sehen.
prinzipiell funktioniert das. Eine Idee ist, dass eure Gruppen im LDAP vielleicht soetwas wie ‚OTRS_ADMIN‘ o.ä. heißen (das wäre im Mapping in der Kernel/Config.pm definiert). Wir nennen als Teil der Migration an verschiedenen Stellen otrs nach otobo um. Das ist noch nicht zu 100% so, dass es immer alles richtig macht, und grad bei der Stelle würde es im Moment noch zu viel erwischen, glaube ich, und dann steht bei euch in der Config u.U. z.B. ‚OTOBO_ADMIN‘, und das ganze passt nicht mehr.
Nicht sicher der Grund, aber vielleicht guckt ihr mal nach.
Wo würde man die Einstellung OTRS_ADMIN bzw. OTOBO_ADMIN denn finden oder setzen? Ich habe durch die alte OTRS-Installation gegreppt und auch OTOBO durchsucht. In beiden fand ich nichts dazu.
Meine Kernel/Config.pm ist vergleichsweise leer. Da stehen die DB-Einstellungen und das Home drin und das wars. Wenn ich in die Kernel/Config/Defaults.pm schaue, sind da wesentlich mehr Einstellungen getroffen. Kann es sein, dass hier einfach Einstellungen fehlen?
Die Defaults.pm gehört eigentlich nicht angepasst und wird nicht migriert. Die Einstellungen sollten da rauskopiert und dann in der Config.pm eingetragen und angepasst werden. Die überschreiben dann die Defaults.pm. Das müssten Sie dann händisch nachholen. (Ich rate dazu die Sachen von nun an in die Config.pm zu schreiben, so ist das erwartete Vorgehen.)
Also die hart überschriebenen Änderungen in den Configs habe ich soweit „zurück korrigiert“. Interessanterweise hat es anfangs nicht funktioniert. Nach ein paar Tagen bin ich per Zufall nochmals auf das System drauf und habe meine Tickets gesehen. Evtl. lief da ein Sync gegen LDAP oder so der das behoben hat.