Stockage des devices dans les activités #143
Conversation
…l date. S'il est défini, la fonction retournera la liste des devices de la personne ainsi que la liste des devices qui sont rattachés à sa présence sur la date donnée. Le but ici est de se souvenir des présences passées pour ne pas les migrer vers un autre coworker dans le cas - rare mais probable - qu'un device passe d'un coworkeur à l'autre. Une MAC dans le passée ne doit pas changer de propriétaire
…e sur une journée donnée enregistre désormais toutes les mac associée avec cette présences si elles luis sonr fournies. Par ailleurs, dans le cas où une activité est deja présente en base, la liste des devices n esera pas mise à jour si elle est deja definie : les mac utilisées dans le passées ne sont donc pas mise à jour
…metre GET optionnel nommé 'date'. Si celui ci est renseigné au format YYYY-MM-DD, la route va retourner la liste des macs connus issues de la collection des devices, mais aussi toutes les macs utilisée à la date donnée dans la collection activity. Au passage, la fonction est renommée pour ne plus etre considérée legacy
| @@ -42,10 +52,22 @@ export async function updateMemberActivity(memberId, date, value, overrideValue | |||
| } | |||
|
|
|||
| const set = {value} | |||
| if (overrideValue !== null && overrideValue !== value) { | |||
| if (overrideValue !== null && overrideValue !== undefined && overrideValue !== value) { | |||
There was a problem hiding this comment.
On peut utiliser isNil() de lodash pour savoir si c'est null ou undefined (mais pas false ou 0)
| if (overrideValue !== null && overrideValue !== undefined && overrideValue !== value) { | |
| if (!isNil(overrideValue) && overrideValue !== value) { |
Par contre, est-ce que overrideValue !== value est important ? Que se passe-t-il si on veut remettre la valeur originale (value) ?
Par exemple :
- pour une activité
value = 0.5 - on change avec
overrideValue = 1 - puis on veut rechanger et remettre la valeur originale (parce qu'on aurait fait une erreur par exemple), donc
overrideValue = 0.5 - comme
value = 0.5etoverrideValue = 0.5, rien ne changera etoverrideValuerestera à1
J'ai voulu me servir de la fonction avec manager-web et c'est pour ça que j'ai enlevé cette condition
https://github.com/coworking-metz/tickets-backend/pull/139/files#diff-aba5d5d5ad80e3f9cf07a4d7b9ab8d7fa75c44cb85f54b66e0e18c3114e1671aR50
There was a problem hiding this comment.
On peut utiliser
isNil()de lodash pour savoir si c'estnullouundefined(mais pasfalseou0)
on peut aussi faire overrideValue != null (ça équivaut a tester si c'est null ou undefined en JS) mais le linter est pas content quand on utilise !=et non !== 🫠
Ok pour l'autre partie cf notre conversation IRL de ce matin
Afin de garantir que le lien entre une personne et une présence passée ne soit jamais rompus, on stocke désormais la ou les adresses mac qui ont structuré une présence dans la table des activités. Ainsi, si un ordinateur est vendu, l'échange ne détruira pas la coéhrence de la base
Sur une presence donnée sur une journée donnée, il peut y avoir plusieurs mac concernées (si une personne à une tablette et un ordi par exemple,et utilise les deux alternativement). C'est pourquoi on parle bien d'une liste de devices associés à une présence, meme si dans la majorité des cas cette liste ne contiendra qu'une seule MAC.
Une fois que les présences embarquent les devices, on peut faire appel à cet historique quand on doit recalculer des présences passées, et se fier en prorité à la liste des devices associés à la présence, plutot que sur le lien entre un user et un device.
Ceci est aussi utile dans le cas ou un coworker retire un device de son compte : ses présences passées restent calculables et associées à son compte.
Cette modification va s'accompagner d'une évolution du depot traitement-presences, à venir, qui va lui se charger de communiquer à la route /api/presence la liste des adresses MAC.
A discuter bien sur