Rendre le module OnlyOffice compatible avec Odoo 19

En migrant un client vers Odoo 19, l'intégration OnlyOffice a commencé à afficher des avertissements au chargement du module. Rien n'était cassé, mais après une montée de version majeure, un avertissement est rarement anodin : c'est souvent le premier signe de ce qui cassera à la version suivante. Nous avons remonté les deux causes à des changements d'Odoo 19, corrigé l'une et l'autre, et le correctif est aujourd'hui fusionné dans le module officiel ONLYOFFICE.

Les deux corrections sont minimes : cinq fichiers, un renommage de fonction et un argument de décorateur. Mais elles illustrent les deux ruptures les plus courantes qu'introduit une version majeure d'Odoo, et les attraper tôt est précisément l'intérêt. Les voici.

Avertissement n°1 : des traductions évaluées trop tôt

Premier symptôme : un flot d'avertissements no translation language detected au démarrage. Les libellés des champs Selection utilisaient la traduction immédiate _(), importée depuis 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")),
    ],
    ...
)

Une définition de champ s'exécute à l'import du module, quand Odoo construit son registre. À ce moment, il n'y a ni utilisateur, ni requête, ni langue : _() cherche donc une traduction sans aucun contexte pour la résoudre. Les versions précédentes laissaient faire ; la 19.0 émet un avertissement.

La solution est la traduction paresseuse _lt(), dans 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")),
    ],
    ...
)

_lt() renvoie un objet paresseux : il attend que la chaîne soit réellement affichée, donc qu'une langue soit présente dans le contexte, avant de chercher sa traduction. Le rendu final est identique. La règle : pour toute chaîne évaluée à l'import (libellés de champs, options de Selection, valeurs par défaut au niveau de la classe), utilisez _lt(), pas _().

Avertissement n°2 : la route type='json' dépréciée

Le second est un simple renommage. Les routes déclarées ainsi :

@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):
    ...

fonctionnent toujours en 19.0, mais type="json" n'y est plus qu'un alias déprécié de jsonrpc :

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

Même dispatch JSON-RPC, aucun changement de comportement. Mais l'alias avertit dès aujourd'hui et sera retiré dans une prochaine version : autant faire le renommage tout de suite.

Pourquoi nous l'avons remonté en amont

Nous aurions pu garder ce diff dans notre propre fork et passer à la suite. Nous ne le faisons pas : un correctif privé se dégrade en silence à chaque fois que le projet d'origine évolue. Une fois fusionné en amont, il devient l'affaire du projet, maintenu, validé par sa CI et livré à tout le monde à la version suivante, nous compris. Contribuer en retour n'est pas une faveur, c'est le choix pragmatique.

C'est aussi ce qui fait l'intérêt du duo Odoo et OnlyOffice chez les clients où nous le déployons : éditer des fichiers Word, Excel et PowerPoint directement dans l'ERP, sur leur propre infrastructure, avec une intégration qui suit les évolutions d'Odoo parce que nous contribuons à les écrire. Vous utilisez Odoo et souhaitez une édition de documents que vous maîtrisez vraiment ? Écrivez-nous à contact@eclypsys.ch.