Zu 1:
Offene Frage: müssen wir das auch machen können? (falls der Kunde das nicht selber machen möchte?)
Grundsätzlich sollten wir folgendes im Hinterkopf behalten:
Zu einen sollten wir die Software so denken, dass wir sie als Full-Service Agentur betreuen können. Das bedeutet aber nicht, dass solche Aufgaben nur mit Adminrechten Ausgeführt werden. Beispiel: Unser “King of Kink” möchte Nutzer moderieren, oder bestimmte CRUD Befehle auf diese ausführen.
Am besten wir machen folgendes:
Nutzerstruktur
- 1 Nutzer hat n parents
- 1 Nutzer hat n childs
- 1 Nutzer gehört zu 1:n gruppen
Nutzer hat alle CRUD rechte über alle kinder und kindeskinder
Gruppenstruktur
Zudem ist es glaube ich für den Unternehmenskontext zusätzlich noch sinnvoll Gruppen zu definiere:
- 1 Gruppe hat n subgruppen
- 1 Gruppe hat n übergruppen
- 1 Gruppe hat n Mitglieder
- 1 Gruppe hat n Owner
Owner können CRUD auf alle Gruppen und Mitglieder der eigenen und der Subgruppen ausführen.
Zu 2:
Nutzername sollte durch Team Owner definierbar, oder frei wählbar sein. Ggf. haben Unternehmen policies wie sie die Nutzernamen definieren.
Ich denke folgendes ist sinnvoll:
- Einladungslink wird via Email versenden
- Einladungslink wird zudem als url und mit QR code angezeigt → Dann können nämlich Team Leads direkt den Account mit den Mitarbeitern zusammen anlegen sollten sie im Office sein.
Bzgl: Mitarbeiter registrieren sich selber
Ich würde semantisch alles als Nutzer und nicht als Mitarbeiter im Hinterkopf behalten. Der Grund dafür ist:
Wir werden die Software als SaaS für Communities z.B. “Jamies Kinkkingdom” anbieten. In diesem Fall ist haben wir unseren King of King 
(Alle Nutzer leiten sich von ihm ab, er ist Gott 
) und seine Kronprinzen (sind direkte Kinkkingkinder). Der King kann alle moderieren und die Kronprinzen nur die Leibeigenen die Ihnen unterstehen. Die Kinder der Kronprinzen haben wiederum die Herrschaft über alle Ihre Kinder… Du erkennst die Idee 
Zusätzlich haben wir die Gruppen die selbst verwaltet sind. Unterliegen natürlich trotzdem dem feudalistischen Herrschaftssystem und sind von Kinkies gnaden, haben aber auch eine eigene Selbstverwaltung (Gruppen Owner) die entscheiden wer Mitglied ist und wer nicht.
Mit dem Modell können wir ziemlich gut Herrschafts- und Hierarchiestrukturen in Firmen aber auch in Communities abbilden. Da hat sich das MEW 21 Studium gelohnt.
Ich weiß aber noch nicht in wie weit das schon in LDAP implementiert ist und wie weit du das im SaaSy implementieren musst. Bin da noch in der Recherche. Siehe auch CyMaIS LDAP Implementierung Documentation
PS:
Um die Frage metaphorisch zu beantworten:
- Leibeigene Registrieren sich selbst mit Double Opt In
- Leibeigene Registrieren sich selbst mit Single Opt In
- Leibeigene Registrieren sich, der König muss aber zustimmen
- Der König läd neue Leibeigene in sein reich ein, diese müssen aber zustimmen
Also vier Modi:
- Single Opt In
- Double Opt In
- Freigabe erforderlich
Am besten ist es wenn die Gruppenowner leute einladen und die anfragen von Mitgliedern die sie, oder ein Co-Owner zu ihrer Gruppe eingeladen hat moderieren können. Also Gruppenowner haben immer alle CRUD Rechte auf die Eigene und Subgruppen und die entsprechende Moderation.