Tornar o módulo OnlyOffice compatível com o Odoo 19

Ao migrar um cliente para o Odoo 19, a integração OnlyOffice começou a mostrar avisos ao carregar o módulo. Nada estava partido, mas depois de uma subida de versão maior, um aviso raramente é inofensivo: é muitas vezes o primeiro sinal do que vai partir na versão seguinte. Rastreámos as duas causas a alterações do Odoo 19, corrigimos ambas, e a correção está agora fundida no módulo oficial ONLYOFFICE.

As duas correções são mínimas: cinco ficheiros, um renomear de função e um argumento de decorador. Mas ilustram as duas ruturas mais comuns que uma versão maior do Odoo introduz, e apanhá-las cedo é precisamente o objetivo. Aqui estão.

Aviso n.º 1: traduções avaliadas demasiado cedo

Primeiro sintoma: uma torrente de avisos no translation language detected no arranque. Os rótulos dos campos Selection usavam a função de tradução imediata _(), importada de odoo:

from odoo import _, fields, models

internal_users = fields.Selection(
    [
        ("none", _("None")),
        ("view", _("Viewer")),
        ("commenter", _("Commenter")),
        ("reviewer", _("Reviewer")),
        ("edit", _("Editor")),
        ("form_filling", _("Form Filling")),
        ("custom_filter", _("Custom Filter")),
    ],
    ...
)

Uma definição de campo executa-se quando o módulo é importado, enquanto o Odoo constrói o seu registo. Nesse momento não há utilizador, nem pedido, nem idioma: _() tenta resolver uma tradução sem qualquer contexto para a resolver. As versões anteriores deixavam passar; a 19.0 emite um aviso.

A solução é a tradução preguiçosa _lt(), em odoo.tools.translate:

from odoo import fields, models
from odoo.tools.translate import _lt

internal_users = fields.Selection(
    [
        ("none", _lt("None")),
        ("view", _lt("Viewer")),
        ("commenter", _lt("Commenter")),
        ("reviewer", _lt("Reviewer")),
        ("edit", _lt("Editor")),
        ("form_filling", _lt("Form Filling")),
        ("custom_filter", _lt("Custom Filter")),
    ],
    ...
)

O _lt() devolve um objeto preguiçoso: espera que a cadeia seja realmente apresentada, ou seja, que um idioma esteja presente no contexto, antes de procurar a sua tradução. O resultado final é idêntico. A regra: para qualquer cadeia avaliada no momento da importação (rótulos de campos, opções de Selection, valores por omissão ao nível da classe), use _lt(), não _().

Aviso n.º 2: a rota depreciada type='json'

O segundo é um simples renomear. As rotas declaradas assim:

@http.route("/onlyoffice/editor/get_config", auth="user", methods=["POST"], type="json", csrf=False)
def get_config(self, document_id=None, attachment_id=None, access_token=None):
    ...

continuam a funcionar na 19.0, mas type="json" passou a ser apenas um alias depreciado de jsonrpc:

@http.route("/onlyoffice/editor/get_config", auth="user", methods=["POST"], type="jsonrpc", csrf=False)

O mesmo dispatch JSON-RPC, sem alteração de comportamento. Mas o alias avisa desde já e será removido numa versão futura: mais vale fazer o renomear agora.

Porque o enviámos para o projeto de origem

Poderíamos ter mantido este diff no nosso próprio fork e seguir em frente. Não o fazemos: uma correção privada degrada-se em silêncio sempre que o projeto de origem evolui. Uma vez fundida no projeto de origem, passa a ser responsabilidade do projeto, mantida, validada pela sua CI e entregue a todos na versão seguinte, nós incluídos. Contribuir de volta não é um favor, é a escolha pragmática.

É também todo o interesse da combinação Odoo e OnlyOffice para os clientes onde a implementamos: editar ficheiros Word, Excel e PowerPoint diretamente no ERP, na sua própria infraestrutura, com uma integração que acompanha a evolução do Odoo porque ajudamos a escrevê-la. Usa o Odoo e quer uma edição de documentos que controla verdadeiramente? Escreva-nos para contact@eclypsys.ch.