search

elefan-grenoble / gestion-compte

Gestion des membres et du bénévolat à l'éléfàn, super marché coopératif Grenoble
https://lelefan.org
GNU General Public License v3.0
45 stars 42 forks source link

Gestion du boitier fournisseur #239

Closed museOnSite closed 5 years ago

museOnSite commented 5 years ago

codebox_diagram

CodeBox

Correspond à un boitier physique.

CodeValue

Liste des codes qui ont été générés (normalement un seul actif par boitier)

CodeAccessForShifter

Entité facultative pour un boitier. Configuration du boitier qui permet de donner accès au code aux bénévoles faisant un créneaux. C'est le fonctionnement actuellement en place. L'idée est de déplacer les 2 configurations qui sont dans parameters.yml dans cette entité (configurations définissant combien de temps avant et après le créneau un bénévole peut accéder au code). Le champ can_generate permet de définir si un bénévole peut générer un nouveau code pour ce boitier.

CodeAccessForShifter

Liste de codes personnalisés permettant de récupérer le code (via SMS et éventuellement espace membre).

Avantage de ce modèle

Arakmar commented 5 years ago

Je trouve ça vraiment propre :)

Dans CodeBoxAccessByCode, on pourrait rajouter (optionnel) des plages horaires ou des jours de la semaine pour plus de sécurité ? On peut aussi essayer de tracer les demandes de codes qu'on a reçues ?

Pour CodeBoxAccessForShifter si j'ai bien compris c'est lié à un Job ou à un Shift ?

museOnSite commented 5 years ago

Oui pour les plages horaires j'y ai pensé aussi me je me disais qu'on pouvais le rajouter après pour aller plus vite. Le CodeBoxAccessForShifter c'est lié à ni l'un ni l'autre, c'est le fonctionnement actuel. Tu détecte si un bénéficiaire a un créneau en cours, et si oui il a accès au code.

janssens commented 5 years ago

C'est bien ce que j'avais en tête aussi. Par contre j'avais imaginé gérer l'accés (user ou code) et la génération (user) par une formule conditionnelle sérialisée en BDD On fait une interface html js qui permet de créer et éditer cette formule. du style SI (User.ClosestShift.startDate > CurrentDateTime - 15min, User.ClosestShift.endDate + 1h > CurrentDateTime) OR (User.Role contain ROLE_ADMIN) ... Ou SI (CurrentDay in (0,1,2,3,4,5,6))... Ou encore SI (User.formation in (ouverture, fermeture)) ... C'est plus chiant à coder mais plus évolutif et plus souple.

Et comme dit @Arakmar il nous faut un log des accés (réussi ou non)

janssens commented 5 years ago

Et comment un membre s'adresse t'il à un code box quand il demande le code par sms ? Ne manque il pas un "slug" ou un "shortname" sur l'entity code box ? "envoie code au 82121" "envoi codesoussol au 82121" ?

museOnSite commented 5 years ago

C'est une bonne remarque. Par contre je pense qu'il ne faut pas mettre le "slug" au niveau du CodeBox mais au niveau du CodeBoxAccessForShifter. En effet, les fournisseurs avec un code personnalisé enverront leur code et non "CODE".

Je pense même qu'il faut mettre cela dans une entité séparée car les autres coops n'auront pas nécessairement une API SMS.

Au sujet du DSL que tu proposes pour configurer les conditions d'accès au code pour les bénévoles, je pense que c'est une très bonne idée, par contre c'est plus complexe, donc à mettre en place dans un deuxième temps.

Voilà le nouveau modèle que je propose. C'est sûr que ça fait pas mal d'entités ^^ J'ai rajouté aussi l'historisation des SMS reçus, pour l'instant j'ai juste mis un champ ignored indiquant que la demande n'a pas fait l'objet d'une réponse avec le code d'un boitier. codebox_diagram

janssens commented 5 years ago

Ok pour faire en deux temps très bien.

C'est vrai que les fournisseurs n'utiliserons pas le slug. Mais si ils le font par erreur, comme ils ne vont pas être reconnu comme membre ça ne pausera pas de problème. Un sms ingnored.

Je ne pense pas que j'aurais dessiné un modèle pour l'API SMS. J'aurais mis les identifiants (url, key, ...) en paramètres (c'est de l'environement) et j'aurais utilisé une classe abstraite, de laquelle chaque coop pourra coder la classe fille qui correspond à l'api qu'elle choisie. Nom de la classe fille à utiliser en paramètre aussi.

Donc sans doute le slug au niveau du CodeBox et une liste de SMS reçu simplement en ManyToOne vers le codeBox. Donc il reste tes deux entities bleues, une seule jaune pour les SMS reçu et deux vertes, une pour les membres une pour les non-membres. Finalement comme ton premier diagramme mais avec ReceivedSMS en plus.

Et tu peux avoir un lien nullable entre le SMS et un utilisateur. (soit l'utilisateur existe, soit non)

museOnSite commented 5 years ago

Conf API SMS

Ok pour mettre en conf. Ce sera plus rapide que de créer une entité. Après je me disais que ce serait bien qu'un maximum de configuration se fasse via l'interface (admin panel). Je pense que c'est plus simple à l'utilisation, surtout pour les autres coops. Mais c'est ma vision, c'est discutable.

Modèle

T'as raison je me suis un peu emballé sur le nombre d'entités ^^ Par contre je maintiens le slug pas au niveau de la CodeBox mais de la CodeBoxAccessForShifter, c'est là où il a du sens.

codebox_diagram

janssens commented 5 years ago

Super comme ça ! ok pour moi.

Pour la configuration je dirais de laisser en param ce qui est lié à l'environement (mdp mysql, apikey, ...) et de mettre accessible en réglage front ce qui peux changer (un email, une url, une couleur, un wording ...) J'ai fait une fois avec symfony une conf éditable coté front, j'avais utilisé une entity "conf" avec un singleton. bof. Sur magento que j'utilise beaucoup, c'est un système de clef valeur. (un peu comme parameters.yml, mais en base) Peut-être @Arakmar sera de meilleur conseil

janssens commented 5 years ago

PS: Tu utilises quoi pour tes diagrammes ?

museOnSite commented 5 years ago

J'utilise yed, logiciel gratuit cross-plateform.

Si on est ok sur le modèle je vais essayer d'attaquer demain le dev des entités. Gaëtan tu t'occupes de l'intégration de l'API SMS ?

Arakmar commented 5 years ago

Je vous rejoins la dessus, le top ça serait d'avoir tous les paramètres "métiers" en base. J'avais déjà étudié la question l'année dernière c'est tout à fait possible en étendant le système de paramètres de Symfony.

Sinon nickel pour le modèle :)

Si vous avez besoin d'un coup de main, hésitez pas

janssens commented 5 years ago

Yes je prend l'api sms.

museOnSite commented 5 years ago

J'ai créé la branche feature/#239-code-boxes et l'entité CodeBox.

@Arakmar Si tu veux tu peux commencer à implémenter l'interface d'administration des CodeBox ?

J’enchaîne avec les autres entités.

Arakmar commented 5 years ago

Ok j'essaie de m'en occuper dans la soirée.

Arakmar commented 5 years ago

Du coup j'ai fini toute la partie admin et les ajustements pour la homepage et le Voter. Vous me direz si ça vous va !

museOnSite commented 5 years ago

Au top @Arakmar !

Du coup t'as tout adapté le code existant ? En gros on pourrait la déployer en l'état en prod théoriquement ?

Arakmar commented 5 years ago

Normalement oui tout fonctionne ! Je voulais quand même faire encore quelques tests au niveau des droits et des pages pour générer les codes.

janssens commented 5 years ago

On ferme ça ?

museOnSite commented 5 years ago

Il manque encore l'API SMS non ?