(ce billet fait partie d’un ensemble consacré au projet Skriv)

Ça fait un bout de temps que je n’ai pas parlé de Skriv, mais je continue à travailler dessus (c’est une des raisons de ma faible productivité sur ce blog).

J’avais écrit un article concernant l’organisation de l’information. C’était intéressant, mais j’étais parti dans une direction bien trop complexe pour être envisageable ; je m’empêtrais dans un système de tags tentaculaire. J’ai continué à réfléchir à tout ça, cette fois-ci en partant du besoin fonctionnel pour aller jusqu’aux droits d’accès des utilisateurs. L’air de rien il s’agit d’un point très important, qui influe directement sur la philosophie de l’outil.

Organisation de l’information

Pour commencer, parlons du découpage des données :

• Il existe des projets, auxquels les utilisateurs ont accès.
• Les utilisateurs possèdent des groupes de projets, dans lesquels ils peuvent placer leurs projets. Ainsi, j’imagine que je mettrai le projet «IT» dans le groupe «Professionnel», alors qu’un de mes collègues le mettra peut-être dans son groupe «Informatique».
• Les projets contiennent des sous-projets. Chaque sous-projet peut contenir un ensemble de listes, de fichiers, de documents écrits, etc. C’est LE moyen de regrouper des informations connexes (par exemple une spécification fonctionnelle, des maquettes graphiques, une spécification technique, une liste de tâche et une liste de bugs) au sein d’un même ensemble logique.

L’idée est de permettre à chacun d’organiser les données de la manière qui lui convient le mieux. Habituellement, les logiciels de gestion de projet sont assez binaires : Ils servent à gérer les projets de l’entreprise, et donc les projets qu’on y crée sont visibles par les membres de l’entreprise ; les systèmes de gestion des droits empêchent d’ailleurs souvent de créer des projets quand on n’est pas soi-même un administrateur ou un chef de projet. Pour ma part, j’ai une vision très différente des choses.

Les buts

Je veux pouvoir utiliser le même outil pour mes projets personnels et mes projets professionnels. Je veux pouvoir regrouper les projets en fonction de ce qui est le plus logique à mes yeux, sans que cela ne me soit imposé par quelqu’un d’autre, ni que mes changements ne se reflètent chez les autres.

Si j’ai accès à un projet, je veux pouvoir y ajouter des éléments (sous-projets, listes, documents, …) qui ne seront visibles que par moi. Par exemple, si j’ai besoin de faire des annotations personnelles sur une spécification, ou si je veux gérer une liste de tâches personnelle concernant un projet particulier, je dois pouvoir le faire. Si je le souhaite, je dois pouvoir ouvrir l’accès à ces élément, à une partie (ou la totalité) des utilisateurs ayant accès au projet lui-même.
Plutôt que d’être dans une démarche classique, selon laquelle l’organisation des données dans l’outil conditionne la manière dont on va y accéder, je préfère laisser à chacun la possibilité d’adapter l’outil sans contrainte.

Je n’ai pas envie de me prendre la tête quand je gère les droits d’accès aux projets et sous-projets. Quand je crée un élément, je dois pouvoir choisir simplement entre 3 possibilités :

1. Je suis le seul à y avoir accès.
2. Tous ceux qui avaient accès à l’élément parent bénéficient du même accès à l’élément enfant que je viens de créer.
3. Je donne un droit d’accès particulier à un utilisateur ou un groupe d’utilisateurs que j’aurai préalablement défini.

Tout autre gestion plus complexe, comme par exemple avoir une liste détaillée de chaque utilisateur ayant accès à l’élément, en choisissant des droits différents pour chacun, peut se faire dans une interface d’administration plus complète. L’essentiel est que l’opération de base la plus courante se fasse en toute fluidité.

Les droits

J’ai donc essayé de définir les droits que l’on pourrait affecter aux utilisateurs, pour retranscrire ces contraintes.

Il y a 4 types d’actions possibles :

• La lecture. Cela veut dire qu’on peut voir un élément et son contenu (sauf restriction sur des sous-éléments).
• L’ajout. Ajouter un sous-projet à un projet. Ajouter une liste ou un partage de fichiers à un sous-projet. Ajouter des items à une liste. Ajout des fichiers à un partage. Ajouter un document à un wiki. Ajouter des messages de micro-blogging sur un projet.
• La modification. Changer le nom d’un projet, d’un sous-projet ou d’une liste. Changer le contenu d’un document wiki. Modifier le contenu d’un item de liste.
• L’effacement. Détruire un projet ou un sous-projet, et tout son contenu. Effacer une liste et tous ses items.  Éliminer un partage et tous les fichiers qu’il contient.

On pourrait penser à une action supplémentaire, celle du déplacement. Par exemple pour déplacer un sous-projet, depuis un projet vers un autre. Ou sortir un item d’une liste pour le mettre dans une autre. Mais en fait, cela correspond à un ajout (dans la destination) et un effacement (dans la source).

J’en arrive à un points où je pense pouvoir tout gérer avec 4 niveaux de droits :

• Administrateur. Autorise tous les types d’action sur l’élément (lecture, ajout, modification, effacement). Autorise tous les types d’action sur les sous-éléments (sauf contre-indication).
• Lecture-écriture. Autorise la lecture de l’élément, ainsi que la lecture, l’ajout et la modification de ses sous-éléments (sauf contre-indication).
• Lecture seule. Autorise la lecture de l’élément et de ses sous-éléments (sauf contre-indication).
• Pas d’accès. Sert à «cacher» un sous-élément, pour le rendre invisible aux yeux d’un utilisateur qui a des droits d’accès à l’élément parent.

Cas particuliers : création et suppression

Par défaut, quand on crée un sous-élément, les droits d’accès sont les mêmes que pour l’élément parent. Il est toutefois possible de déclarer le nouvel élément comme «privé» ; seul son créateur peut alors y accéder (cela ne concerne pas les projets, qui ne sont accessibles que si on y a donné explicitement accès).

On ne peut créer un sous-élément que si on a des droits d’administrateur ou en lecture-écriture. On ne pourra donner accès à ce sous-élément qu’aux personnes ayant un accès (administrateur, lecture-écriture ou lecture seule) à l’élément parent. Par contre, il sera possible de sur-classer un utilisateur : quelqu’un ayant un accès en lecture seule sur l’élément parent pourra avoir un accès en lecture-écriture, ou même en tant qu’administrateur, sur le sous-élément.

La suppression est bien plus délicate. Imaginons que l’administrateur d’un projet décide de l’effacer. Que deviennent les sous-projets dont pour lesquels il n’a pas les droits d’administration ? Question identique pour les éléments placés à l’intérieur des sous-projets.
On pourrait imaginer que tous les sous-éléments en question rejoignent un “projet par défaut”  chez leurs créateurs. Mais ce n’est pas d’une folle évidence ergonomique.

Exemples d’utilisation

Voici quelques exemples d’utilisations concrètes que j’ai en tête.

Je crée un projet «Skriv». Je suis automatiquement administrateur du projet. Je crée des sous-projets «GUI» et «IT», chacun contenant une liste de tâches et un wiki.
Je donne accès à ce projet aux autres contributeurs en lecture-écriture. L’un d’eux veut écrire des notes concernant son travail ; mais tant qu’elles ne sont pas terminées, il ne veut pas qu’elles soient accessibles ; il crée donc une page de wiki en la marquant comme privée.
L’un des contributeurs étant chargé du design, il crée un partage de fichiers dans le sous-projet «GUI». Il en est automatiquement l’administrateur, et me donne l’accès en lecture-écriture. Quand les maquettes seront terminées, on y donnera accès en lecture aux autres contributeurs.

Ma femme crée un projet «Vacances» et me donne l’accès en tant qu’administrateur. Je le place dans mon groupe de projets «Personnel». Je crée le sous-projet «Été 2011», et comme ce sont des vacances en famille, je donne accès à mon frère (en lecture sur le projet, en lecture-écriture sur le sous-projet). Comme nous voulons faire une surprise à nos femmes, nous créons un wiki «Surprise» dans le sous-projet, dont nous sommes les seuls à avoir accès.

Edit : Un cas supplémentaire

En réfléchissant, il m’est apparu que les 4 niveaux de droits (admin, rw, ro, no) ne sont pas suffisants. Il faut ajouter un niveau supplémentaire, qui autorise la lecture de l’élément, ainsi que la lecture et l’ajout de ses sous-éléments (sauf contre-indication).

Le cas d’utilisation concret est une buglist. Il faut que certains utilisateurs puissent remonter des bugs, et donc créer des tickets, sans pour autant pouvoir modifier tous les tickets déjà existants.

Si je reformule, il y aurait donc 5 niveau :

• administrateur
• modification (correspond au “lecture-écriture” définit plus haut)
• ajout
• lecture (correspond au “lecture seule” définit plus haut)
• pas d’accès

Avec une spécificité concernant la création de sous-éléments :

• pas d’accès => On ne peut évidemment pas créer de sous-élément.
• lecture => On ne peut pas créer de sous-élément non plus.
• ajout => On n’est pas administrateur des sous-éléments que l’on crée. Les administrateurs de l’élément parent le sont automatiquement sur le sous-élément. On garde des droits en “ajout” sur le sous-élément créé (pour pouvoir commenter le sous-élément créé, par exemple).
• modification => On peut créer des sous-éléments, et on en est administrateur.
• administrateur => On est évidemment administrateur des sous-éléments que l’on crée.

Ça commence à être assez complet, tout ça. Reste à voir si ça reste facilement compréhensible, je ne veux surtout pas faire une usine à gaz. Le seul cas impossible à gérer, c’est l’utilisateur qui n’a accès à une buglist qu’en lecture, mais qui devrait pouvoir commenter les tickets. Enfin si, ce serait possible, mais il faudrait lui donner explicitement les droits en “ajout” sur tous les tickets de la buglist, au fur et à mesure qu’ils sont créés. Mais je suis certain qu’il n’y a aucune nécessité à gérer ce cas-là.