Offrir la gestion de documents au niveau du département

et gère. (Une machine SharePoint Portal Server peut bien sûr fournir des informations à  l’ensemble de l’entreprise. Le serveur permettra à  tout utilisateur autorisé d’accéder aux informations, même s’il n’appartient pas au département qui possède la machine SharePoint Portal Server.)

Le nouveau produit répond aux besoins de l’infrastructure Windows en matière de fonctions de gestion de documents, comme les versions multiples (c’est-à -dire, la possibilité de maintenir plusieurs versions d’un document ou d’autres éléments en cours de développement). SharePoint Portal Server gère des versions mineures et majeures de documents. Le serveur crée automatiquement des versions mineures – dans lesquelles le numéro de version passe de 1.0 à  1.1 à  1.2 et ainsi de suite – chaque fois qu’un utilisateur met à  jour un document. Il crée des versions majeures – dans lesquelles le numéro de version passe de 1.0 à  2.0 à  3.0 et ainsi de suite – quand un utilisateur autorisé choisit de publier le document. Le produit contrôle complètement le suivi des mises à  jour. Si l’on ne peut pas revenir à  une version de document antérieure, on peut fort bien sauvegarder une version antérieure comme un nouveau document.

La fonction de publication inclut un processus workflow simple pour approuver le contenu d’un document. L’approbation est une propriété de dossier ; comme le montre la figure 1, on peut définir un ensemble d’approbateurs et configurer SharePoint Portal Server de manière à  envoyer un e-mail aux approbateurs quand un utilisateur tente de publier un document. Le workflow est extrêmement simple : on peut envoyer le document aux approbateurs un à  un, ou tous à  la fois. Quand on choisit d’envoyer la notification à  tous les approbateurs, on peut configurer le processus de manière à  publier le document après approbation par tous les destinataires ou par un seul d’entre eux. Il n’est pas possible de fixer un quorum (afin que le serveur, par exemple, ne publie le document que si deux ou trois destinataires l’ont approuvé) ou pour traiter les demandes de nouvelles informations de la part des approbateurs. (Le workflow en série est un peu plus intelligent : le document passe d’un approbateur au suivant dans l’ordre spécifié. La non-approbation du document par l’un des approbateurs a pour effet de renvoyer le document à  l’auteur). Néanmoins, la fonction de publication de SharePoint Portal Server devrait satisfaire de nombreuses entreprises dont le flux de documents est simple.

En interne, le serveur calque ses permissions sur le modèle de sécurité Windows, de la même manière que l’accès au dossier-public fonctionne dans Exchange Server 5.5. Chaque dossier et document que l’on crée dans SharePoint Portal Server a un ensemble de permissions gérées par le serveur et certains rôles permettent aux utilisateurs d’assumer ces permissions. (Un rôle est simplement un ensemble collectif de permissions permettant à  un utilisateur et au serveur d’interagir d’une certaine manière.) Le nouveau serveur définit les trois rôles suivants : Lecteur, Auteur et Coordinateur. Ces rôles sont fixes et l’on ne peut pas créer de rôles personnalisés comme pour les dossiers publics d’Exchange Server.

Comme son nom l’indique, un Lecteur peut lire des documents dans un dossier, mais il ne peut ni les modifier ni en ajouter de nouveaux. On peut associer le rôle Lecteur avec un groupe Win2K ; on peut, par exemple, associer le rôle avec le groupe Everyone sur des dossiers contenant des informations consultables par tous les utilisateurs. Un Auteur peut créer et modifier des documents. Un Coordinateur peut effectuer toute opération, y compris créer de nouveaux profils de documents, sur le dossier. Son rôle est important parce qu’il est également chargé de créer des catégories et de s’assurer que les espaces de travail sont gérés de manière logique et accessible.

Les possesseurs d’Exchange Server utilisent parfois déjà  des dossiers publics pour la gestion de documents. Mais il existe des différences importantes entre les concepts et les fonctions des deux serveurs (le tableau 1 compare les principales fonctions des deux produits). Par conséquent, il ne faut pas croire que l’on peut jouir des possibilités de gestion de documents de SharePoint Portal Server par l’intermédiaire d’Exchange Server (en tout cas, pas d’emblée). Pour plus de détails, voir l’encadré intitulé « Pourquoi ne pas utiliser simplement des dossiers publics ».