Principes généraux d'organisation et de gestion des droits

Un des principaux problème à résoudre et la difficulté de gérer un réseau d'item avec les systèmes de gestion de droits usuels.

En effet si j'accède à un item, cela signifie logiquement que je dois accéder à tout le réseau d'items qu'il référence. En effet, il n'y a pas de différence logique a priori pour un item entre internaliser un contenu (l'avoir au sein d'un même fichier) ou l'externaliser (y accéder via une référence à un autre fichier), donc lire un item implique de lire les items qu'il référence.

Or cela est contradictoire avec la définition d'accès item par item, ou même espace par espace, traditionnellement en vigueur dans les ECM.

On posera qu'obtenir le droit de lire implique obtenir le droit de référencer (voir la section suivante pour la justification).

• Albert est propriétaire de l'espace EA qui contient l'item IA,

• Bob est propriétaire de l'espace EB qui contient les items IB1 et IB2 tel que IB1 référence IB2.

• Bob donne l'accès en lecture (et donc référencement) à Albert sur IB1 (mais pas sur IB2).

• Donc la référence IA->IB1 est possible, mais comme Albert n'a pas le droit d'accéder à IB2, finalement il ne peut accéder qu'à une partie de IB1 (ce qui est internalisé uniquement, pas ce qui est externalisé), il y a donc une contradiction.

  

Par exemple, cette situation implique qu'Albert ne peut pas générer de forme publiée (complète) à partir de son réseau partant de IA. Ou encore, si Albert n'a même pas le droit de connaître l'existence de IB2, alors il verra dans IB1 une référence vers un item inconnu.

• Albert est propriétaire de l'espace EA qui contient l'item IA,

  Bob est propriétaire de l'espace EB qui contient l'item IB,

  Charlie est propriétaire de l'espace EC qui contient l'item IC.

• Albert donne l'accès en lecture à Bob sur EA,

  et Bob à Charlie sur EB.

• Donc le réseau IC->IB->IA est possible,

  or Charlie n'a pas le droit d'accéder à IA, il y a encore contradiction.

Par exemple, imaginons que Charlie ait le droit d'écriture sur EB, il peut éditer IB, donc modifier le lien vers IA, mais il ne peut pas lire IA, ce qui est incohérent. On notera également que Charlie ne connaît potentiellement pas l'existence d'EA et donc qu'il est très difficile de gérer cette interdiction.

Bien entendu comme dans l'exemple précédent, Charlie ne peut pas publier son contenu IC.

Notons :

• qu'une solution qui consisterait à donner les droits en accès simple (titre, méta-données et droit de publication) mais pas en lecture serait fallacieuse, car si Charlie a le droit de générer à partir d'IC, il obtiendrait alors de fait une copie de IA, qu'il pourrait donc lire.

• que ce problème n'affecte en rien les droits d'écriture, si Charlie le droit d'écrire dans EB, mais pas dans EA, cela ne pose aucun problème, tant qu'il a le droit de lire et référencer les items de EA.

Pour qu'un utilisateur ait le droit de référencer un item I situé dans un atelier A à partir d'un item J qui serait lui même référençable, il est nécessaire que tous les utilisateurs de l'atelier A aient le droit de lire cet item I, ainsi que tous les items référencés par I.

Les droits en lecture sont donc gérés globalement par atelier et non utilisateur par utilisateur (les droits en écriture restent gérés utilisateur par utilisateur). L'atelier étant un espace coopératif par définition, cette hypothèse est raisonnable du point de vue des usages.