In HCL Connections gibt es die Möglichkeit, externe Personen, wie Lieferanten, Kunden, Partner und Projektmitarbeiter außerhalb der eignen Organisation als externe Benutzer zuzulassen, damit man in entsprechend angelegten Communities effizient zusammen arbeiten kann.

Ein Weg dazu führt über ein weiteres Benutzerverzeichnis, dass zum Beispiel über eine Directory Assistance-Konfiguration einem Domino-LDAP-Server bekannt gemacht wird. In den TDI-Skripten, die für die Benutzer im LDAP-Verzeichnis Datensätze in der Profil-Datenbank erstellt, gibt es die Möglichkeit, die "ist extern"-Eigenschaft mit einer JavaScript-Funktion berechnen zu lassen.

Wenn dabei ein Fehler passiert oder aus einem anderen Grund eine Person ohne Änderung der E-Mail-Adresse seinen "Externen"-Status verlieren soll, geht es leider nicht mehr ganz so einfach (ich lasse mir gerne das Gegenteil beweisen!). Man muss dann regelmäßig sogar in mehreren Datenbanken und Tabellen Änderungen vornehmen. Die wichtigste Datenbank ist dabei die PEOPLEDB.

Einmal kurz vorweg: Wie finde ich die Details zu einer Person in der EMPINST.EMPLOYEE-Datenbank?

-- PEOPLEDB
select PROF_KEY, PROF_DISPLAY_NAME, PROF_SOURCE_UID, PROF_UID, PROF_STATE, PROF_MODE from EMPINST.EMPLOYEE where PROF_KEY = 'd402d37f-75ed-4d62-b3dd-31ece7d8d4e0';
select PROF_KEY, PROF_DISPLAY_NAME, PROF_SOURCE_UID, PROF_UID, PROF_STATE, PROF_MODE from EMPINST.EMPLOYEE where PROF_DISPLAY_NAME = 'Rainer Zufall';
select PROF_KEY, PROF_DISPLAY_NAME, PROF_SOURCE_UID, PROF_UID, PROF_STATE, PROF_MODE from EMPINST.EMPLOYEE where PROF_UID = 'RZufall';

Dabei kann man die ID des Benutzers z. B. in einigen Protokollen finden. Über die Abfrage oben erfährt man dann auch, um wen es sich dabei eigentlich handelt.

In der PEOPLEDB muss man 4 Tabellen anpassen

-- PEOPLEDB
-- PROF_MODE=0|1 (0 = internal, 1 = external)
-- ROLE_ID='visitor'|'employee'|'employee.extended'
update EMPINST.EMPLOYEE		set PROF_MODE = 0					where PROF_KEY = (select PROF_KEY from EMPINST.EMPLOYEE where PROF_DISPLAY_NAME = 'Rainer Zufall');
update EMPINST.SURNAME		set PROF_MODE = 0					where PROF_KEY = (select PROF_KEY from EMPINST.EMPLOYEE where PROF_DISPLAY_NAME = 'Rainer Zufall');
update EMPINST.GIVEN_NAME	set PROF_MODE = 0					where PROF_KEY = (select PROF_KEY from EMPINST.EMPLOYEE where PROF_DISPLAY_NAME = 'Rainer Zufall');
update EMPINST.EMP_ROLE_MAP set ROLE_ID = 'employee.extended'	where PROF_KEY = (select PROF_KEY from EMPINST.EMPLOYEE where PROF_DISPLAY_NAME = 'Rainer Zufall');

Für den inneren SELECT kann man natürlich auch eindeutige Werte in anderen Spalten nutzen.

Wenn die Person Mitglied mindestens einer Community ist/war - und das sollte sie, warum sonst wäre sie überhaupt in Connections angemeldet? - muss man auch in der Communities-Datenbank SNCOMM eine Tabelle anpassen:

-- SNCOMM
-- ISEXTERNAL=0|1 (0 = internal, 1 = external)
update SNCOMM.MEMBERPROFILE set ISEXTERNAL = 0 where DISPLAY = 'Rainer Zufall';

Und schließlich haben auch die Wikis noch einmal das "Externen"-Flag in einer Tabelle, die dementsprechend angepasst werden muss:

-- WIKIS
-- TYPE=0|1|2 (1 = internal)
update WIKIS.USER set TYPE = 1 where NAME = 'Rainer Zufall';