Silverpeas » Silverpeas Core

A noter que le problème peut être contourné si la fiche utilisateur est modifiée manuellement.

Il me faudrait plus d'informations :

• est ce que l'utilisateur a été créé en base de donnée lors de la première synchro qui a été en échec ?
• si l'utilisateur a été créé en base de données, est ce que la création a été complète (toutes les données attendues ont été sauvegardées) ?
• est ce que les info complémentaires ont été aussi enregistrées ?

Autre question, qu'en est il de la synchronisation unitaire de cet utilisateur ?

Miguel Moquillon a écrit (#note-3):

Il me faudrait plus d'informations :

• est ce que l'utilisateur a été créé en base de donnée lors de la première synchro qui a été en échec ?

oui

• si l'utilisateur a été créé en base de données, est ce que la création a été complète (toutes les données attendues ont été sauvegardées) ?

oui

• est ce que les info complémentaires ont été aussi enregistrées ?

les infos complémentaires ne sont pas enregistrées puisqu'elle sont lues à la volée depuis le ldap.

Autre question, qu'en est il de la synchronisation unitaire de cet utilisateur ?

C'est à dire ?? c'est l'objet de ce ticket..

Miguel Moquillon a écrit (#note-6):

C'est à dire ?? c'est l'objet de ce ticket..

Ha oui, pardon, quand j'ai lu "synchronise unitairement", j'ai pensé à la synchronisation du domaine et pas l'utilisateur.

les infos complémentaires ne sont pas enregistrées puisqu'elle sont lues à la volée depuis le ldap.

Ok, ce ne sont donc pas des infos en provenance d'un formulaire mais de données additionnelles du LDAP.

oui ça aussi je l'avais indiqué.. ;o)

Après cela, ses infos complémentaires (service, fonction, etc..) sont modifiées dans l'annuaire LDAP.

J'ai consulté le code et la mise à jour de l'utilisateur n'a lieu que si au moins une des propriétés habituelles de l'utilisateur (nom, prénom, email, access level, specific id, domain id) ou son état a été modifiée. Les données extra de l'utilisateur en provenance du LDAP ne sont pas pris en compte pour décider de la mise à jour effective ou non (et donc de l'indexation) de l'utilisateur. Je pense que la raison de ceci est que seules les propriétés supportées par Silverpeas sont enregistrées en base de données, ce qui n'est pas le cas des données extra LDAP de l'utilisateur ; ici, on n'a pas pensé que ces données peuvent être modifiées (on n'est pas en mesure de le savoir), ce qui implique une réindexation forcée de l'utilisateur.

Pour une réindexation unitaire, ce n'est pas coûteux, mais pour une synchro complète la question se pose aussi du coup.

Pour une réindexation unitaire, ce n'est pas coûteux, mais pour une synchro complète la question se pose aussi du coup.

D'autant plus que le code est partagé entre synchro unitaire et synchro du domaine