Si un formulaire est bien envoyé, mais que les données n'arrivent pas dans onOffice — ou seulement de manière incomplète —, cela est dû, dans 9 cas sur 10, aux droits de l'utilisateur onOffice avec lequel propform communique. Voici les causes les plus fréquentes, par ordre de probabilité :
L'utilisateur API dans onOffice doit disposer des droits de lecture et d'écriture appropriés pour tous les modules utilisés par votre formulaire (adresses, biens immobiliers, activités, tâches, rendez-vous, critères de recherche, modèles).
Solution : L'ensemble des droits recommandés est documenté ici : Droits de l'utilisateur API onOffice.
> Veillez tout particulièrement à ce que les droits de lecture ET d'écriture soient réglés sur « tous » (et non « uniquement les siens ») si votre formulaire doit modifier des enregistrements d'autres collaborateurs.
Si un collaborateur coche la case « Privé » dans onOffice pour un enregistrement d'adresse, personne d'autre que l'utilisateur qui l'a cochée ne peut plus lire ou modifier cette adresse — pas même l'utilisateur de l'API.
Symptômes :
Solution :
Dans onOffice, des droits d'accès aux enregistrements peuvent être définis pour des adresses, des biens immobiliers, des modèles ou des dossiers de modèles individuels, ce qui exclut l'utilisateur de l'API.
Cas fréquents :
Solution :
> ⚠️ Erreur fréquente avec les modèles : il existe trois niveaux de droits pour les modèles d'e-mail/PDF : > 1. Le modèle lui-même (clé à molette sur le modèle → droits d'accès) > 2. Le dossier de modèles dans lequel se trouve le modèle (icône en forme de clé à molette sur le dossier !) ← souvent oublié > 3. L'utilisateur API sous l'onglet « Droits » → section « Word, modèles d'e-mails, fichiers » → « Lire les modèles → tous » > > Si le modèle n'apparaît pas dans le menu déroulant de sélection dans propform, vérifie ces trois niveaux.
Si ton système onOffice utilise le module Groupes, un utilisateur ne voit par défaut que les enregistrements appartenant à ses groupes. Si l'utilisateur API n'est affecté à aucun groupe, il ne verra que très peu de données.
Solution : Affectez l'utilisateur API à un groupe disposant des droits de lecture les plus étendus possibles.
Voici comment procéder dans onOffice :
> Si vous ne savez pas quel groupe choisir, demandez conseil à votre administrateur onOffice ou au support onOffice.
Si un champ spécifique de votre formulaire ne transmet pas de données, vérifiez dans l'administration onOffice si ce champ y est bien activé. Les champs inactifs ne sont pas proposés à propform — et si vous les avez copiés via la migration, leur valeur disparaîtra dans le néant.
Cas particulier des critères de recherche : les champs doivent être explicitement définis comme champs de critères de recherche dans l'administration onOffice, sinon ils ne seront pas proposés à propform dans le module des critères de recherche.
Ce message d'erreur API typique apparaît lorsque propform tente de charger un enregistrement depuis onOffice, mais n'en trouve aucun qui corresponde.
Causes fréquentes :
Procédure de dépannage :
> Si vous ne trouvez pas la cause, envoyez-nous un e-mail avec l'UUID, le formulaire et l'heure de l'erreur — nous examinerons les journaux ensemble.
Dans le cas de formulaires très volumineux (nombreux champs, en particulier des champs personnalisés complexes), il peut arriver que l'API onOffice ne renvoie plus aucun enregistrement — ce n'est pas seulement un champ qui manque, mais l'appel API dans son ensemble renvoie NULL.
Symptômes :
Contexte : Il s'agit d'une limite imposée par onOffice/MariaDB — lorsque les champs sont trop nombreux ou trop complexes (notamment des textes longs, de nombreux champs à sélection multiple), la réponse de l'API s'interrompt. Ce problème ne peut pas être résolu du côté de propform — nous en avons discuté à plusieurs reprises avec onOffice.
Solution de contournement :
Si vous avez activé propform.io via le Marketplace onOffice, propform fonctionne avec un jeton Marketplace spécial, et non avec un utilisateur API classique. Dans ce cas, vous ne pouvez généralement pas ajuster vous-même les droits — ils sont prédéfinis par la configuration du Marketplace.
Si vous avez besoin d'un contrôle très fin des droits, passez à un utilisateur API classique avec son propre jeton et sa propre clé secrète. Instructions : Créer un utilisateur API.
Dans l'onglet « Droits de l'utilisateur API », sous Biens immobiliers, se trouve la case à cocher spéciale « Ne peut lire que les biens publiés sur le site web ».
> ⚠️ Ce paramètre remplace le droit général « Lire les biens immobiliers → tous ». Même si vous avez sélectionné « tous » ci-dessus, l’utilisateur API soumis à cette restriction ne voit que les biens activés sur un site web — tous les autres sont invisibles, comme s’ils n’existaient pas.
Symptômes :
Solution : Désactivez la case à cocher si vous souhaitez que propform fonctionne pour tous les biens immobiliers (y compris les objets d'évaluation/d'acquisition internes).
Après la soumission, le PDF est créé de manière asynchrone en arrière-plan — délai typique de 10 à 30 secondes. Si le PDF n'apparaît toujours pas dans l'onglet « Fichiers » de l'adresse ou du bien immobilier :
Cause fréquente : le filtre de fichiers dans l'onglet « Fichiers » est actif.
Dans l'interface onOffice, un filtre par défaut est souvent prédéfini dans l'onglet « Fichiers » (par exemple « images uniquement », « certificats énergétiques uniquement », « onglet propre uniquement »). Le PDF nouvellement créé ne répond peut-être pas aux critères du filtre et est masqué, bien qu'il soit présent.
Solution :
> 💡 Si le PDF n'apparaît toujours pas après la réinitialisation du filtre : attendez encore quelques secondes, puis appuyez sur F5. En cas d'absence répétée → Vérifiez les droits API (point 1) et les droits d'accès aux enregistrements (point 3).
Envoyez-nous un e-mail à hello@propform.io en indiquant :
Nous examinerons ensuite les journaux avec vous.