Cozy-Sharing quelques issues

[Crash--]

En débuguant un peu pour #1227, je me suis aperçu de quelques petits soucis par rapport à cozy-sharing.

Récapitulons un peu ce que fait cette lib :
Au mount:

• Récupère tous les partages pour un doctype (sharings)
• Récupère tous les partages par lien pour un doctype (permissions)
• Récupère la liste des apps (via PermissionCollection.getApps() ...)

On dispatch les sharings / permissions en faisant attention au revoqué / membres etc.
On va ensuite mapé sur les éléments pour :

• Créer un slice "byDocId" qui comme son nom l'indique va pour un ID de document associé son sharing et/ou sa permission
• Créer un slice permissions pour ajouter les permissions
• Créer un slice sharings pour ajouter les sharings
• Créer un slice apps pour ajouter les apps

Si le doctype est different de io.cozy.files on s'arrête là.

Si le doctype est celui des fichiers alors :

• On récupère les docsIds par sharing pour ensuite faire une requête sur all(keys : docsIds) pour récupérer tous les objets io.cozy.files concernés
• De la on fait quelques traitements sur les chemins des objets pour créer un slice "sharedPaths" qui va servir, par exemple à dire, pour indiquer dans un sous-dossier que son dossier parent est partagé.

L'ensemble fonctionne pas trop mal mais quelques remarques :

• On passe par Permissions.getApps() alors qu'on devrait certainement passer par App.all() histoire de bénéficier de cozyclient (policy, store etc)
• Une permission ou un partage peut contenir plusieurs types de documents à l'intérieur. Et peut donc concerner à la fois un io.cozy.files mais en même temps un io.cozy.contacts

"permissions": {
    "groups": {
      "type": "io.cozy.contacts.groups",
      "verbs": [
        "GET"
      ],
     "values": ["Group1"]
    },
    "contacts": {
      "type": "io.cozy.contacts",
     "values": ["Contact1"]
    },
    "files": {
      "type": "io.cozy.files",
      "verbs": [
        "GET"
      ],
     "values": ["Files1"]
    },

Ce qui fait que quand on récupère une sharing ou une permission pour le doctype io.cozy.files, on va se retrouver à mettre dans le slice byIds, "Contact1" et "Group1". On devrait certainement juste se baser sur la permission réellement dédiée au doctype qu'on demande afin de ne pas avoir à gérer des effets de bord ? Est-ce que c'est à cozy-client de gérer ça quand on fait :

permissionCol.findLinksByDoctype(doctype)

Ou à cozy-sharing de les enlever quand on boucle dessus ?

Autre point :
Si je partage l'ensemble d'un doctype via une permission, qu'est-ce qu'on s'attend à mettre dans le slice "byIds" ? Est-ce qu'on met genre "*" pour signifier tout ? null ? Et on contourne ensuite tous les traitements sur les paths pour retourner que tout est partagé ? (sur #1227 j'ai mis un tableau vide pour éviter de crasher nos apps dans un premier temps car c'est un cas qui arrive aujourd'hui avec le GL)

[JF-Cozy]

Les partages sont maintenant créés avec les règles de partage les plus élevée (readWrite), mais chaque membre du partage peut avoir une restriction readOnly.

On devrait donc faire disparaître la notion obsolète de one-way / two-way pour la remplacer par la notion booléenne readOnly (qui si elle est fausse est un readWrite implicite).

Ceci impliquerait de modifier :

• les méthodes qui retourne un *-way ou un object contenant *-way => pour retourner à la place un readOnly: true|false
• les composants qui testent un *-way pour afficher un résultat => tester plutôt le readOnly

[JF-Cozy]

Lors d'un partage non approuvé, cela créé un sharing shortcut. Même si l'expéditeur a créé le partage en two-way, le destinataire se voit être en one-way car actuellement on se base sur les rule du partage pour définir *-way. Or il n'y a pas de rule dans un tel cas, on décide donc par défaut de choisir one-way.

On devrait se baser sur le readOnly des membres plutôt que les rules(voir issue au-dessus #1229 (comment))