Project

General

Profile

Actions

Support #4490

closed

Bug de mise à jour des profils utilisateurs

Added by stéphane tissot almost 10 years ago. Updated almost 8 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:
Livraison en TEST:
Livraison en PROD:

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 2 (0 open2 closed)

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

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

Actions
Actions #1

Updated by Nicolas Eysseric almost 10 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 ?

Actions #2

Updated by stéphane tissot almost 10 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

Actions #3

Updated by Sebastien Vuillet over 9 years ago

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

Actions #4

Updated by Sebastien Vuillet over 9 years ago

  • Assignee set to David Lesimple
Actions #5

Updated by David Lesimple over 9 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.

Actions #6

Updated by stéphane tissot over 9 years ago

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

Actions #7

Updated by Sebastien Vuillet over 9 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 ?

Actions #8

Updated by stéphane tissot over 9 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

Actions #9

Updated by Sebastien Vuillet about 9 years ago

  • File deleted (domainARALIS.properties)
Actions #10

Updated by David Lesimple about 9 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 ?

Actions #11

Updated by stéphane tissot about 9 years ago

Bonjour,

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

Actions #12

Updated by David Lesimple almost 9 years ago

Bonjour,

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

Actions #13

Updated by David Lesimple almost 9 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 ?

Actions #14

Updated by stéphane tissot almost 9 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

Actions #15

Updated by David Lesimple almost 9 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).

Actions #16

Updated by David Lesimple almost 9 years ago

  • Status changed from Feedback to Closed
Actions #17

Updated by David Lesimple over 8 years ago

  • Status changed from Closed to New
Actions #18

Updated by David Lesimple over 8 years ago

  • Status changed from New to Feedback
Actions #19

Updated by David Lesimple almost 8 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 ?

Actions #20

Updated by stéphane tissot almost 8 years ago

A clore

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

Actions #21

Updated by David Lesimple almost 8 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF