-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stockage de donnée utilisateur par les fundations #245
Comments
Ça me paraît honnête de vouloir garder une trace, surtout pour des ecocups ou des places. Si je ne m'abuse, on pourrait aussi utiliser cette table pour stocker des préférences des clients spécifiques aux utilisateurs/assos ? Est-ce qu'on ajoute pas le |
hum pour l'app_id je ne sais pas... Si tu as deux mozart ou mozart et pauline, tu veux que les deux puissent échanger les valeurs... |
Moi je dit qu'à partir du moment ou tu as donné le droit à une application d'accèder aux data, tu trust l'application. Ou alors il faut ajouter le app_id, mais laisser le choix à l'application de protéger la donnée pour elle ou pas. |
Je pense que l'app_id ca peut etre pas mal, mais toutes ces histoires de droit ca commence a être compliqué pour l'utilisateur. |
L'utilisateur final s'en branle... C'est plus pour le développeur. Matthieu GUFFROY Le 22 septembre 2013 17:36, Thomas Recouvreux [email protected] a
|
Et tant que j'y suis, je suppose que quand tu dis que c'est compliqué c'est Le 22 septembre 2013 17:40, Matthieu Guffroy [email protected] a écrit :
|
J'aime bien l'idée du pop up, a travailler cependant parce que par exemple pour Pauline c'est a un admin de donner les droits, pas juste à celui qui a installé l'appli, on pourrait imaginer que Pauline fait une espece de requette de droits, et que quand le mec se connecte dans scoobydoo il a plus qu'a accepter. C'est important que ca reste simple pour l'utilisateur parce que on est pas cencé être les seuls à utiliser scoobydoo. Pour l'historique je fais comment alors ? |
Pour #234, il est apparu que ce n'est pas à payutc de gérer des points très spécifiques liés spécifiquement à certaines associations.
Néanmoins il est légitime que certaine association veuillent stocker des informations sur les utilisateurs utilisant le service payutc.
Le point avait été également soulevé par Comet pour stocker un nombre de billets (place d'estu).
@trecouvr et moi même proposons donc l'implémentation suivante d'un stockage de données utilisateurs par les fundations.
Service: USERDATA
Methodes:
getDataByBadge($fun_id, $badge_id, $key)
getDataByLogin($fun_id, $login, $key)
setDataByBadge($fun_id, $badge_id, $key, $value)
setDataByLogin($fun_id, $login, $key, $value)
deleteDataByBadge($fun_id, $badge_id, $key)
deleteDataByLogin($fun_id, $login, $key)
Structure table: t_userdatafun_udf
udf_id
fun_id
usr_id
udf_key
udf_value
udf_inserted
udf_removed
Point interne à discuter ( @apuyou ), lors d'un set est-ce qu'on update l'ancienne valeur (si elle existe) ou conserve-t-on l'historique en mettant la date du removed et un insérant la nouvelle ? (Je suis pour ce point, au cas ou certaines assos stockerait des données "importantes" (ça reste relatif). Après si c'est un nombre d'écocup... ça va peut être juste alourdir la table...
Mais bon une écocup, pour l'assos ça vaut de l'argent, et pour comet des places d'estu aussi... Donc il est peut être bon de pouvoir voir ce qu'il c'est passé si un jour elles (les assos) ont des problèmes...
The text was updated successfully, but these errors were encountered: