Bienvenue, Invité
Nom d'utilisateur : Mot de passe : Se souvenir de moi

SUJET : Documentation API REST

Documentation API REST il y a 10 mois 1 semaine #99430

  • tonio79
  • Portrait de tonio79
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
Je viens de tester avec la version 8.0. Effectivement les extrafields sont traités mais, gros souci, lors d'un update de commande, la fonction appelée est "insertExtraFields()" qui vide la table et insere les champs postés..! On perd donc tous les champs qui n'ont pas été mis à jour...
vu dans le fichier commonobject.class.php ligne 4926

Je vois qu'il y a pourtant bien une function "updateExtraField()".. N'est-ce pas celle-là qui devrait être appelé lors de l'update d'une commande :dry: ?

Qu'en pensez-vous ?
Dernière édition: il y a 10 mois 1 semaine par tonio79.
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 10 mois 1 semaine #99432

  • Jerome_m
  • Portrait de Jerome_m
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
qu'il faut composer, comme avec le reste de l'API :
- passer toutes les valeurs lors de l'update
- activer si ce n'est déjà fait le module des logs et TOUJOURS REGARDER CE QU'IL SE PASSE EN BASE DE DONNÉES QUAND ON UTILISE L'API REST
- toujours !!! cela vous fera gagner des jours de développement :)
Dernière édition: il y a 10 mois 1 semaine par Jerome_m.
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 10 mois 1 semaine #99433

  • tonio79
  • Portrait de tonio79
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
Euh.. merci pour ces précieux conseils mais j'ai évidemment la bdd ouverte en parallèle et je ne vois pas en quoi ça change le problème ...
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 10 mois 1 semaine #99434

  • Jerome_m
  • Portrait de Jerome_m
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
ça ne change pas le problème, ça permet de tout de suite de le détecter :) et en général, il est du côté de l'API... pardon... mais il y a beaucoup à faire encore sur cette API...
Dernière édition: il y a 10 mois 1 semaine par Jerome_m.
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 10 mois 22 heures #99729

  • jtraulle
  • Portrait de jtraulle
  • Hors ligne
  • Senior Boarder
  • Messages : 64
  • Remerciements reçus 24
  • Karma: 3
