getMyGroups

[mattgu74]

Il faut pour un user, dire quels sont ces groupes.

[ejpcmac]

J’ai pas eu trop le temps de coder jusqu’à aujourd’hui, mais j’ai réfléchi à la façon d’implémenter ça et ça va être assez rapide.

On est bien d’accord, il y a trois types de groupes pour l’instant :

• email
• CAS
• CAS UTC (Ginger)

@mattgu74, il faudra que tu m’expliques rapidement comment vérifier qu’un user est valide pour un CAS donné, et le fonctionnement de Ginger.

Pour l’instant, getMyGroups() récupère la liste des groupes dans la BDD*, puis pour chaque groupe appelle la fonction isInGroup().

• Là aussi j’aurais besoin d’une précision : vu qu’on n’est pas dans un contrôleur, comment récupérer le Repository UserGroup pour faire une requête ?

isInGroup() se sert du champ informations (contenu en JSON) pour établir le type du groupe et appeler la fonction de vérification adéquate (pour le mail, c’est juste une regex, mais pour le CAS et Ginger, faut faire des vérifs).

[mattgu74]

Alors le CAS, ce n'est pas ton problème.
Toi tu as juste besoin de Ginger et du login "UTC" de l'user. (#21) Actuellement on ne le fait pas.

Pour ce qui est de Ginger, l'utiliser est maintenant assez simple (après le merge de la PR #17, et surement de la résolution de #18).

Tu peux t'inspirer de ce fichier : https://github.com/payutc/onyx/pull/17/files#diff-5a62a84c173ecbcec538b22317917e46R12

use Ginger\Client\GingerClient;

...

$ginger = new GingerClient("fauxginger", "http://localhost/faux-ginger/index.php/v1/");
$userInfo = $ginger->getUser($loginUTC);   // LE loginUTC n'existe pas pour l'instant voir #21

Ensuite $userInfo contient un objet, avec les champs que tu peux trouver dans le faux ginger
https://github.com/simde-utc/faux-ginger/blob/master/users.php

Le is_cotisant ainsi que le type devrait t'intéresser.

[mattgu74]

Tu pourrais peut être commencer par un groupe "ALL", qui implique un filtre vide.

[ejpcmac]

Le groupe "ALL" dans ce cas ne sera pas un filtre vide, mais de type "all", et constraint vide. Je m’en charge.

Edit : c’est fait.

[ejpcmac]

@mattgu74 Peux-tu me rappeler les différents cas que l’on peut rencontrer pour les groupes utilisant Ginger ?

[mattgu74]

COTISANT / NON COTISANT (BDE)

Pour les types, il y'a :
etu
etuescom
pers
persescom

(Il y'en a peut être d'autre je ne sais plus si on distingue les
doctorants, les masters etc...)
(Et je ne suis pas sur a 100% de la syntaxe, mais ça au pire tu l'intégres
dans la requete)

Genre pour faire un groupe etu il faut "etu || etuescom" un groupe etu
cotisant "(etu || etuescom) && cotisant"

Matthieu GUFFROY

2014/1/3 ejpcmac notifications@github.com

@mattgu74 https://github.com/mattgu74 Peux-tu me rappeler les
différents cas que l’on peut rencontrer pour les groupes utilisant Ginger ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-31529647
.

[mattgu74]

Et j'oubliais les distinctions non lié à ginger mais à l'adresse mail.

exemple: Tremplin

[ejpcmac]

Ok, nickel.

Pour tremplin ce sera un groupe de type "email" : contrainte basée sur une regexp, à moins qu’ils ne veulent nous filer une liste. À ce moment là je créerais un type "email_list", avec en contrainte un tableau d’adresses valides.

[mattgu74]

Et dans ta syntaxe tu as prévu quelque choses pour faire des "OU" et des
"ET" ?

Le 3 janvier 2014 16:41, ejpcmac notifications@github.com a écrit :

Ok, nickel.

Pour tremplin ce sera un groupe de type "email" : contrainte basée sur une
regexp, à moins qu’ils ne veulent nous filer une liste. À ce moment là je
créerais un type "email_list", avec en contrainte un tableau d’adresses
valides.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-31530136
.

[ejpcmac]

Non, pas de la façon dont tu penses.

Pour l’instant je suis parti du principe que le champ "informations" d’un groupe est un objet JSON avec deux éléments :

• $infos->type qui donne le type de groupe ("all", "email", "ginger", …)
• $infos->constraint qui contient la contrainte correspondant au groupe (rien pour "all", une regexp pour "email", et là je suis en train de voir pour ginger)

Pour l’instant, la fonction User->isInGroup($group) regarde de quel type de groupe il s’agit, et retourne la valeur de la fonction correspondant. (Par ex, si c’est un groupe "email", ça retourne la valeur de retour de la fonction isInEmailGroup($pattern))

Mais pour un groupe de type email acceptant par ex des adresse "*@utc.fr || *@etu.utc.fr", le ou se fait sans problème dans une regexp. Pour Ginger, si tu veux avoir un seul et même groupe etu qui regroupe ceux de l’UTC et ceux de l’ESCOM, c’est faisable. Mais je ne sais pas si c’est judicieux.

[mattgu74]

Hum, enfait c'est vrai que le "OU" on s'en tape pas mal, vu que dans les tarifs on peut mettre différents groupes et que ça fait déjà un "OU".

Du coup c'est surtout la possibilité de faire les "ET", genre "Cotisant ET Etu ET Escom" => "Etudiant Cotisant Escom"

[ejpcmac]

Pas de problème pour ça, vu que la contrainte pour les groupes Ginger va en fait contenir une liste d’attributs dont la valeur est à vérifier pour confirmer l’appartenance au groupe. Donc si dans cette liste, tu as etu et cotisant, les deux seront vérifiés par la fonction User->isInGingerGroup($attributes);

Avec ce principe on pourra même avoir le tarif explicite « n’est pas cotisant » (vérifier que is_cotisant == "false"), ou s’en moquer (ne pas vérifier la valeur de is_cotisant).

[ejpcmac]

Au fait, quand tu fais un $userInfo = $ginger->getUser($login); si $login n’existe pas, que renvoie getUser() ? Histoire que je fasse une vérification quand même, ce serait bête que ça plante pour ça.

Edit : et le champ $loginUTC, quand il existera, contiendra quoi si l’user n’est pas UTC ? $loginUTC = "" ? (Pour éviter d’appeler Ginger pour rien…)