Project

General

Profile

Support #4490

Bug de mise à jour des profils utilisateurs

Added by stéphane tissot over 6 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Profil utilisateur
Target version:
-
Start date:
04/17/2013
Due date:
% Done:

0%

Estimated time:
Navigateur:
Tous
Votre version de Silverpeas:
5.11.1
Système d'exploitation:

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.


Files

erreur maj user.rtf (19.6 KB) erreur maj user.rtf stéphane tissot, 04/30/2013 11:23 AM

Related issues

Related to Silverpeas Core - Bug #5767: [Active Directory] Erreur lors de la mise à jour du profil d'un utilisateurClosed07/03/2014

Actions
Copied to Silverpeas Core - Bug #5339: Mise à jour infos LDAP: message de succès même en cas de problème.Closed04/17/2013

Actions

History

#1

Updated by Nicolas Eysseric over 6 years ago

  • Tracker changed from Bug to Support
  • Status changed from New to 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 ?

#2

Updated by stéphane tissot over 6 years ago

Bonjour,

vous trouverez en pièce jointe le fichier de configuration et une trace résultant d'un essai par un utilisateur.

cdt

#3

Updated by Sebastien Vuillet over 6 years ago

Un problème de paramétrage a-t-il été identifié ?

#4

Updated by Sebastien Vuillet over 6 years ago

  • Assignee set to David Lesimple
#5

Updated by David Lesimple over 6 years ago

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.

#6

Updated by stéphane tissot over 6 years ago

Effectivement cela fonctionne lorsque tous les champs sont remplis.
Est-il possible de modifier cette relation aux champs vide de l'annuaire?

#7

Updated by Sebastien Vuillet over 6 years ago

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 ?

#8

Updated by stéphane tissot about 6 years ago

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

#9

Updated by Sebastien Vuillet almost 6 years ago

  • File deleted (domainARALIS.properties)
#10

Updated by David Lesimple almost 6 years ago

  • Priority changed from High to Normal

Bonjour,

Est-ce que ce problème se produit toujours sur votre serveur de test en 5.12.4 ?

#11

Updated by stéphane tissot almost 6 years ago

Bonjour,

Nous sommes passé en 5.13 et le problème persiste

#12

Updated by David Lesimple over 5 years ago

Bonjour,

Pouvez-vous nous envoyer sur les infos de connexion à votre serveur de test ?

#13

Updated by David Lesimple over 5 years ago

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 ?

#14

Updated by stéphane tissot over 5 years ago

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

#15

Updated by David Lesimple over 5 years ago

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).

#16

Updated by David Lesimple over 5 years ago

  • Status changed from Feedback to Closed
#17

Updated by David Lesimple over 5 years ago

  • Status changed from Closed to New
#18

Updated by David Lesimple over 5 years ago

  • Status changed from New to Feedback
#19

Updated by David Lesimple over 4 years ago

Puisque vous êtes maintenant (en test du moins) sous 5.14.3 et AD 2012, est-ce qu'on peut clore cette demande ?

#20

Updated by stéphane tissot over 4 years ago

A clore

si le souci se reproduit sur une version ultérieure nous réouvrirons un dossier

#21

Updated by David Lesimple over 4 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF