Bonjour bonjour !
mise à jour à l’instant pour la version 10, toujours disponible ici : https://test10.dodoc.fr/
La plus grosse modification de cette mise à jour fait suite aux discussions qui ont eu lieu ici et à des échanges que j’ai pu avoir avec d’autres personnes (enseignants et makers notamment) à côté sur la question des permissions et des contenus 
L’objectif étant de trouver une solution qui convienne à toutes et tous, n’hésitez pas à vous manifester ici si ça ne répond pas à vos besoins (ou si c’est trop compliqué et que vous n’y comprenez rien !).
Concrètement, il s’agit pour chaque type de contenu d’avoir la possibilité de définir des référents, et des contributeurs avec les options suivantes :
En détail :
Au niveau de l’instance
Valable pour une installation de dodoc (version application installée, ou version en ligne).
→ Référents
Les admins sont maintenant nommés les référents (avec l’idée de suggérer de les contacter si quelque chose coince). Ils peuvent modifier des réglages critiques de l’instance :
- nom affiché sur la page d’accueil et la barre d’onglet,
- présentation de l’instance,
- email de contact,
- logo affiché dans la barre d’onglet, contenu image/vidéo affiché à côté de la présentation (à venir),
- modification de la liste des référents et des contributeurs à l’instance,
- obliger les visiteurs à créer un compte pour contribuer
- obliger les visiteurs à indiquer un mail pour s’inscrire
- ajouter un mot de passe général
- ajouter un mot de passe pour pouvoir créer un compte (à venir)
- ajouter des familles de caractère
- changer l’emplacement de stockage des contenus (uniquement version application, depuis la fenêtre de l’application)
Ils peuvent également voir les adresses mails des comptes inscrits qui en ont fourni une. Ils peuvent créer des espaces. Ils auront un contrôle sur l’ensemble des contenus de l’instance, privés ou publics.
La liste des admins peut être réglée sur « tout le monde » pour que ces réglages puissent être modifiables par tout le monde (mais ça n’est pas recommandé pour des raisons évidentes). Je suggère plutôt de définir un compte admin, à minima.
À l’installation d’un nouveau dodoc avec un dossier contenu vide, un compte Admin est créé avec pour mot de passe dodoc. Son mot de passe peut et doit être changé (tout cela sera expliqué par un message à rédiger et qui s’affichera au lancement).
Les référents peuvent définir une liste de contributeurs (ou laisser vide, ou ouvrir à tout le monde, cf capture ci-dessus).
→ Contributeurs
Ils peuvent uniquement créer des espaces. Ils ne peuvent pas modifier les espaces qu’ils n’ont pas créé, ni consulter des espaces privés qui ne leur appartiennent pas. Ils n’ont pas accès aux réglages de l’instance. Lors de la création d’un espace, ils sont automatiquement considérés comme référent de cet espace.
Dans un espace
→ Référents
Peuvent modifier le titre, le sous-titre, la description, le statut (public ou privé), la liste des référents et la liste des contributeurs. Peuvent supprimer l’espace, ou créer des projets.
Peuvent enfin voir et modifier l’intégralité des contenus de l’espace (comme un référent de l’instance, mais uniquement dans cet espace).
→ Contributeurs
Peuvent uniquement créer des projets (même logique que les contributeurs d’espace). Ils ne peuvent ni supprimer l’espace ni modifier ses paramètres.
Lors de la création d’un projet, ils sont automatiquement considérés comme référent de ce projet.
Dans un projet
→ Référents
Même logique que pour un espace.
→ Contributeurs
Ils peuvent contribuer des contenus (capturer, importer, créer des remix ou des publications, etc.) mais pas modifier les métadonnées ou supprimer le projet.
À noter que je n’ai pour l’instant pas déployer cette logique au niveau publication, pour éviter de créer trop de complexité dans un même projet, mais c’est envisageable.
Au final
En terme de possibilités, je pense que presque tous les scénarios sont pris en charge : enseignant qui souhaite garder la main sur les contributions des élèves tout en leur laissant une autonomie plus ou moins grande (pouvoir créer des nouveaux espaces ou non, participer aux projets ou pas, etc.). Dans un fablab, cela peut permettre de bien différencier les documentations des machines des projets des usagers, tout en évitant les suppressions et modifications involontaires/indésirés.
On peut par exemple régler un espace pour permettre la création de projets par tous les visiteurs anonymes et inscrits, sans qu’ils puissent modifier/supprimer l’espace ou les projets des autres utilisateurs.
Le revers de la médaille, c’est que c’est nettement plus compliqué à appréhender que la logique de la v9 « role = admin » ou « role = simple utilisateur ». Du coup, il faut mettre le paquet sur les explications – idéallement embarquée pour qu’on puisse facilement avoir un rappel de tout ça en quelques lignes (ou un schéma) directement dans dodoc.
Voilà, j’espère que tout cela est clair, pressé de lire vos retours