Gestion de sélections d’utilisateurs : notion de "classe"

But :

- Sélectionner et inscrire des utilisateurs par groupes dans des cours en tant qu' administrateur.

- Pouvoir gérer en tant qu' administrateur ce que le prof d'un cours peut faire avec une classe.

Questions :

• Une classe peut-elle être une sous-classe d'une autre classe?

• On aurait alors comme pours le cours, un arbre de classes. On peut toujours dire que un dans un premier temps, mais si cela doit être changé un jour, autant préparé les choses en conséquence dans le code et la DB et garder à faire un truc uniforme avec l'arbre des cats de cours.

Idées :

LA CREATION :

Dans l'outils d'admin, à partir de la liste des utilisateurs, vià une checkbox, je peux selectionner qui je mets dans une classe et la créer d'un seul coup--> j'entre alors dans l'interface de gestion de la classe.

Par un profs?? au sein de ses users? (plutot non, il y a déjà les groupes...)

GESTION :

Dans l'admin : un lien vers une page en plus permet de gérer la liste/l'arbre des classes présentes, dès qu'on entre dans une classe, on accède dans une liste de users (même style que celles déjà existantes)

On a donc essentiellement 2 pages (scripts) :

- Une page de gestion des classes, affichage d'arbre à peu près comme dans les cat de cours

- Une page de gestion du contenu de la classe

-ajouter/supprimer un user

-inscrire/ désinscrire la classe à un cours

LES DROITS :

Notion de "visibilités" pour une classe :

- une classe peut être rendue visible aux différents professeurs de la plateforme

- Juste son nom :exemple: "les premières candidatures"

- Son nom ainsi quer la liste des users qui la compose.

- Plus précis encore : ces droits de visiblités pourraient être attribués à certains professeurs seulement ou aux professeurs de certains cours seulement.

Qui peut modifier/supprimer une classe?

- A priori seulement l'admin, via les outils admin, la notion de groupe pour un cours suffit, un prof n'aurait pas à pouvoir jouer avec les classes.

NOUVELLES TABLES :

A priori, deux nouvelles tables sont nécessaires pour gérer cela comme c'est fait dans les groupes :

- Une table pour les classes :

CLASSE : classe_id, name, classe_parent_id, classe_level

- Un table pour savoir qui est dans quelle classe :

CLASSE_REL_USER : Classe_rel_user_id, user_id, classe_id

Vu par moosh, (à fusionner)

But :

Créer des ensembles d'utilisateurs indépendamment de leurs inscription à un cours.

2 concepts à séparer pour simplifier.

• Relations 'classes' <-> 'utilisateurs' <-- membre d'une classe.

• Relations 'classes' <-> 'classes' <- l'arbre

L'arbre sur base de la future classe générique.

La classe sont des noeuds et dans les autres parties de l'appli on gère l'utilisation d'un noeud à la fois. Avec éventuellement une liste des noeuds lors d'une sélection.(la fonction treeToFlat sera bien utile)

Questions:

• Un utilisateurs peut-il être dans plusieurs classes ?

• Un utilisateurs peut-il être dans aucune classes ?

• Si les classes sont des groupes indépendants des cours, quelles sont les détournements que l'imagination de nos utilisateurs peuvent inventer ?

• Groupes de travail inter section, ensemble des assistants d'une faculté, secrétaires de faculté, anciens étudiants, conférenciers, ... Comment ne pas travailler ces cas dans les premiers pas mais rester ouvert à leur probable apparition.

• Dans le cadre d'une création des classes par secrétariat seulement comment font les étudiants qui changent de classe, ou partent ou arrivent après le lancement de leur utilisation ?

• Existera-t-il des relations entre les classes et les catégories ?

Idées :

La création:

Par l'administrateur uniquement (comme pour les catégories)

Mais une « suggestion par utilisateur sans droits » et un système de validation par l'admin pourrait alléger le travail.

Des droits de validation devrait être accordable.

L'inscription des utilisateurs dans les classes

Qui ?

Celui qui en a reçu le droit.

Pour le moment on a peut de granularité pour les sélectionner.

Ça sera

• Le administrateur plate-forme

• Le secrétariat (pour le moment = co-administrateur plate-forme¹)

• Un créateur de cours (un peu fou si l'inscription comme course-manager est libre²)

• l'utilisateur (ben oui, il s'inscrit lui même aux cours, pourquoi pas aux classes)

Comment ?

Auto-ajout

Dans le cas d'une inscription de l'utilisateur par l'utilisateur lui-même, une sélection similaire à celle d'inscription à un cours.

(Une validation par supérieur ou par les pairs est probablement à envisager )

Ajout d'utilisateurs dans une classe.

Lors de son inscription, l'utilisateur pourrait être ajouté à une classe.

Plus tard, ou avec un campus à inscription plate-forme libre mais inscription classe fermée, via une sélection (utilisation d'un panier, oui je reviens un 3eme fois avec ça, preuve que ça me semble intéressant à généraliser³ ).

L'idée serait de pouvoir faire une sélection riche en ajoutant et supprimant des utilisateurs à une liste temporaire jusqu'à validation pour ajout à une classe.

On pourrait ajouter ces utilisateurs sur base de recherche dans la base complète et le supprimer sur base de recherche dans la sélection temporaire.

« recherche de tous les inscrits au cours de Paul Dubois »

« Désélection de 3 lignes sur les 65 trouvées »

« Ajout des 62 lignes à la sélection temporaire »

« Recherche de Francois Desmet »

« ajout du seul compte trouvé »

« ajout de l'utilisateur à l'uid 4738 »

« suppression de la liste temporaire de l'utilisateur 1247 ajouté par l'opération 1 »

« ajout de la sélection temporaire à classe BROL ».

« La classe n'existe pas, ajout des informations liées à cette classe ».

Gestion

Dans l'admin :

Gestion de l'arbre

• A priori pas de multiplication des arbres? Si ?

• Même gestion que les autres arbres

  • ajout

  • suppression

  • renommage

  • déplacement

  • propriétés

Gestion des classes

• ajout,

• suppression,

• renommage,

• valeurs par défaut.

Utilisation des classes

pour inscrire des utilisateurs à un cours.

Dans un outil d'ajout d'utilisateurs à un cours, il est possible les classes comme des présélection. C'est à dire qu'on inscrit les utilisateurs membre d'une classe.

Pour envoyer un message administratif

Dans un outil « annonces » hors cours, accessible à l'administrateur de la plate-forme, les secrétaires, les responsables de catégories, ... la sélection peut se faire selon l'appartenance aux classes au lieu de l'affiliation à un cours

Pour les recherches dans la section administration

L'appartenance à une classe présente un critère utile de sélection.

LES DROITS :

Qui peut ....?

• Les membres,

• Ceux qui on droit d'utiliser les membres d'une classe dans une action vue ci-dessus.

• l'administrateur plate-forme

Que peut-on faire ?

Sur le principe SAMBA. (LIST, READ, WRITE)¹

• Voir que la classe existe (voir son nom dans les listes)

• Voir le contenu de la classe (voir les membres, et leurs propriétés publiques)

• Modifier le contenu de la classe.

Les droits fixés s'appliquent aux enfants. C'est à dire qu'avoir les droits sur une classes ne permet pas d'en modifier l'affiliation ou le nom .. pour cela il faut les droits à la classe parent.

Qui peut changer les droit de visibilité ?

Celui qui a droit en écriture sur le parent.

Qui peut modifier/supprimer une classe?

Celui qui a droit en écriture sur le parent.

Structure des données

NOUVELLES TABLES :

- Une table pour les classes : (les noeuds)

CLASSE : id, classe_label, classe_id, classe_level,

- Un table pour savoir qui est dans quelle classe :

CLASSE_REL_CLASSE_USER¹ : id, user_id, classe_id, rôle, (statut ?)

1Pour gérer la multiplication de ces qualificatifs, je propose une table des propriétés. Contenant 5 champs pour les clés $_cid, $_gid, $_tid, $_uid, $_sid, un champs $id pour l'administration, un champs valeur, un champs nom de propriété. A l'aide des 5 champs en considérant NULL comme valeur pour les ignorer, on peut ajouter autant de propriétés que l'ont désire, à la volée, sans modifier la structure de la base central a chaque nouveautés.

2Comme je l'avais imaginé en son temps pour claroline service, un système de validation semi-bloquante pourrait être mise en place. Par la création d'un user-statut intermédiaire « candidat-créateur de cours » ce statut donne accès à la création de cours mais pas a sa mise en « visible » ou son déplacement de sandbox vers autre chose ou l'inscription d'utilisateurs au cours, ...

3Je proposais le panier d'utilisateurs pour l'ajout à des activités d'administration ou pour la fusion d'utilisateurs.

1Comme ceux sur les quels devraient se baser les droits des outils.

1C bizarre parce que concept = TABLE1 comme nom. voici ce qui est proposé dans les rules .
[NOM DU CONCEPT]_REL_[TABLE1]_[TABLE2]