Contrôle des accès après la séparation d'EcoTaxa

[jiho]

@laurent-n :

Dans la cadre de la séparation, se pose le problème de la gestion de la visibilité.
J'ai quelques question pour vous.

Actuellement la visibilité est gérée par :

• Le fait d’être propriétaire du projet particule
• Les dates des plus ancien samples qui rendent les projets plus ou moins visible à tous au fil du temps
• Le fait d’avoir des droits en écriture ou en lecture sur le projet Ecotaxa associé

Pour les 2 premiers, pas de problème, par contre le 3ème est lié à EcoTaxa et pose problème.
Il me parait difficilement envisageable de faire des requêtes sur les diverses instances Ecotaxa en temps réel.
Option 1) on fait une réplication périodique des privilèges Ecotaxa, mais on a potentiellement le problème de ne pas être sûr que les gens dans EcoPart sont bien les mêmes gens dans EcoTaxa (cf § gestion des login)
Option 2) on gère une table de privilège associé à chaque projet EcoPart qui sera initialisé lors du split avec les privilèges présents dans EcoTaxa
==> Je penche pour l'option 2

Gestion des utilisateurs EcoPart :
Lors du split j’imagine importer les utilisateurs qui sont en lien avec un projet EcoPart avec leur privilèges.
Aujourd’hui pour créer un projet EcoPart il faut avoir le privilège Project Creator de EcoTaxa.
Que fait-on pour la création de nouveaux utilisateurs ?
Comme dans EcoTaxa, ils se créent tout seul ? Risque d’usurpation d’identité si les droits d'ecotaxa sont ramené automatiquement !
On les réplique depuis la base EcoTaxa ? ça peut avoir du sens tant qu’il n’y en a qu’une.

Définition de visibilité:
@laurent-n :
Sur des données EcoPart il est possible de

• Voir qu'elle existe (aucun privilège)
• Afficher des courbes de concentration particulaires
• Afficher des courbes de concentration Taxo
• Exporter les données de concentration particulaires plus ou moins détaillées
• Exporter les données sur la classification des taxon plus ou moins détaillées allant de concentration par tranche de 25m à liste des objets

Il y a un système avec 3 dates qui pemet de donner des niveau de visibilité a tous le monde au fil du temps, auquel s'ajoute des privilèges issus des droits sur le projet EcoTaxa associé.

[jiho]

Pour les données UVP, l'import se fera exclusivement via EcoPart et l'objectif à terme est que EcoPart pousse les données image vers EcoTaxa. Donc la gestion des droits d'accès à l'ensemble de données particules + images doit se faire complètement côté EcoPart et pas côté EcoTaxa.

À terme cela veut dire qu'il faudra que lorsqu'un nouvel utilisateur EcoPart crée un projet avec une composante image et importe ses données:
il soit créé en tant qu'utilisateur Ecotaxa
un projet EcoTaxa soit crée avec lui comme manager et contact
les données y soient poussées.

Ensuite, si des permissions sont rajoutées côtés EcoPart, ces utilisateurs devront également être poussés vers EcoTaxa et leur permissions mises à qq chose de compatible (manager ou annotator probablement; il faut définir un mapping des rôles EcoPart vers les rôles EcoTaxa).

On peut tout à fait imaginer que des personnes supplémentaires soient rajoutées côté EcoTaxa mais pas côté EcoPart et dans ce cas elles n'auront accès qu'aux données d'images, via EcoTaxa, pas à celles de particules et voilà. C'est un use case crédible.

Ce que je vois comme problématique là c'est:

• la création d'utilisateurs automatique côté EcoTaxa: il n'y a pas de point d'entrée API pour, il ne serait dispo que pour un app admin ou user manager, quand EcoTaxa sera à IFREMER ce sera un autre bordel.
  -> à discuter; une possibilité est de dire que l'étape de création d'user doit être manuelle des deux côtés. Il ne va pas non plus y avoir 15,000 utilisateurs d'EcoPart qui auront des images...
• que se passe-t-il si le project manager côté EcoPart est passé à viewer ou viré du projet par un autre projet manager côté EcoTaxa...
  -> de toute façon, que ce soit dans un sens (EcoPart->EcoTaxa) ou un autre (EcoTaxa->EcoPart), il faudra une logique de synchronisation. Je suggère que pour les données UVP, cette logique soit "EcoPart a raison". Donc si qqun est supprimé côté EcoTaxa et pas côté EcoPart, il est automatiquement ré-ajouté à la prochaine synchro (dans un intervalle à déterminer). Ce sera aussi le cas de toutes les autres données (métadonnées des profils, etc.) donc c'est logique que ça marche pareil pour les users.

Qu'en pensez-vous?

[laurent-n]

En lisant les réponses de JOI sur la création du projet EcoTaxa depuis EcoPart et les synchros,
Je me questionne sur la pertinence de séparer les bases EcoPart et EcoTaxa ?
Le fait d'avoir des systèmes qui gère des droits avec des identités non fédérées me semble introduire des problèmes.

Est ce que les raisons qui nous conduisent aujourd'hui à envisager plusieurs instances EcoTaxa ne risque pas de se poser rapidement avec un EcoPart unique et donc de se retrouver à terme à gérer un EcoPart par EcoTaxa et donc on se retrouverai aujourd'hui à chercher des solutions à des problèmes qui ne se poserais pas si on laissais les bases EcoPart et EcoTaxa liées.
Peut être la piste d'un aggregateur d'EcoPart qui aurait la partie publique similaire à ce qu'on à aujourd'hui et qui serait alimenté par des synchro sélective serait intéressante.
Ou un système de réplication sélective multimaitre.

Pour l'instant j'ai travaillé sur la séparation des logiciels et la mise en place de tests, là je commence à analyser plus précisément les impacts de séparer les bases.
La semaine dernière on a discuté avec Laurent S. d'un moyen de récupérer les données sample et taxe et on a conclu qu'une user EcoPart aurait le droit de tout voir et qu'il fallait que je verrouille du mieux possible coté EcoPart la création du lien avec le projet EcoTaxa.

[grololo06]

Méthodo: Effectivement on ne peut pas appliquer dans ce projet d'assignation multiple, comme on fait pour EcoTaxa quand il y a des points à discuter. Je crains que l'effort pour canaliser les discussions ne finisse dans les oubliettes.

[grololo06]

Sur le fond, je n'ai rien contre laisser, dans cette première phase, les deux applis plutôt liées.
Mais, comme posé ici: #23 (comment) , ligne "An interface file for data/events to/from EcoTaxa" il faut que l'interface vers EcoTaxa soit isolée. En terme techniques, elle ne prend que des données de base (JSON-compatible) et ne renvoie que des données du même acabit, qu'on peut simuler (mock) pendant les tests.
Conséquence bénéfique: lors des évolutions d'EcoTaxa, il suffira de regarder cet "interface file" pour savoir l'impact sur EcoPart d'éventuels changements.

Evidemment si cet "interface file" ne contenait que des appels à l'API ce serait optimal, mais on peut envisager d'autres méthodes d'accès pour l'instant.
Je vois https://github.com/ecotaxa/ecopart/blob/master/py/appli/part/ecotaxainterface.py qui est pas mal, mais:

• GetObjectsForTaxoHistoCompute: il faut passer en paramètre prj.proj_id car prj est un objet complexe SQLAlchemy qui ne passera pas en JSON.
• GetObjectsForRawExport : il y a une jointure DB entre une table EcoPart et une table EcoTaxa donc ça n'est pas isolé. Par contre on peut ré-écrire la query pour ne passer qu'une liste de sampleid référencée dans EcoPart. List[int] c'est OK niveau JSON.

Je m'attends à voir dans le fichier d'interface plein d'autres primitives, qui correspondent aux "besoins" d'EcoPart en matière de données/actions EcoTaxa.

[laurent-n]

Dans GetObjectsForTaxoHistoCompute c'est volontaire de passer l'objet car j'imagine que le projet contiendrai la référence de l'instance, cette fonction est libre de prendre les morceaux qu'elle à besoin pour les mettre dans l'appel à l'API

GetObjectsForRawExport pour l'instant c'est une jointure, l'idée est que ça deviendrai un appel API mais du point de vue de la fonction appellante ça serait transparent.

Pour la partie des droits soulevée dans cette issue c'est pour l'instant géré par des jointures, ce qui pourrait persister si on déporte la gestion des droits dans EcoPart, donc pas intéressant de le transformer en code python moins efficace.

La façon dé découper depend de l'objectif à la fin sur certains points. Par exemple si c'est découplé les noms des projets EcoTaxa seront dupliqué dans la table des projets EcoPart alors qu'aujourd'hui c'est fait par une jointure. Il n'y a pas d'interet à mettre un tel appel dans une module d'interface puisque à la fin ce n'est pas l'interface qui existerai.

Il faut décider ce qu'on fait à court terme en terme de split. Est ce qu'on veut absolument séparer les bases parce que vous êtes sur que c'est ce qu'il faudra faire à terme. Si vous n'êtes pas complètement sur ou pas totalement clair sur certains points, rester sur une base partagée serait peut être mieux à court terme.

[grololo06]

Les données sont séparées logiquement même si elles ne le sont pas (encore) physiquement.
Je propose, pour l'écriture des en-têtes des def du fichier d'interface, de considérer le pire cas, où les 2 applications sont sur des machines distinctes avec une connectivité non-fiable (Internet). D'où mon exigence sur le JSON-compatible (et le fait que les appels de ces primitives peuvent échouer temporairement).
Effectivement ça peut apparaître comme un gaspillage de ressources, mais toute séparation a un prix.