INFOPATH : Message d'erreur à la validation

Lors de l'utilisation de formulaires InfoPath, il est courant d'utiliser du code managé pour réaliser des actions supplémentaires lors de la validation d'un formulaire (envoi de mails avec pièce jointe, mise à jour de bases métiers, appels de web service).

 

Dans la plupart des cas, lors de la validation, un bouton de type "Envoyer" (Submit) vérifie que tous les champs du formulaire sont correctement renseignés.

 

Malheureusement, dans le cas d'un formulaire de type InfoPath Forms Services utilisant du code managé, cette vérification n'est pas réalisée sur les champs situés à l'intérieur d'une section masquée.

 

Pour s'affranchir de ce problème contraignant, il est possible d'utiliser le code suivant:

 

 

Ainsi, si le clic sur le bouton génère l'entrée dans le code managé, ce bout de code permettra de vérifier que le formulaire ne contient aucune erreur de validation (réalisée par le test this.Errors.Count == 0).

Le message suivant sera affiché :

 

 



 

 

En regardant de plus prêt le code, vous pourrez constater que ces libellés ne sont pas codés en dur mais récupérés directement depuis les fichiers de ressources de SharePoint utilisés par InfoPath.

SHAREPOINT : ADFS Provider Groupe AD

Aujourd'hui, un post concernant le provider d'authentification ADFS sur un environnement SharePoint. Cette technique est souvent utilisée dans le cadre d'extranet afin de fédérer l'authentification (Google, Facebook, AD externe,...).

Classiquement, certains clients mappent uniquement le champs LDAP sur le claim type "Email" afin que les utilisateurs puissent se connecter.

Seulement, avec du recul, cette configuration n'est pas suffisante car vous vous rendrez compte que les groupes AD ne pourront pas être ajoutés dans SharePoint :

 

Afin de pouvoir ajouter les groupes AD, il vous faudra modifier la partie de confiance ADFS et le trusted issuer associé à SharePoint de la façon suivante:

 

Modification règles sur la partie de confiance ADFS :

 

- Se positionner sur l’interface mappant le champ « Email » au claimtype « Email ».

- Ajouter et mapper le champ LDAP « Token groups unqualified names » sur le claimtype « Role »,

- Ajouter et mapper le champ LDAP « User-Principal-Name » sur le claimtype « UPN ».

 

Le résultat doit être le suivant:

 

 

 

Côté SharePoint 2010– Modification de l’issuer :

Il faudra se connecter sur un des serveurs et lancer la commande PowerShell pour SharePoint suivante :

$issuer = Get-SPTrustedIdentityTokenIssuer
$issuer.ClaimTypes.Add("http://schemas.microsoft.com/ws/2008/06/identity/claims/role")
$map=New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming
$issuer.AddClaimTypeInformation($map)
$issuer.Update()

Get-SPTrustedIdentityTokenIssuer

 

 

Le résultat sera le suivant:

 

 

 

 

 

A présent, suite à ces modifications, vous aurez accès au "Rôle" dans l'interface de sélection "ADFS Provider" de SharePoint :

 

 

 

Il faudra sélectionner la section rôle pour ajouter le groupe. Vous pourrez ainsi constater que le claims associé aux groupes AD se présente de la façon suivante "c :0-.t|Provider name":

 

 

 

 

SHAREPOINT : Nettoyage comptes profil utilisateur

Le service de profil utilisateur de SharePoint stocke les informations sur les utilisateurs dans un emplacement centralisé. Les fonctionnalités sociales exploitent ces informations pour créer des interactions productives et rendre plus efficace la collaboration entre utilisateurs. Pour mettre en service des sites Mon site, activer des fonctionnalités sociales telles que les liens de mise en réseau et les échanges de News ou bien créer et distribuer des profils entre plusieurs sites et batteries de serveurs, vous devez utiliser l’application de service de profil utilisateur.

 

Techniquement, des synchronisations sont effectuées via FIM (synchro bilatérale ou non) depuis l'Active Directory de l'entreprise (en SP2013, un nouveau mode de synchro en export depuis l'AD est fourni : plus rapide).

 

Lorsque les comptes sont supprimés dans l'AD, le service de profil utilisateur SharePoint supprimera ces comptes après quelques synchronisations. Seulement, ceci c'est la théorie...

Régulièrement, certains profils restent accessibles dans les profils du service.

Après une petite enquête, il s'avère que cela provient du fait que le timer job "My site cleanup job" est souvent désactivé sur les fermes SharePoint afin d'éviter toute suppression intempestive.

 

Il existe néanmoins des commandes PowerShell pour SharePoint permettant de réaliser le ménage dans les comptes de la base de profil:

 

# Récupération de l'ID du service UPS

Get-SPServiceApplication

 

# Sélection du service UPS

$upa = Get-SPServiceApplication "GUID-UserProfileService"

 

# Fournit la liste des utilisateurs qui pourront être supprimés (action en lecture)

Set-SPProfileServiceApplication $upa -GetNonImportedObjects $true

 

# Suppression des profils supprimés de l'AD (action irréversible)

Set-SPProfileServiceApplication $upa -PurgeNonImportedObjects $true

 

 

Après quelques synchronisations de profils, les comptes supprimés de l'AD vont disparaitre de votre base de profil.

Attention néanmoins à bien qualifier ceci sur une plateforme de développement ou de validation car la dernière commande est irréversible.