Server-tools: [RFC] nouveau décorateur api.groups pour la fonction

Je pense que c'est une bonne idée - la sécurité par l'obscurité (cacher les boutons) ne fonctionne pas.

La question est de savoir où mettre cela. J'ai créé un module OCA Python qui contient une implémentation api.foreach , mais il n'y a pas eu beaucoup de mouvement pour le faire entrer dans le front OCA

Je pense toujours que c'est une bonne idée d'avoir une bibliothèque d'API OCA. @lasley il vous suffit de créer le référentiel en suivant la méthode mise dans la tâche d'instance OCA ("Créer un projet") et de créer le PR.

À propos de cette fonctionnalité,: +1: pour l'ajouter, mais pas avec les décorateurs add_groups et ainsi de suite. Cela doit être géré avec l'héritage: si vous ajoutez un nouveau groupe dans le décorateur sur une méthode écrasée, ce groupe est ajouté à la liste. À propos de la suppression des groupes, vous devez utiliser d'autres techniques comme dans le noyau (par exemple, une autre méthode avec moins de groupes qui appelle la méthode d'origine).

Salut ! Merci pour votre réponse. Une bibliothèque d'API OCA LGTM. Bonne idée !

mais pas avec les décorateurs add_groups et ainsi de suite

Vous avez raison, cela pourrait être simplifié en effet.

À propos de la suppression des groupes, vous devez utiliser d'autres techniques comme dans le noyau (par exemple, une autre méthode avec moins de groupes qui appelle la méthode d'origine).

Pas sûr que cela couvrira tous les besoins, mais nous en parlerons dans un PR spécifique contre le nouveau repo.

@lasley il vous suffit de créer le référentiel en suivant la méthode mise dans la tâche d'instance OCA ("Créer un projet") et de créer le PR.

@lasley , s'il vous plaît envoyez-moi un ping lorsque le dépôt est créé, je vais alors commencer un POC et essayer de terminer le travail dans les prochains jours ouverts (/ fermés).

Je pense toujours que c'est une bonne idée d'avoir une bibliothèque d'API OCA. @lasley il vous suffit de créer le référentiel en suivant la méthode mise dans la tâche d'instance OCA ("Créer un projet") et de créer le PR.

Bon point - à l'époque, je n'avais pas l'autorisation de le faire. Je ne trouve pas ce processus dans l'instance OCA - je vais creuser un peu plus et faire un rapport avec le nouveau dépôt.

Hmmm ok ouais donc je ne trouve pas de processus pour la création du repo, donc j'allais juste aller de l'avant et créer le repo - mais il semble que je n'ai pas les autorisations. @pedrobaeza pourriez -vous créer un

👍 Pour avoir un décorateur qui fait cela. J'ai eu l'idée de créer un décorateur @privileged qui ferait la même chose et qui pourrait être importé d'un nouveau module d'outils dans server-tools.

Mais avoir le décorateur dans une bibliothèque de pip pourrait l'être aussi. Je m'interroge uniquement sur le nom @ api.groups. Cela ne serait-il pas déroutant car cela ne provient pas du module python odoo api?

Salut @ NL66278 ,

Eh bien, à propos de l'espace de nom, je pense que la collision ne sera pas possible, car le nom sera @ oca.groups et non @ api.groups. (ou quelque chose de similaire)

@legalsylvain Je réagissais au premier exemple d'utilisation. Avoir @oca.groups serait génial.

@legalsylvain C'est une bonne idée!

Je préfère garder «oca» comme package d'espace de noms disponible pour tous les packages oca. Nous pourrions nommer ce nouveau package «oca-decorator». Ce paquet fournirait 'oca.decorator' (ou oca.xyz)

from oca.decorator import groups

    @groups(..)
    def function_name():

À propos de groups Je préférerais un nom plus explicite, par exemple allowed_groups .

lmi

@lasley c'est la tâche où le processus pour un nouveau référentiel / PSC est spécifié: https://odoo-community.org/web#id = 264 & view_type = form & model = project.task & action = 468 & active_id = 2

Omg merci Pedro! Pour une raison quelconque, j'ai tout recherché, du projet au repo, mais je n'ai pas pensé à inclure "PSC". Derp!

J'aurai toujours besoin de droits supplémentaires dans OCA GitHub - je n'ai pas le nouveau bouton:

Réessayez maintenant que j'ai changé de rôle.

@lasley @pedro Pourquoi python-oca ? Ce nom n'a pas de sens. Comment prévoyez-vous de nommer le package python?

@lmignon - J'ai demandé des suggestions et c'était la meilleure. Le package python porte le même nom.

Quelle est ton idée? Je suis tout ouïe.

@lasley Ma principale préoccupation est d'éviter la création d'un package python monolytique. Si l'objectif principal est de fournir de nouveaux décorateurs spécialisés pourquoi pas oca-decorator. Le nom doit dépendre de la portée fonctionnelle couverte par le package ou de ce que vous voulez. Au moins, le nom doit avoir un sens. IMO 'python-oca' est trop large.

Je suis bon avec oca-decorator , même si nous aurions besoin de structurer le module un peu différemment, je pense alors que les décorateurs sont au plus haut niveau dans l'espace de noms. À peu près sûr que je l'avais à l'origine, mais nous l'avons repoussé à oca.helpers dans LasLabs / python-oca # 1

Quoi qu'il en soit, il est assez facile de faire ce changement, et je pense qu'il serait préférable d'en discuter dans le contexte du code. Vu que j'ai fait le repo, je soumettrai le PR et inclurons votre suggestion - alors nous pourrons discuter dans le contexte au lieu de ce PR détourné.

@lasley l'espace oca noms

Compris, donc nous voudrions simplement renommer notre package helpers en decorators , puis appeler cela notre schéma pour les trucs Python? Résumé Exemple: oca-package-sub == oca.package.sub

oui: sourire narquois: c'est l'idée.

Dommage que ocapi soit pris: smile_cat:

https://github.com/OCA/oca-decorators/pull/1 soumis

J'ai une question sur la structure de ce code. (peut-être que ma question n'est pas pertinente, désolé)

Fondamentalement, je vois deux façons d'écrire ce code.

A) via un module odoo classique (dans un référentiel existant ou nouveau). donc, pour l'utiliser, nous devons en écrire

from odoo.addons.my_oca_lib_in_module import my_decorator

B) via une lib python.

Il semble que vous parlez tous de la solution «B», et bien sûr, c'est la solution la plus propre.
mais d'un autre côté, je crains qu'une telle technologie ne bloque certains utilisateurs qui n'ont aucune compétence technique pour utiliser des modules qui dépendent de la nouvelle lib oca-python. Je pense par exemple aux personnes qui installent le module via l'interface utilisateur, ou autre via odoo.sh (et demain avec l'appstore OCA, peut-être!). Je ne suis pas sûr que tout le système d'hébergement permettra d'installer facilement une bibliothèque python personnalisée.
il serait dommage que certains utilisateurs n'aient pas la possibilité d'installer des modules OCA, car il y en a dépendant d'une bibliothèque supplémentaire qui n'est pas installable pour certaines personnes.

Il n'y a qu'un seul autre exemple dans l'OCA pour le moment. Le fichier openupgradelib. le code était initialement dans le projet OpenUpgrade, et a été déplacé dans une python-lib externe. Pour moi, ce n'est pas un point de blocage pour l'openupgradelib, car faire une mise à jour est une chose technique.

Qu'en penses-tu ?

Savons-nous comment Odoo.sh gère les dépendances pip?

OMI, c'est à eux de corriger la clé external_depencies dans le manifeste - nous avons beaucoup de modules qui l'utilisent. Je ne pense pas que les modules utilisant cette nouvelle bibliothèque seraient différents de, disons, barcodes_generator_abstract nécessitant barcode

pour ne pas dire Odoo.sh (ou Odoo.hs pour les français) est le prochain Runbot. Pari pris.

😆 Ouais, nous savons où est mon pari sur celui-là

nous avons beaucoup de modules qui l'utilisent (par @lasley)

En effet, mais c'est assez différent. Bien sûr, si vous voulez un système qui gère la génération de codes-barres, vous devez installer barcode lib. idem pour astérisque, etc ...
mais c'est très limité, et peut-être que certains utilisateurs dans le monde n'installent pas de tels modules parce qu'ils ne le peuvent pas ou ne savent pas comment faire. mais il n'y a pas d'alternative. pour utiliser la génération de codes à barres, vous avez besoin d'une bibliothèque de codes à barres.

Ici, c'est différent. Je viens de mettre à jour l'analyse de la source du code OCA. il existe aujourd'hui 4182 modules. (un module présent dans deux jalons est compté deux fois). En revanche, dans tous ces 4182 modules, il n'y a que 274 dépendances python. Ainsi, 94% des modules OCA ne dépendent pas de bibliothèques python externes et peuvent être installés très facilement. des détails :

Si demain, il y a une bonne lib supplémentaire oca python avec des décorateurs utiles (comme celui que nous essayons de décrire dans ce fil qui essaie de résoudre un problème de sécurité), la plupart des modules OCA dépendront de cette bibliothèque, étape par étape.

L'objectif de l'OCA est de promouvoir le travail des membres de l'OCA. Donc, si une telle décision (créer une bibliothèque à installer) réduit la possibilité pour les gens d'utiliser des modules OCA, je pense qu'il ne faut pas aller dans cette direction pour le moment. Nous pourrions créer d'abord un petit référentiel oca-decorator, avec des modules classiques . Et si dans 1/2 ans, il est mature, et si le système de déploiement et d'hébergement est plus mature aussi (*), il sera très facile de mettre tout le code dans une lib externe.

Le code openupgrade a été pendant des années dans le référentiel openupgrade et a été placé dans une bibliothèque externe récemment par @StefanRijnhart. Je pense que ce changement n'était pas grave.

(*): le système d'hébergement et de déploiement a beaucoup évolué ces dernières années. (obtenir du code par bzr, obtenir du code par github, utiliser la technologie de buildout, et plus récemment le déploiement de pypi)

J'aimerais entendre ce que @ OCA / board pense à ce sujet. ce n'est pas seulement une décision technique, c'est aussi une décision stratégique

Maintenant que https://github.com/OCA/oca-decorators est disponible, cette RFC peut s'y déplacer.

@legalsylvain - J'ai initialement soumis un module pour api.foreach avant de le créer en tant que bibliothèque. Jetez un œil à ce PR , et vous verrez pourquoi nous avons abandonné cette stratégie.

L'utilisation de l'API était quasiment impossible lorsque vous commencez à comptabiliser un chemin d'importation de 60 à 70 caractères, et un try / sauf qui doit être placé autour de chacune des importations. Cela rendra l'adoption du module pratiquement nulle - l'importation est plus difficile que la boucle d'enregistrement.

Chose intéressante, notre stratégie try / except échoue lamentablement avec les décorateurs, mais c'est un sujet complètement différent. Encore une fois, j'aimerais qu'Odoo répare sa clé external_dependencies .

@dreispt - y a-t-il un bon moyen de déplacer cette discussion préexistante vers un autre dépôt? Il y a beaucoup de points exposés ici dont je ne suis pas sûr qu'ils seraient transférés de manière fluide.

L'utilisation de l'API était quasiment impossible lorsque vous commencez à comptabiliser un chemin d'importation de 60 à 70 caractères, et un essai / sauf qui doit être placé autour de chacune des importations

Je ne comprends pas quel est le besoin try / except dans cette solution.

Pour utiliser un décorateur oca @ foreach, définissez dans une bibliothèque ou un module oca_api. :

Impacts de la solution Lib
déployer :

• pip install ou via buildout. Limitation Saas.

fichier manifeste:

'external_dependencies': {'python': ['oca_api']}

Fichier Python:

from oca_api import oca

Impacts de la solution du module
déployer :

• pip installer ou télécharger et installer via l'interface utilisateur ou via buildout ou simplement en ajoutant un module dans le fichier addons. aucune limitation saas.

fichier manifeste:

'depends': ['oca_api'],

Fichier Python:

from odoo.addons.oca_api import oca

Ou ai-je raté quelque chose? Si oui, corrigez-moi.

Sincères amitiés.

Je ne comprends pas quel est le besoin try / except dans cette solution.

Le try / except est ce que nous devons faire lors de l'importation de tout ce qui n'est pas le cœur d'Odoo, donc vos exemples seraient les suivants à la place:

try:
    from oca_api import oca
except ImportError:...

try:
    from odoo.addons.oca_api import oca
except ImportError:...

Mais oui, avec le nom de votre module, ce n'est pas aussi mauvais que le mien.

Je pense que cela est dû en grande partie au fait que le module ne s'installe pas dans une base de données et n'est pas encapsulé dans l'environnement comme le seraient la plupart des modules. Cela signifie qu'il fournit des fonctionnalités à des environnements qui n'ont pas explicitement installé le module, et pourrait être considéré comme un problème (sécurité ou autre).

@lmignon vient d'exposer un argument similaire à celui ci-dessus dans https://github.com/OCA/webhook/pull/3#issuecomment -336935193. Je pense que ce sont des conversations parallèles - qui résument essentiellement la façon dont nous fournissons des ensembles de fonctionnalités comme celui-ci.

Personnellement, je pense que foreach d'un module.

Salut @lasley.

Merci! Je pensais que faire des dépendances à un module était suffisant pour supposer que le module est présent, mais en reprenant tout le code OCA, j'ai vu beaucoup d'échantillons de ce que vous parlez. (beaucoup pour report_xls et connecteur).

Je n'ai pas les compétences pour comprendre les problèmes de sécurité hre, en raison d'un module. Pour moi, si le module n'est pas installé, le code du module d'oca_api ne doit pas être appelé. mais peut-être que je me trompe.

Salutations.

Je pensais que faire des dépendances à un module suffisait pour supposer que le module est présent,

Jetez un œil à https://github.com/odoo/odoo/pull/14850 pour plus d'informations

Pour moi, si le module n'est pas installé, le code du module d'oca_api ne doit pas être appelé.

C'est là que réside le problème. Ce n'est pas le cas - Odoo importe tous les modules du chemin addons en mémoire. Pour cette raison, les importations sur le module réussiront dans n'importe quel module, que la personne à charge soit réellement installée ou non.

C'est le cœur d'Odoo, et de manière réaliste, il n'y a pas de contournement. C'est aussi pourquoi je ne co-héberge pas mes clients de la même manière qu'Odoo SA. Je suis curieux de savoir s'ils ont réussi à résoudre ce problème avec Odoo.sh, mais je suppose qu'ils ont une bombe à retardement sur leurs mains dans leur SaaS

Merci pour toutes ces clarifications. C'est dommage que odoo / odoo # 14850 ne soit pas accepté.
Je pense toujours que faire beaucoup de modules OCA en fonction d'une bibliothèque externe limitera sûrement l'utilisation de ces modules. Mais bon, un module ne semble pas vraiment être une solution.
Cordialement et merci beaucoup pour votre perspicacité.

Je ferme ce numéro. (déplacé dans https://github.com/OCA/oca-decorators/issues/7)
salutations et merci pour tous vos commentaires.