Notes techniques relatives aux développements C2M · septembre 2009 pour permettre à l'ensemble des acteurs (Kelis, UTC et Nuxeo) de partager une vision commune sur le système

14 avril 2011 - Version 1.2

Kelis, ICS - Contributions : Nuxeo, Amexio

Notes techniques relatives aux

développements C2M

PROJET C2M

SOMMAIRE

Objet de ce document.....................................................................5

I Intégration Scenari - Nuxeo.........................................................6

1 Applications cibles..................................................................................................6

2 Principes élémentaires de Scenari et définitions...................................................6

3 Besoins fonctionnels...............................................................................................7

II Scenari - CMIS - Nuxeo...............................................................9

1 Quelques rappels....................................................................................................9

2 Limites du standard CMIS....................................................................................11

3 Mapping CMIS iso-fonctionnel au mapping FileSystem.......................................12

4 Mapping CMIS dédié Scenari...............................................................................12

III Synthèse de l'implémentation de l'intégration Scenari-Nuxeo14

1 Architecture générale...........................................................................................14

2 Api du connecteur................................................................................................14

IV Gestion des liens et des versions dans SCENARInuxeo............15

1 Principes généraux...............................................................................................15

2 Les versions..........................................................................................................16

3 L'historique..........................................................................................................17

V Projet de gestion des droits dans Scenari.................................18

1 Définitions............................................................................................................18

2 Principes d'implémentation..................................................................................21

2.1 Avec arbre de gestion des items...............................................................21

2.2 Sans arbre de gestion...............................................................................22

Glossaire.......................................................................................23

Annexes........................................................................................25

C2M 3

OBJET DE CE DOCUMENT

Ce document agrège différentes notes techniques produites au fur et à mesure du déroulement du projet pour permettre la collaboration des différents acteurs.

C2M 4

I INTÉGRATION SCENARI - NUXEO

En prévision d'une intégration avec le système Nuxeo, cette note a été écrite en septembre 2009 pour permettre à l'ensemble des acteurs (Kelis, UTC et Nuxeo) de partager une vision commune sur le système Scenari, ses principes de fonctionnements et les premiers enjeux fonctionnels auxquels on souhaitait répondre.

1 Applications cibles

1. Nuxeo back-end de stockage de Scenari et de son IHM pour accroitre la scalabilité et intégrer des fonctionnalités « GED » à Scenari.Cas d'usages : Les utilisateurs actuels et futurs de Scenari demandeurs d'une « pure » chaine

éditoriale.2. Scenari embarqué dans Nuxeo et son IHM en intégrant son moteur d'édition et

son moteur de transformation.Cas d'usages : Les utilisateurs actuels et futurs de Nuxeo, disposant d'une base de documents

non structurés souhaitant intégrer des briques structurées ou migrer progressivement leurs contenus vers une approche structurée.

Exploitation des 2 IHM : Ihm Nuxeo pour les gestionnaire/administrateurs, validateurs de workflow, etc. et l'Ihm scenari pour les auteurs

3. Ihm full-web produite dynamiquement par le moteur de transformation Scenari offrant au travers de la navigation du contenu les accès aux fonctionnalités d'édition Scenari, de gestion GED et de publications multi-supports.Cas d'usages : KM, bases de connaissance / capitalisation où les fonctions d'auteurs, de

lecteur et de gestionnaire s'imbriquent. CMS/Wiki 3.0, ie structurés sémantiquement et réellement multi-usage et

multi-support.

2 Principes élémentaires de Scenari et définitions

Un item* est le grain de contenu manipulable par les auteurs*. Un item peut-être référencé par d'autres items. L'ensemble du réseau des items* (xml et binaires) constitue la base de contenus sous leurs « formes génératrices* ».

Un « document » au sens Scenari (ou forme publiée*) est le résultat d'une transformation* de la forme génératrice d'un ou plusieurs items sous une forme adaptée à un usage (auteur, relecteur, public cible : opérationnel, manager, apprenant, formateur...) et à un canal de diffusion (pdf, page web, site web, slide-

C2M 5

Notes techniques relat ives aux développements C2M > Intégrat ion Scenari - Nuxeo

show...)

1 item = 1 « document » est l'exception. Chaque item est généralement constitué d'une agrégation arborescente d'autres items (réseau acyclique). Certains cas d'usages impliquent des modèles documentaires* permettant des réseaux cycliques d'items.

3 Besoins fonctionnels

Suivi des modifications de chaque item avec mémoire des modifications, surtout si changement d'auteur (différent du versionning car pas de mémoire du réseau).

Stratégies de versionning :

1. Besoin prioritaire : versionner un item avec sa descendance2. Dans certains cas : versionner un atelier (le versionning d'espace semble

moins pertinent) Modifications concurrentes :

Fonctionnement actuel : création d'un item suffixé de ~conflict si une modification est intervenue entre temps (méthode à la Lotus Notes).

Lock / unlock manuel des items : peu réaliste/utilisable dû à l'écriture fragmentée multi-items.

Fonctionnement envisageable : lock automatique de l'éditeur dès la 1ère modification dans un éditeur jusqu'à l'enregistrement ou la fermeture de l'éditeur (développement ad-hoc dans Sc).

Concept de workspace = espace de travail collaboratif instantané / synchrone associé à un modèle documentaire et potentiellement restreint à certains utilisateurs en lecture et/ou écriture.

Autorisations d'accès au sein d'un atelier : Restrictions en écriture : principes d'ACL applicables sur les espaces ou les

items. Spécifié manuellement et/ou en fonction du modèle grâce à SCbuilder. Mais attention techniquement : la modification d'un item lié peut entrainer un changement de statut et une modification des propriétés des items parents (même si l'auteur de la modif n'a pas les accès en écriture sur les pères).

Restrictions en visibilité : non car la contextualisation des propriétés d'item en fonction de l'auteur n'est pas envisagée.

Des items versionnés ou live d'un workspace peuvent posséder un statut « public » : ils constituent des « portes d'entrées » donnant un accès en lecture seule à l'item et à ses descendants. Les items publics sont référençables par des items d'autres ateliers.

Attention : Appliquer les restrictions d'accès en lecture internes au workspace. Niveaux de compatibilité entre modèles documentaires de workspaces => les

propriétés de l'item sont recalculées et propres au workspace pointeur. Des versions d'items (et leur descendance) peuvent être publiées dans des

sections publiques (au sens NuxeoDM) pour créer un « grain » (un Document-dossier (DD)*). Ce grain peut aussi contenir un ou plusieurs documents générés à partir de cet item (un pdf, un site web, un export xml dans un autre schéma, un extrait textuel dédié à l'indexation full-text, forme génératrice* mais avec des liens


C2M 6

Notes techniques relat ives aux développements C2M > Intégrat ion Scenari - Nuxeo

inter-items en relatifs pour être exportés dans un système tiers ou FG', etc.). Le grain est vu lui-même comme un live document, dont toute modification crée systématiquement une version. Cela permet à celui qui pointe un des contenus du grain de spécifier une version précise ou de pointer le live document pour bénéficier automatiquement de la dernière version publiée du grain. Problème du respect des restrictions d'accès en lecture internes au workspace

si publié par un auteur autorisé. Faut-il considérer ces 2 fonctionnalités (publication de grains et restrictions en lecture dans un atelier) structurellement incompatibles ?

Des items peuvent référencer des items publiés ou des documents générés associés, voire d'autres documents de la base documentaire de Nuxeo (si le modèle documentaire du workspace de l'item source permet d'intégrer le format de ces documents).

Recherche d'items : à partir d'un workspace ou d'un espace à partir d'un item et dans toute sa descendance lorsqu'on cherche un item d'un autre workspace pour le référencer, on peut

considérer qu'on sait dans quel workspace on recherche l'item, et la recherche full-text pourrait se limiter aux items déclarés publics sans leur descendance.

Recherche de grains publiés : à partir d'une section publique dans les grains


C2M 7

II SCENARI - CMIS - NUXEO

Cette note technique a été produite en octobre 2009 dans le cadre des réflexions sur l'intégration Scenari-Nuxeo : La première piste envisagée était d'exploiter la nouvelle norme d'interropérabilité CMIS. Cette piste a été finalement écartée pour les raisons évoquées dans cette note.

1 Quelques rappels

Structure d'objets Scenari

Workspace* = espace de travail racine associé à un modèle documentaire permettant de valider et d'exploiter les contenus des items qu'il contient (indexation, renditions...).

Space*(s) = structuration arborescente pour aider les auteurs dans leur organisation / gestion, non signifiant sémantiquement pour le contenu des items (ie pas d'impact sur les publications). Item*

Contenu de l'item composé de flux xml et/ou binaires (cf ci-après). Propriétés de l'item intégralement calculées à partir du contenu (ie

extraites du contenu) et du modèle documentaire associé au workspace. Données complémentaires prévues dans le cadre d'une intégration GED :

meta-données de gestion de l'item indépendantes du contenu (audit-trail, statuts workflow, etc.)

Propriétés d'items (extraites du contenu)

La structure de propriétés d'items respecte un schéma XML générique indépendant du modèle documentaire.

Voici un exemple de représentation XML possible des propriétés d'un item extraites de son contenu en fonction du modèle documentaire associé au workspace :

<item>

<title>Titre de l'item</title>

<signature>String représentant les caractéristiques de l'item</signature>

<status>Null/Pending/Valid/Warning/Error : état de l'item; si il existe et calculé, l'état valid / warning ou error est calculé par agrégation des problèmes issus des contentProblems et des attrRef ci-dessous</status>

<attrStr name="clé de cet attribut">Valeur de l'attribut</attrStr>

<attrListStr name="clé de cet attribut">

<str>Valeur 1</str>

<str>Valeur x</str>

C2M 8

Notes techniques relat ives aux développements C2M > Scenari - CMIS - Nuxeo

</attrListStr>

<attrDate name="clé de cet attribut">Date</attrDate>

<attrNumber name="clé de cet attribut">Number</attrNumber>

<attrXml name="clé de cet attribut">...xml...</attrXml>

<attrRef name="clé de cet attribut" refUri="uri item pointé">

<pb type="warning/error" code="..." msg="...">...details...</pb>


</attrRef>

<contentProblems>



</contentProblems>

</item>

Interdépendance des propriétés d'items :

Contexte : un item A pointe un item B, ie un item A contient un attrRef qui pointe l'item B.

Les propriétés de l'item A doivent être réévaluées lorsque l'item B est modifié car des problèmes de l'AttrRef de l'item A peuvent apparaître ou être résolus en fonction de la nouvelle version de B.

Le statut général de l'item A peut donc évoluer en fonction des modifications de l'item B.

Typologie des contenus d'items Scenari Items XML = 1 flux xml Items binaires = 1 flux binaire Items binaires enrichis = 1 flux binaire + 1 flux de meta-données xml + 1 flux de

propriétés physiques xml + {PREVU : x flux binaires associés à des paths arborescents = sources auteurs non gérés par Scenari}

Items folders = X flux binaires associés à des paths arborescents + {PREVU : 1 flux de meta-données xml}

Mapping avec le FileSystem Workspace = un dossier contenant un fichier xml nommé « .wspmeta » spécifiant

le modèle documentaire à utiliser. Space = un dossier du FileSystem. Item Xml = un fichier xml. Item Binaire = un fichier binaire.


C2M 9


Item Binaire enrichi = un dossier contenant : le flux binaire portant le même nom que le dossier + un fichier xml de meta-données + un fichier xml de propriétés physiques.

Item Folder = un dossier du FileSystem contenant des fichiers et sous-dossiers.

Limites du mapping FileSystem Pas d'audit-trail / versionning Pas de gestion de droits élaborés Scalabilité limitée : pas de sérialisation / persistance des propriétés des contenus

=> nécessité de garder en mémoire le réseau des propriétés d'items et de parser l'intégralité des contenus au chargement d'un workspace pour offrir les fonctionnalités du type « parcours ascendant du réseau d'items », ou renommage transverse d'items.

Pas de fonctions collaboratives et de notions : de locks, de working copys privés d'items publics exploitables par d'autres workspaces de workflow de production et validation des contenus

2 Limites du standard CMIS

La principale limite est l'absence de fonctions transactionnelles. L'intégrité référentielle nécessaire à la persistance des propriétés des items (et de leur inter-dépendance) ne peut être garantie.

Par conséquent, en utilisant CMIS, il apparaît impossible de résoudre plusieurs des limites actuelles de Scenari : la scalabilité et certaines fonctions collaboratives.

Deux usages de CMIS sont néanmoins envisageables offrant un spectre limité de fonctionnalités (cf ci-après).

Autres inconvénients (non rédhibitoires) :

Norme assez lâche autorisant différents comportements du serveur, mais contraignant le client à des implémentations plus complexes s'adaptant à ces différents serveurs. Exemple : chaque modification peut ou non produire un nouvel ID. L'ID ne peut donc être considéré comme une donnée stable pour un item donné, ce qui aggrave le problème des performances.

Absence de notion de paths, ce qui implique des requêtes couteuses en performance pour obtenir l'ID d'un item et nécessitera probablement des mécanismes de caches.

Absence de système de notification des modifications intervenues dans le repository qui seraient utile pour améliorer les performances et mettre à jour les caches et le réseau d'item Scenari (problème d'immaturité de la norme).


C2M 10


3 Mapping CMIS iso-fonctionnel au mapping FileSystem

Avantages : Aucun développement/paramétrage côté serveur CMIS. Développements relativement simples côté Scenari, sous réserve des

performances réelles qui nécessiterait un système de cache.

Inconvénients Pas de versionning possible via CMIS (folders non versionnables). Contenus difficilement exploitables côté GED en dehors de Scenari. Aucune des limites actuelles de Scenari résolues via CMIS (éventuellement

certaines features peuvent être assumées par le système de GED directement, indépendamment de Scenari).

4 Mapping CMIS dédié Scenari

Création de types spécifiques Scenari côté serveur CMIS : ScWorkspace extends Folder

Property « wspMeta » de type xml ScSpace extends Folder ScItem extends Document

Property « title » de type string Property « preview » de type html

ScItemXml extends ScItem Le contentStream contient le flux Xml

ScItemBinary extends ScItem Le contentStream contient le flux binaire principal Property « meta » de type xml contenant les meta-données du flux binaire Property « props » de type xml contenant les propriétés physiques du flux

binaire (SCSize, etc.) ScItemFolder extends ScItem

Le contentStream contient un jar du dossier Property « index » de type xml contenant l'index des dossiers et fichiers (à

valider l'intérêt, pour perfs) Property « meta » de type xml contenant les meta-données du dossier


C2M 11

III SYNTHÈSE DE L'IMPLÉMENTATION DE L'INTÉGRATION

SCENARI-NUXEO

Cette note technique produite début 2011 synthétise l'implémentation réalisée pour l'intégration Nuxeo.

1 Architecture générale

Le couche java de Scenari est intégrée dans la webApp (J2EE) de Nuxeo. Scenari déclare une servlet supplémentaire dans la webApp Nuxeo, point d'entrée

pour l'IHM Scenari. Scenari exploite l'authentification réalisée en amont par les servlet filters de

Nuxeo pour récupérer un objet NuxeoSession et le user connecté. Ce NuxeoSession est passé en paramètre à tous les appels de l'Api nuxeo-scenari-

connecteur.

2 Api du connecteur

Nuxeo utilise une approche de type OSGI. Un service OSGI (singleton) permet à Scenari de dialoguer avec les couches

Nuxeo. Ce service permet d'obtenir des objets stateless représentant les objets Scenari

stockés dans Nuxeo : Workspace, Space, Item...

Javadoc des interfaces du connecteur

Cette interface java a été posée en collaboration avec les équipes techniques de Nuxeo et en particulier Thierry Delprat, directeur technique de Nuxeo.

en web (cf. page Error: Reference source not found) en pdf (cf. annexe 1 page 23)

C2M 12

IV GESTION DES LIENS ET DES VERSIONS DANS SCENARINUXEO

Cette note a été produite en janvier 2011 pour synthétiser les développements réalisés dans Nuxeo pour assurer l'une des fonctions jugée prioritaire dans C2M : la gestion de versions des réseaux d'items. Cette note permettra de partager cette première expérience avec notre partenaire Amexio pour envisager les connections avec d'autres systèmes d'ECM.

1 Principes généraux

Scenari, en tant que système d'édition de document par fragment, doit maintenir un réseau* de références entre les différents items* composant un document. Cette problématique ne fait pas partie des systèmes de GED, existant avant tout pour gérer des documents bureautiques classiques (PDF, DOC, etc...). Ces systèmes peuvent permettre de définir des relations entre documents, mais ces mécanismes ne sont pas assez flexibles dans un contexte d'édition, notamment à cause de contraintes d'intégrités fortes ne permettant pas à un lien d'être "cassé".

Références par identifiant

Les systèmes de GED permettent de pointer un document à la fois par un chemin et par un identifiant. En utilisant ces derniers comme données de références entre les items Scenari, l'intégrité du réseau sur les déplacements et les renommages est assurée implicitement, les identifiants étant stables quelque soit le chemin.

Dans un système avec arbre de gestion, les références doivent néanmoins être cohérentes par rapport à l'emplacement. Par exemple, partant d'un item A pointant un item B, si B est supprimé et qu'un item C est ensuite déplacé vers l'ancien emplacement de B, la référence de A vers C doit être résolue.

Le live document

Le live document correspond à un document dans son état courant : sur lequel s'effectue les évolutions / les utilisateurs travaillent. Il est à mettre en opposition à une version qui correspond à l'état du document à un instant t (en lecture seule et créé par copie du live document).

Nuxeo conserve l'identifiant des live documents lors d'une création de version (ce qui n'est pas implicite sur un checkIn/checkOut). Étant donné qu'il ne propose pas de versionning de branches, il ne peut y avoir plusieurs live documents d'un même document.

C2M 13

Notes techniques relat ives aux développements C2M > Gest ion des l iens et des versionsdans SCENARInuxeo

2 Les versions

Lors de la création d'une version d'un document, une copie du réseau d'items le composant est effectuée. Néanmoins, les références entre items doivent être modifiées pour pointer les versions des items liés et non pas les live documents. Une table de correspondance de liens, définie sur chaque item, est utilisée à cette fin : le flux binaire de l'item versionné conserve la référence vers le live document mais lors de la résolution du lien, la table est interrogée pour établir la correspondance avec l'item versionné.

Nuxeo voit la création d'une version d'un document comme une opération atomique : il est impossible de modifier une version après l'établissement de son identifiant et avant sa création effective et sa mise en lecture seule. Nous ne pouvons donc établir la table de correspondance avec les identifiants systèmes des versions référencées. Nous utilisons un identifiant annexe, spécifique aux versions, impliquant un cas particulier dans la résolution des références.

Réutilisation des réseaux versionnés

Si un réseau n'a pas été modifié depuis la dernière version créé, celle-ci est réutilisée lors de la création d'une nouvelle version l'impliquant (exception faite de l'item portant la version). Il s'agit d'une optimisation importante : dans un document d'une centaine d'items ou plus, les modifications d'une version sur l'autre sont généralement localisées. Sa mise en place implique par contre de répercuter le status dirty d'un item à l'ensemble des sous-réseaux l'utilisant.

Étapes de la construction d'une version

La création d'une version se décompose ainsi :

1. Établir la liste des items à versionner en parcourant le réseau du document2. Générer un identifiant pour chaque future version, ou récupérer celui de la

dernière version s'il n'y a pas eu de modification sur le live document depuis celle-ci (en prenant en compte les modifications sur la descendance)

3. Pour chaque item nécessitant la création d'une version :1. Sauvegarder le tableau de correspondance du live document,2. Établir le tableau de correspondance des liens avec les identifiants de version,3. Affecter ce tableau au live document,4. Créer la version,5. Rétablir les propriétés du live document.

3 L'historique

L'historique est un ensemble de versions permettant de suivre les changements locaux effectués sur un item.


C2M 14

Notes techniques relat ives aux développements C2M > Gest ion des l iens et des versionsdans SCENARInuxeo

Ces versions sont crées à chaque fois qu'un utilisateur modifie un item précédemment édité par un autre, et non pas à chaque sauvegarde. Cela répond à la majorité des besoins fonctionnels sans être trop coûteux d'un point de vue système (manie du Ctrl-S).

Les références de l'entrée d'historique ne sont pas transformés : elles continuent à pointer les live documents. Elles ne sont donc pas réutilisées dans le versioning de réseau. Une information de type/origine est stockée sur chaque version (d'historique et de réseau) pour permettre cette sélection.


C2M 15

V PROJET DE GESTION DES DROITS DANS SCENARI

Cette note technique synthétise les réflexions en cours concernant l'un des aspects les plus problématiques du projet : la gestion des droits et des restrictions d'accès dans une chaine éditoriale. Les premières implémentations pour valider les principes évoqués dans cette note commenceront en février 2011.

1 Définitions

Rôles

La gestion des droits dans Scenari est basée sur le concept de rôles. Par rôle, nous entendons une fonction assumée par les acteurs d'un système. Exemples : rédacteur, éditeur, correcteur, traducteur, documentaliste...

Dans les conceptions classiques d'un contrôle d'accès par rôles, ceux-ci consistent en un regroupement d'utilisateurs sur une partie d'un système (worskpace/espace dans notre cas) par son critère d'accès (le chemin). Les rôles dans Scenari peuvent être définis par d'autres critères que le chemin, tel que le type de l'objet dans le sens d'un modèle documentaire, pour par exemple restreindre l'édition d'items dédiés à l'indexation à un rôle documentaliste.

Outre cet enjeu fonctionnel, l'introduction des rôles permet :

de définir les classes d'acteurs en amont de l'instance de l'application, lors du développement du modèle documentaire,

de définir des rôles implicites sur les objets tel que créateur, pour par exemple restreindre l'initiation d'un workflow sur un objet à son créateur,

avoir une interface utilisateur réactive s'adaptant finement aux droits alloués à l'utilisateur, sans que le client n'ait besoin d'interroger le serveur ou d'avoir une vue complète sur le système.

Définition des rôles d'un utilisateur pour un objet

getRoles(object, user) -> role[]

avec :

user : utilisateur connecté (incluant son profil, ses appartenance à des groupes, etc),

object : objet sur lequel l'utilisateur joue un ou plusieurs rôles. Aujourd'hui, les objets sont des items, des espaces, des ateliers, le serveur (mais ce pourrait être d'autres objets : les publications, les documents-dossiers*, les workflow, les annotations...),

C2M 16

Notes techniques relat ives aux développements C2M > Projet de gest ion des droi ts dansScenari

role[] : ensemble de rôles assumés par un utilisateur sur un objet donné, getRoles() : fonction qui doit fournir la liste des rôles pour un couple (objet,

utilisateur) donné.

Permissions

Une permission représente une opération possible sur un objet. Il se caractérise par un verbe (read, write, etc...). L'ensemble des permissions est défini en dur dans le code de l'application, par une hiérarchie représentant la spécialisation de l'opération. Cette spécialisation se veut très fine, allant jusqu'à décrire la visibilité des opérations dans l'interface graphique.

Droits systèmes

La gestion de droits par rôles est complémentaire d'une gestion de droits dit "système", représentant des contraintes extérieurs indépendantes des rôles joués par chaque utilisateur sur les objets. Par exemple, sans modifier les rôles de chaque utilisateur sur un item, ce dernier peut-être verrouillé en écriture car :

il est en cours d'édition par un auteur il est impliqué dans un processus de workflow qui impose de ne pas modifier cet

item pendant la durée de ce workflow l'item n'est pas un item appartenant à l'atelier mais un item externe (cf liens inter-

ateliers) un mécanisme de backup impose de verrouiller tout accès en écriture pendant

une heure chaque nuit etc.

Exemples d'un ensemble de permissions avec son arbre de spécialisation

La permission do est la racine de toutes les permissions.

Les permissions de 2ème niveau correspondent à des grandes classes d'actions (lire, écrire, administrer...).

Les permissions de niveaux suivants correspondent à des actions sur des types d'objets précis.

Les permissions de dernier niveau sont des permissions spécifiques à chaque élément d'interface graphiques (comme les views..). Une même action peut ainsi être autorisée au travers d'une certaine interface graphique, mais pas une une autre.

Les permissions systèmes sont précisées entre parenthèses.

do read (READ) write (WRITE)

item.write item.create

- view.wspnav.item.create


C2M 17


item.delete- view.wspnav.item.delete

item.update- view.wspnav.item.update- view.mainview.item.update

item-version.restore- view.versions.restore

item-version.create view.versions.create

admin (ALL) wsp.create

view.wspManager.wsp.create server.create server.installPack

Caractéristiques des rôles Priorité : les différents rôles définis pour un utilisateur sur un objet peuvent

entraîner des permissions contradictoires. Les rôles sont donc caractérisés par une priorité influençant l'ordre de contrôle des permissions.

Extension : une notion d'extension de rôle est introduite pour faciliter la définition des autorisations : un auteur est un contributeur qui dispose en plus des permissions X et en moins les permissions Y.

Groupe : les rôles peuvent être groupé pour déterminer une relation d'exclusivité entre les rôles. Cette contrainte n'est pas forcément forte : elle sert avant tout à présenter une interface graphique de sélection du rôle adaptée à l'environnement métier.

Autorisations

Les rôles jouant le rôle d'indirection par rapport à l'association objet / utilisateur, le test effectif déterminant si une action est permise ou non se résume à une relation entre les permissions et les rôles. Elle peut être définie en amont de l'instance applicative, sous la forme d'un ensemble de triplets (role, permission, allowed).

Exemple de paramétrage (superAdmin, do, allow) : un utilisateur qui a le rôle superAdmin peut tout faire. (contributor, do, deny) : un utilisateur qui a le rôle contributor ne peut rien faire

par défaut. Les permissions lui seront autorisées plus localement.

Définition des autorisations

isAllowed(permission, role[], systemRights) -> boolean

avec :

permission : permission à tester, role[] : liste de rôles issus de la formule getRoles(object, user), systemRights : droits systèmes associés à l'objet, isAllowed() : fonction qui détermine si au moins un des rôles passés en paramètre


C2M 18


dispose d'une permission.

L'algorithme de isAllowed() est :

1. tri des rôles selon leur priorité ;2. si des droits systèmes sont associés à la permission, contrôle que les droits

systèmes de l'objet passé en paramètre inclus les droits requis par la permission, sinon retourne faux.

3. pour chaque rôle :1. recherche d'un triplet avec la permission. si un triplet est trouvé, la fonction

retourne vrai si allow, faux si deny ;2. si aucun triplet trouvé, on recommence avec le rôle qu'il étend;

4. si aucun triplet trouvé, on recommence l'étape 2 avec la permission parente ;5. si aucun trouvé, on retourne faux (mais c'est alors une erreur de paramétrage à

moins que la liste des rôles ne soit vide).

2 Principes d'implémentation

L'implémentation de la gestion des droits peut différer de façon importante en fonction des possibilités de la GED et des besoins fonctionnels, notamment sur la définition de getRoles.

On pourra, par exemple, faire simplement correspondre l'ensemble des rôles aux groupes d'utilisateurs dans certains cas d'usages.

Nous pouvons néanmoins dégager deux grands types d'implémentation dépendant des besoins fonctionnels : avec et sans arbre de gestion.

2.1 Avec arbre de gestion des items

Héritage

Dans un système avec une arborescence d'objets (notion d'espaces dans Scenari), il est naturel d'envisager la définition de getRoles en fonction du chemin des objets, et de permettre l'héritage des autorisations d'un objet vers ses descendants.

Si un rôle est défini localement sur un objet O pour l'utilisateur U, l'héritage des rôles par les ascendants de O est coupé pour U et cette redéfinition sera héritée par les descendants de O.

Interface graphique de visualisation et de définition de getRoles

L'interface est contextuelle à un objet de l'arborescence (workspace, espace) et doit permettre :

de visualiser les autorisations définies localement, de visualiser les autorisations hérités et leur surcharge éventuelle,


C2M 19


d'ajouter et supprimer une autorisation locale.

Maquette de l'écran de définition des rôles

2.2 Sans arbre de gestion

Dans un système sans arbre de gestion (où l'accès aux documents se fait par catégorisation ou recherche) la définition de getRoles pourrait ne dépendre que du type des items (cf exemple du rôle documentaliste) et être global à un atelier (sans notion d'héritage).


C2M 20

GLOSSAIRE

Atelier p. 8Un atelier est un lieu de travail collaboratif restreint à une équipe d'utilisateurs identifiés.

Il est animé par un coordinateur (le chef d'atelier) et les membres de l'équipe ont des droits différents (lecture, écriture, etc.) en fonction de leur rôle (auteur, éditeur, contributeur, etc.).

L'ensemble des contenus créés dans l'atelier est accessible à l'équipe entière en lecture au moins, à l'exception de ceux situés dans des îlots.

Auteur p. 5Un auteur est un utilisateur ayant pour tâche de produire des documents.

Il possède un ou plusieurs espaces, au sein desquels il a tous les droits (créer des items, des sous-espaces, etc.) y compris celui de s'affecter des coauteurs ou des contributeurs

Il intervient sur le contenu et le scénario des documents.

Document-dossier (DD) p. 6, 16Un document-dossier est une unité de diffusion et d'archivage. Il est composé d'une forme génératrice figée FG', de formes de référence figées FR, de formes publiées figées FP et du modèle documentaire.

Dans un contexte de fragmentation, il est une unité de fermeture car il regroupe un réseau d'items fermé et figé.

Dans un contexte de séparation "fond/forme", il est une unité de publication car il regroupe les formes de production et les formes de publication nécessaire à un usage.

Espace p. 8Un espace est un sous-ensemble d'un atelier (équivalent à un dossier dans un système de fichiers), contenant des sous-espaces et des items. Il sert à l'organisation du contenu fragmenté dans l'atelier.

Il appartient à un auteur. Il est accessible en lecture à tous les collaborateurs de l'atelier (sauf s'il est situé

dans un îlot). Il est accessible en écriture à l'auteur et aux coauteurs sur l'espace, et en révision

aux contributeur sur l'espace.

Forme génératrice (FG) p. 5, 6Une forme génératrice est une inscription calculable contrôlée par un modèle documentaire, permettant de dériver l'ensemble de ses formes publiées et formes éditables, par application de transformations.

C2M 21

Notes techniques relat ives aux développements C2M > Glossaire

Elle peut-être constituée de plusieurs fragments (ou items) reliés entre eux et constitue la matrice d'un document-dossier.Synonyme : Réseau d'items.

Forme publiée (FP) p. 5Une forme publiée est un document obtenu par transformation d'une forme génératrice (FP=T(FG)) destiné à un usage en particulier. Elle peut également être une forme d'usage du document-dossier (lecture, diffusion, échange, etc.)

Item p. 5, 8, 13Un item désigne un fragment autonome (référençable par d'autres items) dans le système.Synonyme : Fragment

Modèle documentaire p. 6Un modèle documentaire est constitué de l'ensemble des informations formelles permettant de contrôler la structure d'une forme génératrice ainsi que ses transformations en formes publiées et formes éditables.Un modèle documentaire comprend :

Le schéma XML L'explicitation formelle du schéma XML (sémantique associée) Les programmes ou algorithmes des transformations

Réseau d'items p. 5, 13Un réseau d'items désigne un ensemble d'items se référençant. Il dispose d'un item racine permettant d'accéder récursivement à tous les items du réseau.Synonyme : Forme génératrice

Transformation p. 5Une transformation est un programme informatique permettant d'obtenir, à partir d'une forme génératrice, une forme publiée, une forme éditable ou une forme de référence.

FP=T(FG) FE=T(FG) FR=T(FG)


C2M 22

ANNEXES

Annexe 1 apidocs

cf. 'apidocs.pdf'

C2M 23

Documents

Notes techniques relatives aux développements C2M · septembre 2009 pour permettre à l'ensemble des acteurs (Kelis, UTC et Nuxeo) de partager une vision commune sur le système