Bug #14518
fermé
[Synchronisation manuelle unitaire] L'utilisateur n'est pas indexé auprès du moteur de recherche
0%
Description
Cas rencontré : Suite à un problème d'indexation lors de sa synchronisation initiale, un utilisateur n'est pas retrouvé par le moteur de recherche de l'annuaire principal.
Après cela, ses infos complémentaires (service, fonction, etc..) sont modifiées dans l'annuaire LDAP.
Si on le synchronise unitairement, on pourrait s'attendre à ce que sa fiche soit indexée ou réindexée puisque ses infos complémentaires ont été modifiées.
Constat : L'utilisateur n'est toujours pas indexé
Mis à jour par David Lesimple il y a 13 jours
A noter que le problème peut être contourné si la fiche utilisateur est modifiée manuellement.
Mis à jour par Miguel Moquillon il y a 7 jours
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 ?
Mis à jour par Miguel Moquillon il y a 7 jours
Autre question, qu'en est il de la synchronisation unitaire de cet utilisateur ?
Mis à jour par David Lesimple il y a 7 jours
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..
Mis à jour par Miguel Moquillon il y a 7 jours
- Statut changé de New à Feedback
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.
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.
Mis à jour par David Lesimple il y a 7 jours
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.
Mis à jour par Miguel Moquillon il y a 7 jours
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
Mis à jour par Miguel Moquillon il y a 6 jours
- Statut changé de Feedback à In progress...
Je vais ajouter un nv paramètre à la fonction de synchronisation d'un utilisateur qui indique si sa synchronisation doit être forcée ou non. Ce paramètre sera utilisé dans le cas d'une synchronisation unitaire d'un utilisateur.
Mis à jour par Miguel Moquillon il y a 6 jours
- Statut changé de In progress... à Resolved
Mis à jour par Miguel Moquillon il y a 3 jours
- Statut changé de Resolved à Closed
Intégré dans les branches 6.4.x et master