-
AutorBeiträge
-
-
26. März 2021 um 13:15 Uhr - Views: 662 #11264
Hallo,
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.
Hat jemand einen Rat?
Danke und Schöne Grüße
Matthias
-
6. April 2021 um 18:29 Uhr #11302
Anonym
Seid ihr hier weiter gekommen? Bei meinem Migrationsversuch passierte genau das Gleiche und ich bin auf der Suche nach einer Lösung. ;-)
-
6. April 2021 um 21:22 Uhr #11306
Hallo Matthias, hallo Jens,
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.
Viele Grüße, Sven
-
7. April 2021 um 9:55 Uhr #11312
Anonym
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.
-
-
6. April 2021 um 23:58 Uhr #11308
Anonym
Meine
Kernel/Config.pm
ist vergleichsweise leer. Da stehen die DB-Einstellungen und das Home drin und das wars. Wenn ich in dieKernel/Config/Defaults.pm
schaue, sind da wesentlich mehr Einstellungen getroffen. Kann es sein, dass hier einfach Einstellungen fehlen? -
7. April 2021 um 8:17 Uhr #11310
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.)
Viele Grüße, Sven
-
23. April 2021 um 13:54 Uhr #11415
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.
Nachvollziehbar war das aber nicht …
-
30. Mai 2021 um 11:33 Uhr #11508
Aktuell gehe ich davon aus, dass es sich um ein Caching Problem gehandelt hat.
-
-
AutorBeiträge
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.