En effet, il y a beaucoup à faire encore au niveau de l'API mais elle a le mérite d'exister (c'est un travail en cours) ;)

En parlant de l'API, j'ai mis à jour mon Dolibarr vers la version 8.0 et j'ai vu les nouvelles fonctions liées à Stripe notamment la possibilité de lier un client Stripe à un Tiers Dolibarr. En creusant un peu, j'ai vu que c'était stocké en BDD dans la table llx_societe_account.

Une idée de comment indiquer l'identifiant client Stripe lors de la création/modification d'un tiers en utilisant l'API ?
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 10 mois 21 heures #99730

  • jtraulle
  • Portrait de jtraulle
  • Hors ligne
  • Senior Boarder
  • Messages : 64
  • Remerciements reçus 24
  • Karma: 3
Pour répondre à tonio79 (message #99430), pour moi, c'est correct.
En effet au sens REST strict, la méthode PUT met à jour une entité de façon complète tandis que la méthode PATCH permet de ne mettre à jour que les champs spécifiés tout en ne touchant pas aux autres champs de l'entité.
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 10 mois 21 heures #99733

  • jtraulle
  • Portrait de jtraulle
  • Hors ligne
  • Senior Boarder
  • Messages : 64
  • Remerciements reçus 24
  • Karma: 3
Pour répondre à mon précédent message #99729, il semblerait que cela ne soit pas géré pour l'instant.
J'ai vu la Pull Request suivante sur Github github.com/Dolibarr/dolibarr/pull/9016/files qui ajoute la gestion des RIB (donc stockés dans la table llx_societe_rib).

Je vais sans doute essayer de m'en inspirer pour ajouter la gestion des Interfaces de paiement dans
htdocs/societe/class/api_thirdparties.class.php
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 9 mois 4 semaines #99849

  • marine17
  • Portrait de marine17
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
Bonjour,
Je souhaite pouvoir générer des documents via l'API. (En l'occurrence une proposition commerciale, mais ce pourrait être un autre objet).

En suivant la méthode appliquée dans ce post : #85676, je parviens à mes fins. Mais la solution ne me convient pas, car elle impose de modifier le fichier natif api_proposals.class.php.

J'ai donc tenté de faire ce que la doc suggère :
Ajouter un nouveau service
Ajouter un nouveau service est aussi facile qu'ajouter un fichier nommé api_monmoduleobject.class.php dans le dossier htdocs/module/class. Vous trouverez des exemples dans htdocs/commande/class/api_orders.class.php

Le framework détecte automatiquement les API et elle devrait être visible dans l'explorateur.

Les méthodes et paramètres sont détectées en fonction de l'introspection réalisée dans les classes PHP de l'objet (htdocs/module/class/object.class.php) en utilisant les annotations trouvées dans la classe.

Pour une documentation à propos des annotations : github.com/Luracast/Restler/blob/master/ANNOTATIONS.md

J'ai copié, le fichier /htdocs/modulebuilder/template/class/api_mymodule.class.php comme /htdocs/comm/propal/class/api_mymodule.class.php

Puis y ai inclu ma méthode generatedocument (celle qui fonctionne lorsqu'elle est dans la classe Proposals native). La méthode s'affiche bien dans l'explorer :
GET /mymoduleapi/generatedocument/{id} (si je ne mets pas d'annotation @url)

mais j'ai une erreur 501 API not found (failed to include API file) lorsque j'essaye d'y accéder.

J'ai tenté plusieurs options (changé la méthode, mettre une annotation en entete de classe, sans succès...)

Quelqu'un aurait-il une solution à me proposer ? Une exemple de module custom serait bienvenu...
Merci d'avance...
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 9 mois 4 semaines #99852

  • jtraulle
  • Portrait de jtraulle
  • Hors ligne
  • Senior Boarder
  • Messages : 64
  • Remerciements reçus 24
  • Karma: 3
Bonjour,

L'API permet de générer de façon standard les différents documents (que ça soit des factures ou des propales).
Regardez du côté du endpoint
PUT /documents/builddoc



Pour une propale, vous devez indiquer proposal ou propal pour module_part et le doctemplate par défaut est azur. Pour le original_file, c'est de la forme REF/REF.pdf donc par exemple PR1808-0001/PR1808-0001.pdf
Dernière édition: il y a 9 mois 4 semaines par jtraulle. Raison: Infos complémentaires
L'administrateur a désactivé l'accès en écriture pour le public.
Cet utilisateur a été remercié pour son message par: marine17

Documentation API REST il y a 9 mois 4 semaines #99854

  • marine17
  • Portrait de marine17
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
Merci pour la réponse, mais si ce document n'est pas encore créé, comment puis-je faire : je ne peux pas remplir le champ original_file
C'est pour cela que je voulais passer par une action custom.
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 9 mois 4 semaines #99855

  • jtraulle
  • Portrait de jtraulle
  • Hors ligne
  • Senior Boarder
  • Messages : 64
  • Remerciements reçus 24
  • Karma: 3
Si le document n'est pas encore créé, il le sera à l'emplacement indiqué dans original_file lors de l'appel à builddoc.
Si ça ne fonctionne pas, assurez-vous que vous ayez validé la PR auparavant (endpoint POST /proposals/{id}/validate)
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 9 mois 4 semaines #99856

  • marine17
  • Portrait de marine17
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
Merci, cela fonctionne effectivement: à la validation de la proposition, un document est créé (même lorsqu'on passe par l'API), on peut alors l'utiliser en référence dans l'API documents/builddoc pour créer un nouveau document.

Mais si le document est encore en brouillon, je peux via l'interface normale créer un document (qui s'appelera (PROVnnn).pdf (bouton générer), mais je ne peux pas le faire via l'API.
C'est cette action que je voulais reproduire via l'API. Et c'est pourquoi je voulais créer une action custom.
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 9 mois 4 semaines #99858

  • jtraulle
  • Portrait de jtraulle
  • Hors ligne
  • Senior Boarder
  • Messages : 64
  • Remerciements reçus 24
  • Karma: 3
Marine,

Vous pouvez tout à fait le générer via l'API même si la propal n'est pas validée en fait.
{
  "module_part": "propal",
  "original_file": "(PROV2)/(PROV2).pdf",
  "doctemplate": "azur",
  "langcode": "fr_FR"
}

À la place de REF (qui n'est générée que lors de la validation), il vous suffit simplement d'indiquer (PROV<rowid>).
Je viens d'essayer et ça fonctionne parfaitement ;)

Le rowid vous est renvoyé lors de l'appel à POST /proposals quand vous créez votre propal.
Dernière édition: il y a 9 mois 4 semaines par jtraulle.
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 9 mois 4 semaines #99859

  • marine17
  • Portrait de marine17
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
Merci, OK, cela fonctionne. Je n'étais pas allée au bout des tests...
En effet, car lorsque je crée une propale depuis l'API, le fichier (PROVxxx).pdf n'est pas visible sur l'IHM, et pas physiquement dans le dossier /documents/propale. Je pensais donc qu'on ne pouvait le référencer ! Mais, il semble que l'on puisse ! Cool !

Merci, en tous les cas !
L'administrateur a désactivé l'accès en écriture pour le public.

Documentation API REST il y a 9 mois 2 semaines #100271

  • marine17
  • Portrait de marine17
  • Hors ligne
  • Fresh Boarder
  • Messages : 11
  • Karma: 0
Bonjour à tous,

Je travaille actuellement sur la création de propales via l'API REST.
Je n'ai pas trouvé de meilleur endroit que ce fil pour partager mes interrogations. S'il est un autre endroit spécifique sur cette API, veuillez m'excuser, et merci de me le signaler.

Je ne suis pas sûre de gérer correctement les dates, notamment la date de fin de validité.
Si je ne mets rien dans les données en CREATE, cela me donne une date en 1970...
J'ai tenté en valorisant plusieurs valeurs (fin_validite, date_validite) sans succès.

J'ai résolu le problème en UPDATANT juste après la création avec le champ fin_validite que je calcule.
Est-ce la solution normale ?
L'administrateur a désactivé l'accès en écriture pour le public.