Problème avec les Lookup de plus de 100 éléments dans le panneau des propriétés d’un document de Office

Lorsque vous créez une colonne Lookup dans une bibliothèque de documents SharePoint et que vous souhaitez modifier les valeurs de cette propriété dans une application Office (Word par exemple),  vous pouvez rencontrer le problème suivant si votre Lookup contient plus de 100 éléments.

List de plus de 100 éléments

Symptomes :

En ouvrant un document de cette bibliothèque dans Word, vous remarquez que ce lookup est tronqué aux 100 premiers éléments. De plus, si depuis SharePoint vous aviez sélectionner une valeur en dehors de ces 100 premiers éléments, c’est l’id de l’élément qui sera affiché et non son nom.

Explication  :

Le problème provient de la configuration de la liste sur laquelle pointe le lookup. Si votre liste est configurée pour n’afficher que 100 éléments, il vous suffit d’augmenter ce nombre jusqu’au nombre d’éléments dans votre liste pour régler le probleme.

ATTENTION : Si votre liste est configurée en mode Afficher tous les éléments, bizarrement SharePoint se comporte comme si vous vouliez limiter aux 100 premiers éléments.

limitation éléments d\'une liste

Résolution : Le seul moyen d’afficher un lookup dans Word contenant un grand nombre d’éléments est de limiter l’affichage à un nombre supérieur à votre nombre d’éléments effectivement dans la liste. Par exemple si votre lookup contient 1000 éléments, il faut régler la liste sur Limiter le nombre total d’éléments à : 1000

Dans ce cas, les applications Office afficheront bien dans le panneau de propriétés l’ensemble des éléments du lookup.

En résumé : Pour afficher un nombre important d’éléments, pensez à limiter celui-ci dans la vue !!!


Pas de commentaire

Custom Membership Provider, People picker et web.config

7 commentaires 08/07/2010

Le Membership Provider étant déjà bien documentée sur la MSDN et le TechNet, je ne souhaite pas revenir sur le partie développement et configuration de celui-ci dans l’administration centrale mais plutôt sur les liens avec le people picker.

Le but étant de revenir sur l’intérêt ou non déclarer les membership provider dans les différentes zones d’une Web Application.

L’étape de déclaration est pourtant bien notée dans le step by step du MSDN mais il est aisé de passer à coté:

For the Central Administration and existing Windows authentication Web application web.config files, you make the same changes as described previously for the forms authentication zone’s web.config file—with one exception…

Sans cette déclaration dans le Web.config, il sera impossible de rechercher un utilisateur ayant un compte dans la nouvelle base de compte (LDAP, SQL, …)

Prenons l’exemple d’un site où les utilisateurs de la zone AD doivent administrer les utilisateurs Custom.

C’est le cas le plus standard et il s’applique souvent aux applications collaboratives que l’on souhaite ouvrir à des utilisateurs externes au domaine. Dans la plupart des cas, les utilisateurs externes n’auront que des droits de collaboration sur le site et ne pourront pas gérer la sécurité. Il est donc indispensable de pouvoir rechercher les utilisateurs Custom dans le peoplepicker depuis un compte AD (et donc depuis une URL AD) pour leur donner des droits.

Dans ce cas, la déclaration du MemberShip doit être la même sur les deux zones. A l’exception de l’attribut defaultprovider qui n’est pas présent dans la zone AD.

Exemple de déclaration de la zone AD:

    <membership >
      <providers>
        <add name="fbaUser" type="Microsoft.IW.customUser, fbaSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b74d22b2d68547b5" />
      </providers>
    </membership>
    <roleManager enabled="true">
      <providers>
        <add name="fbaRole" type="Microsoft.IW.customRole, fbaSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b74d22b2d68547b5" />
      </providers>
    </roleManager>

Exemple de déclaration de la zone Custom:

    <membership defaultProvider="fbaUser">
      <providers>
        <add name="fbaUser" type="Microsoft.IW.customUser, fbaSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b74d22b2d68547b5" />
      </providers>
    </membership>
    <roleManager enabled="true" defaultProvider="fbaRole">
      <providers>
        <add name="fbaRole" type="Microsoft.IW.customRole, fbaSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b74d22b2d68547b5" />
      </providers>
    </roleManager>

Dans les cas ou les users de la zone Custom ne sont pas administrés par ceux de la zone AD

Dans ce cas, pas besoin de déclarer le provider dans la zone AD. En revanche pour pouvoir affecter des droits aux premiers utilisateurs custom vous devrez déclarer le provider dans le web.config de l’administration central pour créer une stratégie sur la zone. cf Gérer les autorisations par le biais d’une stratégie

Dans tous les cas :

  • Les utilisateurs qui font une recherche dans le people picker depuis une URL en authentification Custom n’effectue jamais une requête sur l’AD.

Cela signifie que pour un utilisateurs ayant un compte par le provider Custom et un compte par le provider AD, ces deux comptes ayant les mêmes droits dans SharePoint ils ne recevront pas les mêmes résultats.

  • Peut importe leur mode d’authentification, les utilisateurs effectuant des recherches dans le people picker trouveront toujours les utilisateurs ayant des droits explicites sur cette collection de site.

Prenons l’exemple de deux utilisateurs AD : contoso\user1 et contoso\user2, où seul contoso\user1 a des droits sur la collection de site (il est dans le groupe des membres par exemple). Si je me connecte avec un compte s’authentifiant sur le custom provider en saisissant user1 dans le people picker j’aurai bien un résulat : contoso\user1 mais en saisissant user2 je n’aurai aucun résultat.

En revanche, si je saisi le nom complet à savoir contoso\user2, le compte apparaitra. Cela peut être contourné par l’application de la KB96135.


7 commentaires

De l’intérêt d’activer les quotas sur une collection de site

Paramètres du siteQuand on travaille sur SharePoint, il y a des pages que l’on voit tous les jours. La page des paramètre de site par exemple.

Mais il y en a que l’on met deux ans à découvrir et c’est le cas de la page de gestion de l’espace de stockage que j’ai découvert très récemment.

Cette page permet de vérifier d’un seul coup d’oeil la volumétrie de la collection de site, l’espace restant par rapport au quota attribué ainsi que les bibliothèques  classées par volumétrie. Cette page est accessible à l’administrateur de collection de site à partir du moment ou les quotas ont été activés sur son site.

Attribution de l\'espace de stockage

Pour moi, c’est une bonne raison d’activer les quotas sur une collection de site. C’est en effet, à ma connaissance, le seul moyen Out of the box d’avoir un aperçu de la volumétrie d’une collection de site ainsi que de la répartition de cette volumétrie entre les bibliothèques.

D’autant que les quotas sont ajustables à postériori et qu’ils permettent de garder un oeil sur la croissance des sites et recevant des alertes au passage d’un seuil.

Liens relatifs au sujet :


Pas de commentaire

Windows Integrated authentification avec Firefox

4 commentaires 30/10/2009

image

Il est possible d’activer l’authentification Windows intégrée dans Firefox et ainsi éviter le popup d’authentification à chaque ouverture de session sur le site.

Pour cela, il suffit d’ouvrir la configuration de Firefox en tapant : about:config dans la barre d’adresse et de changer la chaine de caractère : network.automatic-ntlm-auth.trusted-uris qui est vide par default.

image

image

Saisissez ici le nom d’hôte du site auquel vous souhaitez accéder et validez

Inconvénient : Il faut saisir ici les noms d’hôte de chacun des sites individuellement.


4 commentaires