Server-tools: [RFC] nuevo decorador api.groups para función

Creo que esta es una buena idea: la seguridad por oscuridad (ocultar los botones) no funciona.

La pregunta es dónde poner esto. Hice un módulo OCA Python que tiene una implementación api.foreach en él, pero no hubo mucho movimiento para ponerlo en OCA

Sigo pensando que es una buena idea tener una biblioteca API de OCA. @lasley solo necesita crear el repositorio siguiendo el método puesto en la tarea de instancia OCA ("Crear un proyecto") y hacer el PR.

Acerca de esta función,: +1: para agregarla, pero no con los decoradores add_groups y así sucesivamente. Esto debe manejarse con la herencia: si agrega cualquier grupo nuevo en el decorador en un método sobrescrito, entonces ese grupo se agrega a la lista. Acerca de la eliminación de grupos, entonces debe usar otras técnicas como en el núcleo (por ejemplo, otro método con menos grupos que llame al método original).

Hola ! Gracias por tu respuesta. Una biblioteca de API de OCA LGTM. Gran idea !

pero no con los decoradores add_groups y así sucesivamente

Tienes razón, de hecho podría simplificarse.

Acerca de la eliminación de grupos, entonces debe usar otras técnicas como en el núcleo (por ejemplo, otro método con menos grupos que llame al método original).

No estoy seguro de que cubra todas las necesidades, pero hablaremos de ello en un PR específico contra el nuevo repositorio.

@lasley solo necesita crear el repositorio siguiendo el método puesto en la tarea de instancia OCA ("Crear un proyecto") y hacer el PR.

@lasley , por favor envíeme un ping cuando se cree el repositorio, comenzaré un POC y trataré de terminar el trabajo en los próximos días abiertos (/ cerrados).

Sigo pensando que es una buena idea tener una biblioteca API de OCA. @lasley solo necesita crear el repositorio siguiendo el método puesto en la tarea de instancia OCA ("Crear un proyecto") y hacer el PR.

Buen punto: en ese momento no tenía permisos para hacer esto. Sin embargo, no encuentro este proceso en la instancia de OCA; investigaré un poco más e informaré con el nuevo repositorio.

Hmmm, sí, no puedo encontrar un proceso para la creación del repositorio, así que iba a seguir adelante y crear el repositorio, pero parece que no tengo permisos. @pedrobaeza, ¿le importaría crear un repositorio de OCA / python-oca en blanco para que pueda enviarle un PR?

👍 Por tener un decorador que hace esto. Tuve la idea de crear un decorador @privileged que hiciera lo mismo y que pudiera importarse desde un nuevo módulo de herramientas en herramientas de servidor.

Pero tener al decorador como parte de una biblioteca de pip también podría serlo. Solo me pregunto por el nombre @ api.groups. ¿No sería confuso, ya que esto no proviene del módulo python de odoo api?

Hola @ NL66278 ,

bueno, sobre el espacio de nombres, creo que la colisión no será posible, porque el nombre será @ oca.groups y no @ api.groups. (o algo similar)

@legalsylvain Estaba reaccionando al primer uso de ejemplo. Tener @oca.groups sería genial.

@legalsylvain ¡ Es una buena idea!

Prefiero mantener 'oca' como paquete de espacio de nombres disponible para todos los paquetes de oca. Podríamos llamar a este nuevo paquete 'oca-decorator'. Este paquete proporcionaría 'oca.decorator' (u oca.xyz)

from oca.decorator import groups

    @groups(..)
    def function_name():

Aproximadamente groups Preferiría un nombre más explícito, por ejemplo allowed_groups .

lmi

@lasley, esta es la tarea en la que se especifica el proceso para un nuevo repositorio / PSC: https://odoo-community.org/web#id = 264 & view_type = form & model = project.task & action = 468 & active_id = 2

¡Dios mío, gracias Pedro! Por alguna razón busqué de todo, desde Project hasta Repo, pero no pensé en incluir "PSC". ¡Derp!

Sin embargo, todavía necesitaré algunos derechos adicionales en OCA GitHub, no tengo el nuevo botón:

Inténtelo de nuevo ahora que he cambiado de rol.

@lasley @pedro ¿ python-oca ? Este nombre no tiene sentido. ¿Cómo planeas nombrar el paquete de Python?

@lmignon - Pedí sugerencias y esta fue la mejor. El paquete de python tiene un nombre similar.

¿Qué idea tienes? Soy todo oídos.

@lasley Mi principal preocupación es evitar la creación de un paquete python monolítico. Si el objetivo principal es proporcionar nuevos decoradores especializados, ¿por qué no oca-decorator? El nombre debe depender del alcance funcional cubierto por el paquete o lo que desee. Al menos el nombre debe ser significativo. En mi opinión, 'python-oca' es demasiado ancho.

Soy bueno con oca-decorator , aunque tendríamos que estructurar el módulo de manera un poco diferente, creo que entonces para hacer que los decoradores sean de nivel superior en el espacio de nombres. Estoy bastante seguro de que lo tenía de esa manera originalmente, pero lo devolvimos a oca.helpers en LasLabs / python-oca # 1

De todos modos, es bastante fácil hacer ese cambio, y creo que sería mejor discutirlo en el contexto del código. Al ver que hice el repositorio, enviaré el PR e incluiré su sugerencia, luego podemos discutir en contexto en lugar de este PR secuestrado.

@lasley, el espacio oca nombres

Entendido, así que básicamente solo querríamos cambiar el nombre de nuestro paquete helpers a decorators , y luego llamarlo nuestro esquema para las cosas de Python. Resumen Ej. oca-package-sub == oca.package.sub

sí: sonrisa satisfecha: esa es la idea.

Lástima que se tome ocapi : smile_cat:

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

Tengo una pregunta sobre la estructura de este código. (tal vez mi pregunta sea irrelevante, lo siento)

Básicamente, veo dos formas de escribir este código.

A) a través de un módulo odoo clásico (en un repositorio nuevo o existente). entonces, para usarlo, tenemos que escribir algunos

from odoo.addons.my_oca_lib_in_module import my_decorator

B) a través de una lib de python.

Parece que todos estáis hablando de la solución "B", y por supuesto, es la solución más limpia.
pero, por otro lado, me temo que dicha tecnología bloqueará a algunos usuarios que no tienen habilidad técnica para usar módulos que dependen de la nueva lib oca-python. Pienso, por ejemplo, en las personas que están instalando un módulo a través de la interfaz de usuario, u otro a través de odoo.sh (¡y mañana con la tienda de aplicaciones OCA, tal vez!). No estoy seguro de que todo el sistema de alojamiento permita instalar una biblioteca de Python personalizada fácilmente.
Sería una lástima que algunos usuarios no tuvieran la posibilidad de instalar módulos OCA, porque dependen de una lib extra que no es instalable para algunas personas.

Solo hay otro ejemplo en la OCA por el momento. El archivo openupgradelib. el código estaba inicialmente en el proyecto OpenUpgrade y se movió a un python-lib externo. Para mí, no es un punto de bloqueo para openupgradelib, porque hacer una actualización es una cuestión técnica.

Qué piensas ?

¿Sabemos cómo Odoo.sh maneja las dependencias de pip?

En mi opinión, esto está en ellos para arreglar la clave external_depencies en el manifiesto; tenemos muchos módulos que lo usan. No creo que los módulos que usan esta nueva biblioteca sean diferentes a, digamos, barcodes_generator_abstract requieren barcode

por no decir Odoo.sh (o Odoo.hs para los franceses) es el próximo Runbot. Apuesta tomada.

😆 Sí, sabemos dónde está mi apuesta en ese

tenemos muchos módulos que lo usan (por @lasley)

De hecho, pero es bastante diferente. Por supuesto, si desea un sistema que maneje la generación de códigos de barras, debe instalar lib. lo mismo para asterisco, etc ...
pero esto es muy limitado, y tal vez algunos usuarios en el mundo no estén instalando dichos módulos porque no pueden o no saben cómo hacerlo. pero no hay alternativa. para utilizar la generación de códigos de barras, necesita una biblioteca de códigos de barras.

Aquí es diferente. Acabo de actualizar el análisis de fuente de código OCA. hoy hay 4182 módulos. (un módulo presente en dos hitos se cuenta dos veces). Por otro lado, en todos esos 4182 módulos, solo hay 274 dependencias de Python. Entonces, el 94% de los módulos OCA no dependen de bibliotecas de Python externas y se pueden instalar muy fácilmente. detalles :

Si mañana, hay una buena lib extra de oca python con decoradores útiles (como el que intentamos describir en este hilo que intenta solucionar un problema de seguridad), la mayoría de los módulos OCA dependerán de esta lib, paso a paso.

El objetivo de la OCA es promover el trabajo de los miembros de la OCA. Entonces, si tal decisión (crear una biblioteca para instalar) está reduciendo la posibilidad de que la gente use módulos OCA, creo que no deberíamos ir en esta dirección por el momento. Podríamos crear primero un pequeño repositorio oca-decorator, con módulos clásicos . Y si en 1/2 años está maduro, y si el sistema de implementación y alojamiento también está más maduro (*), será muy fácil poner todo el código en una biblioteca externa.

El código de openupgrade ha estado durante años en el repositorio de openupgrade y ha sido establecido en una biblioteca externa recientemente por @StefanRijnhart. Creo que estos cambios no fueron gran cosa.

(*): el sistema de hosting e implementación ha cambiado mucho durante los últimos años. (obtención de código por bzr, obtención de código por github, uso de tecnología de construcción y, más recientemente, implementación de pypi)

Me gustaría escuchar lo que @ OCA / board está pensando sobre ese punto. no es solo una decisión técnica, también es una decisión estratégica

Ahora que https://github.com/OCA/oca-decorators está disponible, este RFC puede trasladarse allí.

@legalsylvain : originalmente api.foreach antes de crearlo como una biblioteca. Eche un vistazo a este PR , y verá por qué abandonamos esta estrategia.

El uso de la API era casi imposible cuando comienzas a tener en cuenta una ruta de importación que tiene 60-70 caracteres, y un try / excepto que debe colocarse alrededor de cada una de las importaciones. Esto hará que la adopción del módulo sea básicamente cero: la importación es más difícil que el ciclo de grabación.

Curiosamente, nuestra estrategia try / except falla estrepitosamente con los decoradores, pero ese es un tema completamente diferente. Nuevamente, me gustaría que Odoo arreglara su clave external_dependencies .

@dreispt : ¿hay una buena manera de mover esta discusión preexistente a otro repositorio? Hay muchos puntos expuestos aquí que no estoy seguro de que se trasladen con fluidez.

El uso de la API era casi imposible cuando comienzas a tener en cuenta una ruta de importación que tiene 60-70 caracteres, y un try / excepto que debe colocarse alrededor de cada una de las importaciones

No entiendo cuál es la necesidad de intentar / excepto en esa solución.

Para usar un decorador oca @ foreach, defina en un módulo o lib oca_api. :

Impactos de la solución lib
desplegar:

• pip install o mediante buildout. Limitación de Saas.

archivo de manifiesto:

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

Archivo Python:

from oca_api import oca

Impactos de la solución del módulo
desplegar:

• pip instalar o descargar e instalar a través de la interfaz de usuario o mediante buildout o simplemente agregando un módulo en el archivo de complementos. sin limitación de saas.

archivo de manifiesto:

'depends': ['oca_api'],

Archivo Python:

from odoo.addons.oca_api import oca

¿O me perdí algo? Si es así, corrígeme.

Saludos cordiales.

No entiendo cuál es la necesidad de intentar / excepto en esa solución.

El try / except es lo que tenemos que hacer al importar cualquier cosa que no sea el núcleo de Odoo, por lo que sus ejemplos serían los siguientes:

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

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

Pero sí, con el nombre de su módulo, no es tan malo como el mío.

Creo que mucho de esto tiene que ver con el hecho de que el módulo no se está instalando en una base de datos y no está encapsulado en el entorno como lo estaría la mayoría de los módulos. Esto significa que proporciona funcionalidad a entornos que no han instalado explícitamente el módulo y podrían considerarse un problema (de seguridad o de otro tipo).

@lmignon acaba de exponer un argumento similar al anterior en https://github.com/OCA/webhook/pull/3#issuecomment -336935193. Creo que se trata de conversaciones paralelas, que básicamente se centran en cómo proporcionamos conjuntos de funciones como este.

Personalmente, siento que @lmignon está aquí y deberíamos proporcionar esto como una biblioteca. IIRC su consejo fue la razón principal por la que también saqué el decorador foreach de un módulo.

Hola @lasley.

¡Ay gracias! Pensé que hacer dependencias a un módulo era suficiente para asumir que el módulo está presente, pero al agrupar todo el código OCA, vi muchas muestras de lo que hablas. (mucho para report_xls y conector).

No tengo las habilidades para comprender los problemas de seguridad aquí, debido a un módulo. Para mí, si el módulo no está instalado, no se debería llamar al código del módulo de oca_api. pero tal vez me equivoque.

Saludos.

Pensé que hacer dependencias a un módulo era suficiente para asumir que el módulo está presente,

Eche un vistazo a https://github.com/odoo/odoo/pull/14850 para obtener más información

Para mí, si el módulo no está instalado, no se debería llamar al código del módulo de oca_api.

Ahí yace el problema. Este no es el caso: Odoo importa todos los módulos dentro de la ruta addons a la memoria. Debido a esto, las importaciones en el módulo se realizarán correctamente en cualquier módulo, ya sea que el dependiente esté instalado o no.

Esto es fundamental en Odoo y, de manera realista, no hay elusión. Esta es también la razón por la que no comparto con mis clientes de la misma manera que lo hace Odoo SA. Tengo curiosidad por saber si han logrado resolver esto con Odoo.sh, pero supongo que tienen una bomba de tiempo en sus manos en su SaaS.

Gracias por todas estas aclaraciones. Es una pena que no se acepte odoo / odoo # 14850.
Sigo pensando que hacer muchos módulos OCA dependiendo de una biblioteca externa seguramente limitará el uso de estos módulos. Pero bueno, un módulo no parece ser una solución.
Saludos y muchas gracias por tu comprensión.

Cierro este tema. (movido a https://github.com/OCA/oca-decorators/issues/7)
saludos y gracias por todos sus comentarios.