J'ai eu récemment le cas d'un client qui voulait, lors de la suppression d'un objet user, mettre à jour l'annuaire LDAP sur lequel l'utilisateur avait un compte, plutôt que supprimer ce compte.
Pour cela, il faut tout d'abord modifier l'action liée à la situation SOURCE_MISSING, pour utiliser Unlink plutôt que Delete (en fait, si on garde l'opération Delete, on peut lancer un script, mais l'objet cible sera quand même supprimé par la suite).
On assigne donc l'action UNLINK à la situation SOURCE_MISSING dans le paramétrage.
Puis on va ajouter un script sur l'événement unlink :
Pour plus de souplesse, on utilise un script externe. J'ai tendance à structurer mes scripts par connecteur, d'où le sous-répertoire LDAP :
Le contenu du script onUnlink.js est le suivant :
/**
* Ce script est utilisé pour gérer le UnLink
* A cet instant, seul target._id est disponible. Il faut donc utiliser openidm.read
* pour récupérer tout l'objet.
*
*/
logger.info("[LDAP/onUnlink] target _id : {} " , target._id);
var ldapUser = openidm.read('system/ldap/account/' + target._id );
logger.info("[LDAP/onUnlink] ldapUser _id : {} - uid {}" , ldapUser._id, ldapUser.uid);
var dateUnlink = (new Date()).toString();
ldapUser.description="DELETED-"+dateUnlink;
ldapUser.AccountStatus="DELETED";
openidm.update('system/ldap/account/' + target._id, null, ldapUser);
Lorsqu'on supprimer l'objet User, on constate que son compte est toujours présent dans le LDAP, avec la description et le status mis à jour :
{
"pagedResultsCookie": null,
"remainingPagedResults": -1,
"result": [
{
"AccountStatus": "DELETED",
"_id": "d4f7b091-bad1-4c97-8bec-9e358038d686",
"cn": "Virginia WOLF",
"description": "DELETED-Thu Jan 28 2016 15:53:27 GMT+0100 (CET)",
"dn": "uid=vwolf,ou=People,dc=example,dc=com",
"givenName": "Virginia",
"sn": "WOLF,
"uid": "juwolanin"
}
],
"resultCount": 1
}Dans le processus du client, un batch va aller récupérer tous les soirs les entrées avec le statut "DELETED", pour les sauvegarder, afin de pouvoir éventuellement les restaurer si besoin.