Documentation API REST

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)

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.

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 b[/b].
Je viens d’essayer et ça fonctionne parfaitement :wink:

Le rowid vous est renvoyé lors de l’appel à POST /proposals quand vous créez votre propal.

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 !

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 ?

Bonjour,

En effet, je reproduis ce comportement en v8.0
A priori le champ fin_validite est ignoré et la durée par défaut indiquée dans les paramètres du module semble toujours appliquée.

Solution de contournement, faire un update après coup mais en effet ce n’est pas très « propre » (et cela nécessite deux requêtes au lieu d’une).

Je vous conseille d’ouvrir un ticket d’anomalie sur https://github.com/dolibarr/dolibarr/issues/new car ce n’est en effet pas un comportement normal.

Bonjour,
J’ai un exemple qui fonctionne avec un champ « duree_validite », et en donnant une valeur en jours par rapport à la date du jour.
Je suis en v7.

Bonjour yves57,

Merci pour l’info. En effet, avec duree_validite, cela fonctionne également en v8.0 en passant un nombre de jours.

Bonjour à vous, et merci.

Je passe :
{
« date »: « 2018-10-12 »,
« socid »: « 1 »,
« statut »: « 0 »,
« duree_validitite »: 30
}

Et j’obtiens le 31/01/1970 comme date de fin…

Si j’envoie:

{
« date »: « 2018-10-12 »,
« socid »: « 1 »,
« statut »: « 0 »,
« duree_validite »: 30
}

J’obtiens comme date de validité le 31/01/1970

Bonjour,

La date doit être au format timestamp UNIX.

1 J'aime

Merci, c’était donc ca !

je vous propose une synhèse des bugs de l’API REST, avec les contournements,
j’y ai mis ce que j’ai expérimenté :


le document est accessible à tout le monde en lecture / écriture

Bonjour,
Je suis totalement nouveau sur Dolibarr, aussi merci d’excuser ma naïveté.
Je ne comprends pas « $fk_product = $newProductResult ».
D’après la documentation, le retour de la requête Create est un array au format JSON avec error et debug etc.
D’où vient l’id de l’enregistrement qui a été créé?
Merci pour votre aide.

Bonjour,

Les requêtes POST de création de nouvelles entitées renvoient l’id de l’enregistrement nouvellement créée en cas de succès (code HTTP 200) ou dans tous les autres cas le tableau JSON que vous évoquez :wink:

1 J'aime

Bonjour,
je découvre les API REST de dolibarr. J’essaie de développer des API supplémentaires pour un besoin métier, mais je me galère un peu.
Sur le wiki (https://wiki.dolibarr.org/index.php/Module_Web_Services_REST_(développeur)) il est indiqué
Ajouter un nouveau service est aussi facile qu’ajouter un fichier nommé api_monmoduleobject.class.php dans le dossier htdocs/module/class.
J’ai donc ajouté mon propre fichier, il est reconnu dans l’explorer, mais l’API ne fonctionne pas (« API not found (failed to include API file) »).
pour faire simple, j’ai juste copié / collé / renommé une API existante (users => customers) donc le code ne devrait pas poser de problème…

Merci

Nicolas

Pièces jointes :

@chag :laugh: :laugh: :laugh: :laugh: :laugh:

@godloff Bonjour,

Que souhaitez vous faire exactement avec l’API REST ?
En savoir un peu plus sur votre besoin permettra certainement de mieux vous orienter.

Bonne journée à vous :wink:

Bonjour,
je souhaite gérer des réservations de service par des clients via mobile, pour un POC.
Mon idée est d’utiliser la base client standard dolibarr pour créer (thirdparties POST) ou gérer (thirdparties PUT, GET) les comptes client.
Ca, j’ai réussi à le faire à peu près, mon API modifié répond à mon besoin pour l’instant.
Je voudrais maintenant gérer manuellement mes réservations en créant une table à la main dans la BDD et en accèdant à cette table via une nouvelle API.
J’aimerais donc créer une API Booking. Pour l’instant, j’ai juste copié / collé l’API users en la renommant, mais ma nouvelle API n’est pas reconnue. Je suppose donc qu’il y a plus d’actions à faire que juste mettre un fichier api_toto.class.php, qui contient une classe toto avec des methodes get, put, post etc.

@godloff Je suis un peu inquiet quand je lis que vous avez modifié l’API des Thirdparty. C’est assez dangereux de modifier directement le coeur de Dolibarr car cela posera problème lors des mises à jour (je vous déconseille donc de faire cela directement). Je ne sais pas ce que vous avez modifié et pourquoi mais on peut éventuellement en discuter ici également.

Ensuite, je vous déconseille également de créer une table « à la main » pour les mêmes raisons qu’évoquées ci-dessus. Voyez cette page du wiki https://wiki.dolibarr.org/index.php/Développement_module qui vous permettra d’adopter une approche plus propre pour étendre le coeur de Dolibarr et créer vos propres classes PHP DAO https://wiki.dolibarr.org/index.php/Développement_module#Cr.C3.A9er_vos_tables_SQL_et_les_classes_PHP_DAO_.28optionnel.29.

Pour l’API, du coup, votre fichier sera dans votre propre répertoire class/ de votre module (évitez de copier/coller et commencez avec un fichier minimal et juste une méthode GET par exemple).