Support #4490
fermé
Bug de mise à jour des profils utilisateurs
0%
Description
Nous avons utilisé le paramètre AllowedToUpdate=U dans le fichier de propriété de notre domaine, cependant tous les utilisateurs n'arrivent pas à mettre à jour ces informations.
Seuls les utilisateurs avec des droits de gestionnaire (statut attaché au profil) y parviennent.
Les utilisateurs "utilisateur" peuvent modifier le contenu des champs, au moment de la validation ils observent bien le message "votre profil a été mis à jour avec succès" mais leurs modifications ont disparu.
Par ailleurs, il est impossible d'effacer le contenu d'un champs, le profil n'accepte pas qu'un champs soit vidé - le même phénomène se produit en l'occurence pour tous les utilisateurs.
Fichiers
Mis à jour par Nicolas Eysseric il y a environ 11 ans
- Tracker changé de Bug à Support
- Statut changé de New à Feedback
Nous ne constatons pas d'anomalies sur la mise à jour des informations du profil.
Pouvez-vous nous transmettre le fichier de configuration de votre domaine d'utilisateurs ?
Mis à jour par Anonyme il y a presque 11 ans
- Fichier domainARALIS.properties ajouté
- Fichier erreur maj user.rtf erreur maj user.rtf ajouté
Bonjour,
vous trouverez en pièce jointe le fichier de configuration et une trace résultant d'un essai par un utilisateur.
cdt
Mis à jour par Sebastien Vuillet il y a presque 11 ans
Un problème de paramétrage a-t-il été identifié ?
Mis à jour par David Lesimple il y a presque 11 ans
En fait, le problème se pose lorsqu'un des 5 champs modifiés est vide.
A priori, cela pourrait venir de la manière dont Silverpeas communique la notion de champ vide l'annuaire (champ vide ou null).
Le problème ne semble se poser qu'avec Active Directory.
Mis à jour par Anonyme il y a presque 11 ans
Effectivement cela fonctionne lorsque tous les champs sont remplis.
Est-il possible de modifier cette relation aux champs vide de l'annuaire?
Mis à jour par Sebastien Vuillet il y a presque 11 ans
Le problème est lié l'Active directory, car sur un annuaire LDAP le problème ne se pose pas.
Serait-il possible d'avoir un serveur de test, afin d'investiguer plus en profondeur ?
Mis à jour par Anonyme il y a presque 11 ans
Notre admin réseau est en congés mais revient la semaine prochaine, nous mettrons en place un serveur de test probablement en milieu de semaine
cdt
Mis à jour par Sebastien Vuillet il y a plus de 10 ans
- Fichier
domainARALIS.propertiessupprimé
Mis à jour par David Lesimple il y a plus de 10 ans
- Priorité changé de High à Normal
Bonjour,
Est-ce que ce problème se produit toujours sur votre serveur de test en 5.12.4 ?
Mis à jour par Anonyme il y a plus de 10 ans
Bonjour,
Nous sommes passé en 5.13 et le problème persiste
Mis à jour par David Lesimple il y a environ 10 ans
Bonjour,
Pouvez-vous nous envoyer sur support@silverpeas.com les infos de connexion à votre serveur de test ?
Mis à jour par David Lesimple il y a environ 10 ans
Bonjour,
Après quelques tests, je peux dire que cela vient bien du fait qu'on essaye de mettre à jour un champ avec une valeur vide
alors que le dit champ (par exemple le téléphone) indique dans l'AD que la longueur minimale est de 1 (et pas 0 pour un champ vide).
J'ai vérifié sur un autre AD que le votre, mais je pense que la configuration est similaire.
Pouvez-vous vérifier ce point ?
Mis à jour par Anonyme il y a environ 10 ans
bonjour,
et il n’est pas possible de ne lancer la requête que sur les champs modifiés sans tenir compte des autres ? De notre côté cela semble compliqué de changer le paramétrage de ces champs.
Par ailleurs cela n’a rien à voir mais j’en profite: nous allons sans doute migrer vers un AD 2012 courant avril cela aura-t-il un impact sur vos requêtes LDAP?
cdt
Mis à jour par David Lesimple il y a environ 10 ans
1. Non, c'est l'AD qui est maitre de la gestion de ces champs.
Par contre, la gestion d'erreur peut être améliorée.
2. Aucun problème pour passer à Windows Server 2012 (donc AD 2012).
Mis à jour par David Lesimple il y a environ 9 ans
Puisque vous êtes maintenant (en test du moins) sous 5.14.3 et AD 2012, est-ce qu'on peut clore cette demande ?
Mis à jour par Anonyme il y a environ 9 ans
A clore
si le souci se reproduit sur une version ultérieure nous réouvrirons un dossier