---

hi,

im zuge einer trennung einer datenbank in zwei (firmentrennung) habe ich das problem, viele user aus verschiedensten gruppen in der jeweiligen db zu entfernen. die user haben auch daten in den jeweiligen gruppen erzeugt.
der händische weg (inaktiv setzen bzw. user aus gruppe entfernen) dauert einfach zu lange - wir haben ca. 200 user. wir arbeiten mit hierarchischen gruppen (z.b. gruppe projekt.viewer).

gibt es da irgendwo in der weiten welt ein utility, das mir weiterhilft?

------------------
Gruß aus Hamburg

Yeti

It's nice to be important, but it's more important to be nice! (Scooter in "Move Your Ass")

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Mit dem Entfernen sei vorsichtig!
a) Für vorhandene Objekte muss der Besitz übertragen werden.
Das kann lange dauern.
b) Sobald der Benutzer als Prüfer an einem Workflow teilgenommen hat, ist es NICHT MÖGLICH, ihn zu löschen.
( Es sei denn, Du löscht zuerst alle betroffenen Prozesse...)

Du musst ja nicht durch einzelne Gruppen gehen.
Es genügt völlig, den Benutzerstatus (insgesamt) zu deaktivieren.

Mal angenommen, Du wolltest die Hälfte von 200 Usern deaktivieren
und hast eine alphabetisch sortierte Liste - das sollte maximal 2 Stunden Arbeit bedeuten.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hi schulze,

a) das mit dem entfernen ist nicht so tragisch - da gibt es ein plm-easy-tool (change_ownership), das da sehr unterstützend ist. und das auf irgendeinem rechner vor sich hin juckeln kann (und auch schneller, als tce-standard ist)...
b) keine workflows im einsatz, lediglich status.

aus jetziger erkenntnis machbar ist das inaktiv setzen in der jeweiligen gruppe - da kann er zumindest keine daten in der falschen db mehr erzeugen.
die liste wäre hilfreich, wenn jeder user nur in standardgruppen wäre. aber: durch hierarchische gruppen sind anwender manchmal innerhalb eines projektes in mehreren gruppen und manchmal sogar noch unterschiedlichen rollen. 
also kuddelmuddel, der jetzt einfach aufgeräumt werden muß. ich muß nur sicherstellen, das der jeweilige anwender nur in der richtigen db anmelden bzw. daten erzeugen darf. da die beiden db's am tag X natürlich vollständig identisch sind und sich erst dann auseinanderdriften.

------------------
Gruß aus Hamburg

Yeti

It's nice to be important, but it's more important to be nice! (Scooter in "Move Your Ass")

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP