Documentation
Version 5

Migration vers la V5 — Développeurs

Migration vers la V5 — Guide pour les développeurs et intégrateurs

Cette page s'adresse aux équipes qui maintiennent des applications personnalisées, des forks ou des intégrations via l'API. Si vous utilisez Dokos sans personnalisation de code, elle ne vous concerne pas.Si votre site est hébergé par Dokos, la migration technique est prise en charge par notre équipe — vous n'avez pas à vous occuper de l'infrastructure. En revanche, si vous avez développé des personnalisations, vérifiez les points ci-dessous qui vous concernent.

La V5 de Dokos s'appuie sur la V16 de Frappe et ERPNext. Cette montée de version introduit des changements structurels significatifs. Certains sont transparents, d'autres nécessitent une action de votre part avant ou après la migration.

Prérequis techniques

Avant toute chose, vérifiez vos dépendances. Les versions minimales ont été relevées :

  • Python 3.14 ou supérieur
  • NodeJS 24 ou supérieur
Si votre environnement ne répond pas à ces prérequis, la migration ne pourra pas aboutir. C'est le premier point à vérifier.

Changements structurels dans Frappe

Modules extraits en applications distinctes

Plusieurs modules ont quitté le cœur de Frappe pour devenir des applications indépendantes. Si vous les utilisiez — directement ou via des dépendances — ils devront être réinstallés séparément :

  • Energy Points
  • Newsletter
  • Backup Integrations
  • Blog

Tri par défaut changé : modified → creation

C'est probablement le changement le plus silencieux et le plus susceptible de créer des comportements inattendus dans vos applications.

À partir de la V16, toutes les vues liste et la plupart des APIs Frappe trient par défaut selon la date de création (creation) et non plus par date de modification (modified).

Ce que vous devez faire :

  1. Auditez votre code pour identifier les endroits où le tri implicite par modified affecte votre logique métier
  2. Mettez à jour l'ordre de tri par défaut de vos DocTypes personnalisés de modified vers creation
  3. Partout où vous avez besoin d'un tri par modified, rendez-le explicite : order_by='modified desc'

Les APIs concernées : frappe.get_all(), frappe.get_list(), frappe.db.get_value(), frappe.db.get_values(), frappe.qb.get_query().

Si vous souhaitez conserver l'index sur modified après la migration, vous pouvez le ré-ajouter dans le contrôleur de votre DocType :

def on_doctype_update():
    frappe.db.add_index("Doctype Name", ["modified"])

Passage au Query Builder pour get_list et get_all

frappe.get_all() et frappe.get_list() utilisent désormais le nouveau Query Builder en backend. Des ajustements de compatibilité peuvent être nécessaires selon l'usage que vous en faites, notamment pour les appels de fonctions SQL comme sum. Consultez le guide de migration officiel vers le Query Builder pour les détails et exemples.

Méthodes whitelistées nécessitant désormais POST

Les méthodes suivantes n'acceptent plus que des requêtes POST :

  • /api/method/logout
  • /api/method/web_logout
  • /api/method/upload_file
  • /api/method/frappe.www.login.send_login_link

Si votre code client appelle ces méthodes en GET, mettez-le à jour.

Code pays obligatoire et validé

Le champ Code du DocType Pays est maintenant obligatoire et doit respecter la norme ISO 3166 ALPHA-2. Si votre base contient des pays personnalisés ou des codes non conformes, ils devront être corrigés avant la migration.

frappe.flags.in_test est déprécié

Remplacez frappe.flags.in_test par frappe.in_test. L'ancien attribut sera supprimé dans une prochaine version. Si vous modifiez cette valeur dans vos tests, utilisez frappe.tests.utils.toggle_test_mode qui met à jour les deux attributs simultanément.

db.get_value convertit maintenant les résultats des Single DocTypes

Jusqu'ici, db.get_value retournait toujours des chaînes de caractères pour les Single DocTypes. Ce comportement a été corrigé — les valeurs sont maintenant retournées dans leur type réel. Si votre code comparait ces valeurs à des chaînes, adaptez-le :

# Avant
if frappe.db.get_value("Settings", "Settings", "enabled") == "1":

# Après
if frappe.db.get_value("Settings", "Settings", "enabled") == 1:

Chargement du code JS en IIFE

Les fichiers JS des Rapports, Graphiques de tableau de bord et Pages sont maintenant évalués comme des IIFEs. Si votre code reposait intentionnellement sur la pollution du scope global, il devra être mis à jour. Il reste possible de modifier le scope global en mutant explicitement l'objet window.

meta.get_valid_columns() exclut désormais les champs virtuels

Si votre code supposait que les champs virtuels figuraient dans get_valid_columns(), vous devrez l'adapter.

Vue carte : comportement aligné sur la vue liste

La vue carte affiche maintenant les 20 premiers éléments avec pagination, comme la vue liste. L'ancien comportement (chargement de tous les enregistrements en une seule fois) a été supprimé. Sur les grands jeux de données, c'est un gain de performance significatif — mais si votre code s'appuyait sur ce chargement complet, anticipez l'adaptation.

Changements côté ERPNext

Facturation des feuilles de temps via l'API

Si vous créez des factures de vente via l'API et récupériez automatiquement les feuilles de temps non facturées liées à un projet, ce comportement n'est plus automatique. Un appel supplémentaire est maintenant nécessaire :

PUT /api/v2/document/Sales%20Invoice/SINV-0001/method/add_timesheet_data

Suppression de méthodes whitelistées

Deux méthodes ont été supprimées. Si vous les appelez dans des scripts ou intégrations, adaptez votre code pour utiliser directement frappe.new_doc :

  • erpnext.accounts.doctype.bank_account.bank_account.make_bank_account
  • erpnext.accounts.doctype.pricing_rule.pricing_rule.make_pricing_rule

Un blocage, une question ?

Ouvrez une issue sur notre GitLab ou venez en parler sur le forum. Une migration qui se passe bien, c'est aussi notre responsabilité — on préfère qu'on le sache tôt plutôt que vous voir avancer seuls face à un comportement inattendu.