Server-tools: [RFC] novo decorador api.groups para função

Acho que é uma boa ideia - segurança por obscuridade (esconder os botões) não funciona.

A questão é onde colocar isso. Eu fiz um módulo OCA Python que tem uma implementação api.foreach , mas não houve muito movimento em colocá-lo na frente do OCA

Ainda acho uma boa ideia ter uma biblioteca de APIs OCA. @lasley você só precisa criar o repo seguindo o método colocado na tarefa de instância OCA ("Criar um projeto") e fazer o PR.

Sobre este recurso: +1: para adicioná-lo, mas não com os decoradores add_groups e assim por diante. Isso deve ser tratado com a herança: se você adicionar qualquer novo grupo no decorador em um método sobrescrito, esse grupo será adicionado à lista. Sobre a remoção de grupos, então você deve usar outras técnicas como no núcleo (por exemplo, outro método com menos grupos que chama o método original).

Oi ! Obrigado pela sua resposta. Uma biblioteca LGTM da API OCA. Boa ideia !

mas não com os decoradores add_groups e assim por diante

Você está certo, poderia ser simplificado de fato.

Sobre a remoção de grupos, então você deve usar outras técnicas como no núcleo (por exemplo, outro método com menos grupos que chama o método original).

Não tenho certeza se atenderá a todas as necessidades, mas falaremos sobre isso em um PR específico para o novo repo.

@lasley você só precisa criar o repo seguindo o método colocado na tarefa de instância OCA ("Criar um projeto") e fazer o PR.

@lasley , por favor, me envie um ping quando o repo for criado, eu começarei um POC e tentarei terminar o trabalho nos próximos dias abertos (/ fechados).

Ainda acho uma boa ideia ter uma biblioteca de APIs OCA. @lasley você só precisa criar o repo seguindo o método colocado na tarefa de instância OCA ("Criar um projeto") e fazer o PR.

Bom ponto - na época eu não tinha permissão para fazer isso. No entanto, não estou encontrando esse processo na instância OCA - vou cavar um pouco mais e relatar de volta com o novo repo.

Hmmm ok sim, então não consigo encontrar um processo para a criação do repo, então eu estava indo em frente e criando o repo - mas parece que não tenho permissões. @pedrobaeza , você se importaria de criar um

👍 Por ter um decorador que faz isso. Tive a ideia de criar um decorador @privileged que faria a mesma coisa e que pudesse ser importado de um novo módulo de ferramentas em ferramentas de servidor.

Mas ter o decorador como parte de uma biblioteca pip também pode servir. Eu apenas me pergunto sobre o nome @ api.groups. Isso não seria confuso, já que isso não vem do módulo odoo api python?

Olá @ NL66278 ,

bem, quanto ao namespace, acho que a colisão não será possível, pois o nome será @ oca.groups e não @ api.groups. (ou algo semelhante)

@legalsylvain Eu estava reagindo ao primeiro exemplo de uso. Ter @oca.groups seria ótimo.

@legalsylvain É uma boa ideia!

Prefiro manter 'oca' como um pacote de namespace disponível para todos os pacotes oca. Poderíamos nomear este novo pacote 'oca-decorator'. Este pacote forneceria 'oca.decorator' (ou oca.xyz)

from oca.decorator import groups

    @groups(..)
    def function_name():

Sobre groups Eu prefiro um nome mais explícito, por exemplo allowed_groups .

lmi

@lasley esta é a tarefa em que o processo para um novo repositório / PSC é especificado: https://odoo-community.org/web#id = 264 & view_type = form & model = project.task & action = 468 & active_id = 2

Omg obrigado Pedro! Por algum motivo, pesquisei de tudo, do Project ao Repo, mas não pensei em incluir "PSC". Derp!

Ainda vou precisar de alguns direitos adicionais no OCA GitHub - não tenho o novo botão:

Tente novamente agora que mudei sua função.

@lasley @pedro Por que python-oca ? Este nome não tem sentido. Como você planeja nomear o pacote python?

@lmignon - Pedi sugestões e essa foi a melhor. O pacote python tem um nome semelhante.

Qual é a sua ideia? Sou todo ouvidos.

@lasley Minha principal preocupação é evitar a criação de um pacote python monolítico. Se o objetivo principal é fornecer novos decoradores especializados, por que não um decorador. O nome deve depender do escopo funcional coberto pelo pacote ou o que você quiser. Pelo menos o nome deve ser significativo. IMO 'python-oca' é muito largo.

Eu sou bom com oca-decorator , embora precisemos estruturar o módulo de forma um pouco diferente, eu acho, para tornar os decoradores de nível superior no namespace. Tenho certeza de que era assim originalmente, mas voltamos para oca.helpers em LasLabs / python-oca # 1

De qualquer forma, é fácil fazer essa alteração e acho que seria melhor discuti-la no contexto do código. Vendo como fiz o repo, irei enviar o PR e incluir sua sugestão - então podemos discutir no contexto em vez deste PR sequestrado.

@lasley, o oca deve permanecer vazio. Caso contrário, não será possível criar outros pacotes python sob o mesmo namespace.

Entendi, então basicamente queremos renomear nosso pacote helpers para decorators , em seguida, chamá-lo de nosso esquema para as coisas do Python? Resumo Ex: oca-package-sub == oca.package.sub

sim: sorriso: essa é a ideia.

Que pena que ocapi foi capturado: smile_cat:

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

Tenho uma dúvida sobre a estrutura deste código. (talvez minha pergunta seja irrelevante, desculpe)

Basicamente, vejo duas maneiras de escrever esse código.

A) por meio de um módulo odoo clássico (em um repositório existente ou novo). então, para usá-lo, temos que escrever alguns

from odoo.addons.my_oca_lib_in_module import my_decorator

B) por meio de uma biblioteca python.

Parece que todos vocês estão falando sobre a solução “B” e, claro, é a solução mais limpa.
mas por outro lado, temo que tal tecnologia bloqueie alguns usuários que não possuem nenhuma habilidade técnica para usar módulos que dependem da nova lib oca-python. Eu acho que por exemplo para as pessoas que estão instalando o módulo via UI, ou outro via odoo.sh (e amanhã com o appstore OCA, talvez!). Não tenho certeza se todo o sistema de hospedagem permitirá a instalação de lib python personalizada facilmente.
seria uma pena se alguns usuários não tivessem a possibilidade de instalar módulos OCA, pois existem dependendo de uma lib extra que não é instalável para algumas pessoas.

Por enquanto, há apenas um outro exemplo na OCA. O openupgradelib. o código estava inicialmente no projeto OpenUpgrade e foi movido para um python-lib externo. Para mim não é um ponto de bloqueio para o openupgradelib, porque fazer uma atualização é uma coisa técnica.

O que você acha ?

Sabemos como Odoo.sh lida com dependências de pip?

IMO, eles estão encarregados de corrigir a chave external_depencies no manifesto - temos vários módulos que a usam. Não acho que os módulos que usam esta nova biblioteca seriam diferentes de, digamos, barcodes_generator_abstract exigindo barcode

para não dizer Odoo.sh (ou Odoo.hs para franceses) é o próximo Runbot. Aposta realizada.

😆 Sim, nós sabemos onde está minha aposta naquele

temos muitos módulos que o usam (por @lasley)

Sim, mas é bem diferente. Claro, se você deseja um sistema que lide com a geração de código de barras, você deve instalar a biblioteca de código de barras. o mesmo para asterisco, etc ...
mas isso é muito limitado, e talvez alguns usuários no mundo não estejam instalando esses módulos porque não podem ou não sabem como fazer. mas não há alternativa. para usar a geração de código de barras, você precisa de uma biblioteca de código de barras.

Aqui é diferente. Acabei de atualizar a análise de código-fonte OCA. hoje existem 4182 módulos. (um módulo presente em dois marcos é contado duas vezes). Por outro lado, em todos os 4182 módulos, existem apenas 274 dependências python. Portanto, 94% dos módulos OCA não dependem de bibliotecas python externas e podem ser instalados facilmente. detalhes :

Se amanhã houver uma boa lib oca python extra com decoradores úteis (como aquele que tentamos descrever neste tópico que tenta corrigir um problema de segurança), a maioria dos módulos OCA dependerá dessa lib, passo a passo.

O objetivo da OCA é promover o trabalho dos membros da OCA. Portanto, se tal decisão (de criar uma lib para instalar) está reduzindo a possibilidade de as pessoas usarem módulos OCA, acho que não devemos ir nessa direção por enquanto. Poderíamos criar primeiro um pequeno repositório oca-decorator, com módulos clássicos . E se em 1/2 anos, ele estiver maduro, e se o sistema de implantação e hospedagem também estiver mais maduro (*), será muito fácil colocar todo o código em uma biblioteca externa.

código openupgrade esteve durante anos no repositório openupgrade e foi definido em uma biblioteca externa recentemente por @StefanRijnhart. Acho que essa mudança não foi grande coisa.

(*): o sistema de hospedagem e implantação mudou muito nos últimos anos. (obtenção de código por bzr, obtenção de código por github, uso de tecnologia buildout e, mais recentemente, implantação de pypi)

Eu gostaria de ouvir o que @ OCA / board está pensando sobre esse ponto. não é apenas uma decisão técnica, é também uma decisão estratégica

Agora que https://github.com/OCA/oca-decorators está disponível, este RFC pode ser movido para lá.

@legalsylvain - Eu originalmente enviei um módulo para api.foreach antes de criá-lo como uma biblioteca. Dê uma olhada neste PR e você verá por que abandonamos essa estratégia.

O uso da API era quase impossível quando você começa a contabilizar um caminho de importação de 60-70 caracteres e uma tentativa / exceção que deve ser colocada em cada uma das importações. Isso tornará a adoção do módulo basicamente zero - a importação é mais difícil do que o loop de registro.

Curiosamente, nossa estratégia try / except falha miseravelmente com decoradores, mas esse é um tópico completamente diferente. Mais uma vez, gostaria que o Odoo corrigisse sua chave external_dependencies .

@dreispt - há uma boa maneira de mover essa discussão pré-existente para outro repo? Há muitos pontos expostos aqui que não tenho certeza se seriam transmitidos com fluidez.

O uso da API era quase impossível quando você começa a contabilizar um caminho de importação de 60-70 caracteres e uma tentativa / exceto que deve ser colocada em torno de cada uma das importações

Não entendo qual é a necessidade de tentar / exceto nessa solução.

Para usar um decorador oca @ foreach, defina em um oca_api lib ou módulo. :

Impactos da solução Lib
implantar :

• pip install ou via buildout. Limitação de Saas.

arquivo de manifesto:

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

Arquivo Python:

from oca_api import oca

Impactos da solução do módulo
implantar :

• pip instalar ou baixar e instalar via IU ou via buildout ou apenas adicionando um módulo no arquivo addons. sem limitação de saas.

arquivo de manifesto:

'depends': ['oca_api'],

Arquivo Python:

from odoo.addons.oca_api import oca

Ou eu perdi alguma coisa? Se sim, por favor me corrija.

Atenciosamente.

Não entendo qual é a necessidade de tentar / exceto nessa solução.

O try / except é o que temos que fazer ao importar qualquer coisa que não seja o núcleo Odoo, então seus exemplos seriam os seguintes:

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

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

Mas sim, com o nome do seu módulo, não é tão ruim quanto o meu.

Acho que muito disso tem a ver com o fato de que o módulo não está sendo instalado em um banco de dados e não está encapsulado no ambiente como a maioria dos módulos estaria. Isso significa que ele está fornecendo funcionalidade para ambientes que não instalaram explicitamente o módulo e pode ser considerado um problema (segurança ou outro).

@lmignon acaba de expor um argumento semelhante ao acima em https://github.com/OCA/webhook/pull/3#issuecomment -336935193. Acho que são conversas paralelas - basicamente fervilhando em como fornecemos conjuntos de recursos como este.

Pessoalmente, acho que @lmignon está bem aqui e devemos fornecer isso como uma lib. O conselho do IIRC foi o principal motivo pelo qual também tirei o decorador foreach de um módulo.

Olá @lasley.

Ai obrigado! Achei que fazer dependências para um módulo fosse o suficiente para assumir que o módulo está presente, mas rgrepando todo o código OCA, vi muitos exemplos do que você fala. (muito para report_xls e conector).

Não tenho habilidades para entender os problemas de segurança aqui, devido a um módulo. Para mim, se o módulo não estiver instalado, o código do módulo de oca_api não deve ser chamado. mas talvez eu esteja errado.

Cumprimentos.

Eu pensei que fazer dependências para um módulo era o suficiente para assumir que o módulo está presente,

Dê uma olhada em https://github.com/odoo/odoo/pull/14850 para mais informações

Para mim, se o módulo não estiver instalado, o código do módulo de oca_api não deve ser chamado.

Ai que está o problema. Este não é o caso - Odoo importa todos os módulos dentro do caminho addons para a memória. Devido a isso, as importações no módulo serão bem-sucedidas em qualquer módulo - esteja o dependente realmente instalado ou não.

Isso é fundamental no Odoo e, de forma realista, não há como evitar. É também por isso que não co-hospedo meus clientes da mesma forma que Odoo SA. Estou curioso para saber se eles conseguiram resolver isso com Odoo.sh, mas meu palpite é que eles têm uma bomba-relógio em suas mãos em seu SaaS

Obrigado por todos esses esclarecimentos. É uma pena que odoo / odoo # 14850 não seja aceito.
Eu ainda acho que fazer muitos módulos OCA dependendo de uma biblioteca externa certamente limitará o uso desses módulos. Mas bem, um módulo não parece ser uma solução de fato.
Atenciosamente e muito obrigado por sua visão.

Eu encerro esse problema. (movido para https://github.com/OCA/oca-decorators/issues/7)
cumprimentos e obrigado por todos os seus comentários.