Compte-rendu de réunion développement à Nantes

La discussion a tourné principalement autour de l’organisation des données. La première étape a été de définir ce qui faisait le cœur de l’application, agencé en modules.

Le cœur de l’application et les modules

Le cœur est constitué de :
– installation (qui pourrait être considérée comme une application à part)
– authentification
– acl (permissions)

Les modules indispensables (en tout cas à mettre par défaut)
– agenda des ressources
– sites (territoires, EPN, salles)
– utilisateurs (profils)

Les modules optionnels
– équipement (inventaire)
– maintenance
– usages
– ateliers (parfois nommé initiations)
– projets (qui n’existe pas encore)
– parcours pédagogiques
– évaluation

Les modules à mettre de côté pour le moment, en attendant la possibilité d’adjoindre des greffons à l’application
– partage des initiations (une belle idée à reprendre plus tard)
– hébergement de sites
– prêt de matériels

Dans chaque module

Les modules devront contenir :
– procédure d’installation (schéma base de données, liste de dépendance si nécessaire)
– procédure de configuration
– code métier
– code statistique
– documentation

Le planning des ressources

Le planning des ressources doit pouvoir être autonome. Il comprends au minimum :
– date, heures, récurrence
– participants (nombre, éventuellement noms en texte libre)
– type d’activité

• sessions (collectives) : ateliers, réunion, etc.
• accès libre
• accès accompagné
• projet
• maintenance

Mais on peut y rattacher aussi :
– des participants, avec statut possible d’animateur, observateur ou simple participant (c’est un lien vers la liste des utilisateurs)
– des ressources

• un sites (EPN ou salle ou groupe d’ordinateurs)
• un ou plusieurs ordinateurs de ce site

On a donc des tables :
– session-users (dont quel poste, car on n’a pas l’information aileurs)
– session-workshop
– session-resource

• session-ressouce-computers
• session-resource-site

A propos d’autres tables

Table profil des utilisateurs : prévoir le minimum vital.

Table sites : elle pourrait recouvrir un territoire, un organisme (genre EPN), une salle ou un groupe d’ordinateurs. Le tout avec une hiérarchie.

Table config : avec la config du cœur et de tous les modules. Ne resterait dans un fichier config que le lien vers la base de données.

Pour aller vers une architecture plus modulaire, on sépare le parcours de l’utilisateur et l’inscription aux sessions ou utilisations.

A propos des ACL

Franchement, actuellement, c’est compliqué.

Après prise de tête entre les mains, il est convenu que les droits doivent être liés à des actions (et pas seulement lecture, écriture).
– module concerné
– à qui on attribue le droit : un utilisateur ou un type (anim, directeur) d’utilisateurs d’un site (territoire, EPN)
– action concerné (par exemple lire, modifier, changer mot de passe, exporter...)
– sur quoi : pour faire simple pour le moment : type d’utilisateurs (ou tous) d’un site (territoire, EPN, salle) (ou tous)

Il faut prendre des exemples et faire pour le moment au plus simple pour faire de manière plus compréhensible au moins ce qu’on arrive à faire actuellement.

Par exemple, on peut s’en sortir en créant des TAGS pour chaque action de chaque module en fonction des droits. Un peu comme l’existant :
– MODULE_ACTION_CREATE
– MODULE_ACTION_READ
– MODULE_ACTION_UPDATE
– MODULE_ACTION_DELETE
– MODULE_ACTION_LIST

Dans mon exemple ci dessus on exagère un peu, c’est juste pour donner une idée de l’idée. On peut très bien commencer avec READ et UPDATE

Divers

Quand Loïc aura avancé dans son autoapprentissage de Symfony, Marc pourra expliquer plus avant comment symfoniser des modules au fur et à mesure.

Discussion sur l’authentification par la base mysql ou ldap. Pas terminé, mais ça paraît possible.