Feat(mespapiers): Use queries instead of sessionStorage to manage contactList when creating a new paper

[Merkur39]

Dans la step Contact, nous souhaitons conserver la liste de contacts préalablement sélectionnée plus longtemps que le temps d'une session. Il semble courant que les utilisateurs aillent souvent rechercher les mêmes contacts.

Avec cette nouvelle approche, nous enregistrons juste les ids des contacts présents dans la liste dans le doctype io.cozy.mespapiers.settings, ainsi nous n'avons qu'à fetch ces derniers au besoin.

• Avec l'approche actuelle, il faudrait gérer la synchro des ids dans io.cozy.mespapiers.settings

[Crash--]

J'ai plusieurs questions là-dessus :

• A quoi ça sert ? Qu'est-ce qu'on stocke dedans ?
• On fait maintenant persister des datas dans le localStorage qu'on ne va jamais cleaner, même après un logout (car le logout se fait sur le FQDN pas sur le domaine de ton app). Et donc on laisse trainer des infos perso dans le localStorage d'un browser, c'est pas fou.

Aujourd'hui on s'interdit toutes persistances des données personnelles en localStorage tant qu'on ne résout pas la problématique du logout ou du fait d'activer ça que si l'utilisateur a coché "se souvenir de moi" (aka je suis sur un périphérique de confiance). Mais vu qu'on n'a ni l'un ni l'autre, je suis vraiment pas chaud pour ce changement de code, sauf si arguments contraires.

[Crash--]

Et bien sûr, il faut comprendre le "à quoi ça sert" par "Qu'est-ce qu'on essaye de résoudre comme problème" ?

[Merkur39]

Pour plus de contexte:
Durant la création de papier, une step demande d'assigner un ou plusieurs contacts à ce papier, de base seul son propre contact est proposé.
Il est possible de choisir d'autres contacts (si existants dans cozy-contacts).
A la sélection d'un contact on l'ajoute à la liste présente dans la step actuelle.
Précédemment nous sauvegardions cette liste dans le SessionStorage afin que lors de la création de plusieurs papiers, nous n'ayons pas à rechercher à nouveau des contact préalablement sélectionnés.
Aujourd'hui nous souhaitons persister cette liste même après la fermeture de l'onglet/navigateur.

Je n'ai pas touché aux data stockés, cela reste donc l'objet contact.

J'avais remonter le "problème" pour moi de ne pas permettre à l'utilisateur une gestion plus fine de cette liste, mais je n'avais pas tes arguments, plus bloquant encore.

[JF-Cozy]

Aujourd'hui nous souhaitons persister cette liste même après la fermeture de l'onglet/navigateur

pourquoi ? Pour quel cas d'usage suivant stp ?

edit : vu en zoom, c'est parce qu'on suppose que l'utilisateur utilise l'app toujours dans un même contexte social et familiale, et que donc il y a de grandes chances que les contacts soient toujours les mêmes pour tous les papiers créés. On sauvegarde donc cette liste pour que lors d'une prochaine création de papier, les mêmes contacts soient déjà sélectionnés.

Une nouvelle approche serait plutôt de stocker les id des contacts dans les settings de l'app.

[Merkur39]

Approche revu, j'ai mis à jour la description également

[Crash--]

Et pourquoi ne pas imaginer un "tag" / "groupe" sur les contacts ? Et vu qu'on fait une relation entre une entrée dans un doctype et un autre doctype, ne devrait-on pas utiliser les relationships de cozy-client ? cc @paultranvan

[paultranvan]

Et pourquoi ne pas imaginer un "tag" / "groupe" sur les contacts ? Et vu qu'on fait une relation entre une entrée dans un doctype et un autre doctype, ne devrait-on pas utiliser les relationships de cozy-client ? cc @paultranvan

Je trouve en effet que le UC ressemble bigrement à un groupe io.cozy.contacts.groups "Favourites contacts" en relationships des contacts. Et du coup on aurait :

• Quelque chose de transverse au Cozy, utilisable par d'autres apps
• Editable par le user directement depuis ses Contacts