-
Notifications
You must be signed in to change notification settings - Fork 1
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
Contrôle des accès après la séparation d'EcoTaxa #31
Comments
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: 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:
Qu'en pensez-vous? |
En lisant les réponses de JOI sur la création du projet EcoTaxa depuis EcoPart et les synchros, 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. 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. |
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. |
Sur le fond, je n'ai rien contre laisser, dans cette première phase, les deux applis plutôt liées. 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 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. |
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. |
Les données sont séparées logiquement même si elles ne le sont pas (encore) physiquement. |
@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 :
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
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é.
The text was updated successfully, but these errors were encountered: