Bonsoir,
Ça marche très bien.
Merci Beaucoup.
Je l’utilise avec Jelix. Ce petit framework gagne à être connu 
1 « J'aime »
Bonjour, je ne parviens pas à me loguer pour obtenir un token afin d’utiliser l’API
J’optiens la réponse suivante : 400Bad Request: Invalid value specified for reset. Expecting integer value
Quels login et password faut-il indiquer dans l’URL : ceux de la base de données ou ceux pour entrer dans Dolibarr ?
Merci
Bonjour,
Premièrement, regarde la cohérence entre le protocole http et https.
Ensuite, quel est ton opérateur ou hébergeur?
Pour ma part, l’utilisation de API REST n’a jamais fonctionné dans un environnement O2switch. Je dois revenir vers eux.
Il ne faut pas oublier la clef pour l’API que tu dois initialiser dans le profil de ton utilisateur; cele te permet d’avoir de suite ton API KEY
Cordialement
1 « J'aime »
pour os2switch, il y a une probleme dans leur implementation PHP, il faut faire un changement dans un fichier de dolibarr pour compenser.
dans le fichier index.php du dossier API, changer ligne 93
preg_match(’/index.php/([^/]+)(.*)$/’, $_SERVER[« PHP_SELF »], $reg);
preg_match(’/index.php/([^/]+)(.*)$/’, $_SERVER[« REQUEST_URI »], $reg);
source:
https://github.com/Dolibarr/dolibarr/issues/7623
C’est fonctionnel pour un de mes clients. Mais O2switch est à fuir en effet…
Bonsoir,
J’ai fait la modificatif sur une version 7.0.2 et pas de changement.
Message : failed to parse JSON/YAML response
Cordialement
avez -vous activer le curl dans les options du php ?
O2switch est pas cher mais vraiment à éviter et l’assistance est inutile… en plus avec la RGPD, aucune confidentialité a priori, ils voient tout…
Bonjour à tous,
Quelqu’un à t’il réussi à passer des attributs personnalisés lors de la création d’un objet ?
J’arrive à faire pratiquement tout ce que je souhaite avec l’API REST (création de Tiers, création de commande, génération des fichiers PDF associés) …
Le seul problème est sur les attributs personnalisés. Lors d’un GET, si je les défini manuellement dans l’interface Web de Dolbarr, j’arrive bien à les récupérer sous la forme :
{
"array_options": {
"options_nomattribut1": "valeur attribut 1",
"options_nomattribut2": "valeur attribut 2"
}
}
Cependant, lorsque je passe un tableau de la même forme en création (POST) ou modification (PUT) d’objet, cela semble être ignoré.
Avez-vous une idée lumineuse ? 
En vous remerciant par avance pour votre aide 
il faut ajouter ‹ array_options › => $extrafields où $extrafields est un array composé de $extrafields[$key] = $value;
J’avoue que j’ai beaucoup cherché aussi pour y arriver
1 « J'aime »
Super, merci beaucoup @ptibogxiv
J’avoue avoir essayé pas mal de combinaisons mais pas celle là.
Cela marche parfaitement 
Attention tout de fois, un PUT semble fonctionner et ne lève pas d’erreur en cas de doublon.
Je m’explique. Si j’ai un attribut idapp par exemple et que dans la configuration des attributs supplémentaires il est marqué comme unique. Lorsque j’édite un objet avec PUT, le body JSON retourné semble toujours OK même si l’édition n’a pas fonctionné parce que la validation de l’unicité échoue. Ce qui semble assez étrange. Dans ce cas, retourner une HTTP 409 (Conflict) semblerait logique. De même il est possible de passer des champs/propriétés qui n’existent même pas lors d’un POST ou PUT sans que ça ne gène le moins du monde l’API. Je trouve que ça devrait lever une HTTP 400 (Bad Request).
Par ailleurs, y-a-t-il quelque part une documentation sur le modèle de données ? En effet, au fur et à mesure de mes tests, je me suis rendu compte que de nombreux champs semblent ne plus être utilisés mais sont toujours présents dans le schéma de données (colonnes en base de données).
Bonjour,
Curl est activé par défaut et j’ai également choisi les options json et yaml
9a ne fonctionne toujours pas
Cordialement
Bonjour,
je suis confronté au même problème mais je ne comprends pas où ajouter cette ligne …
j’envoie comme datas un json_encode de [‹ array_optiosn › => [‹ options_nomdemonchamp › => valeur]] mais ça ne fonctionne pas…
si je mets un nom d’extrafield inconnu je le vois bien dans le retour du curl, ajouté aux array_options, mais si je mets un champ existant, l’update ne se fait pas.
help please
Bonjour,
Si l’update ne se fait pas, c’est probablement parce qu’une contrainte d’intégrité n’est pas satisfaite ou qu’une validation échoue. Essayez de modifier manuellement depuis l’interface web de Dolibarr pour voir si un message d’erreur s’affiche (cela peut vous aider à diagnostiquer le problème). Dans mon cas, j’avais coché unique ou pas de doublon (je ne sais plus comment s’appelle l’option) pour mon extrafield et j’essayais de mettre à jour une fiche avec une valeur pour cet extrafield qui existait déjà dans une autre fiche
1 « J'aime »
ok je vais essayer ça merci !
Bon et bien ça me veut pas marcher … 
aucun souci pour un champ natif (ref_client par exemple), mais pas pour un extrafield…
Mes champs n’ont pourtant aucune contrainte, j’arrive bien à les modifier dans l’interface, mais aucun update possible … (voir la capture)
Merci quand même / d’avance !
Note : dans la fonction « update » de commande.class, je ne vois pas à quel moment elle prend en compte les extrafields… 
petit point tout bête mais est ce que « Peut toujours être édité » est bien coché dans la config de l’attribut supplémentaire ?
Oui oui bien sûr …!
Bonjour,
Est ce que quelqu’un peut nous aider sur cette problématique qui est toujours d’actualité et vraiment bloquante pour nous ?
Rappel du pb publié par Tonio79 qui travaille avec moi :
Problème sur les attributs personnalisés. Pas de soucis pour récupérer les éléments avec un GET,exemple :
{
« array_options »: {
« options_nomattribut1 »: « valeur attribut 1 »,
}
}
Cependant, lorsque je passe un tableau de la même forme en création (POST) ou modification (PUT) d’objet, cela semble être ignoré.
j’envoie comme datas un json_encode de ] mais ça ne fonctionne pas…
Si je mets un nom d’extrafield inconnu je le vois bien dans le retour du curl, ajouté aux array_options, mais si je mets un champ existant, l’update ne se fait pas.
Pas de contrainte d’intégrité, pas de contrôle de valeurs, aucune erreur pour modifier les champs personnalisés depuis l’interface de Dolibarr, le critère « Peut toujours être édité » est bien coché dans la config de l’attribut supplémentaire…
On sèche, là !
Please Help !
Gaëlle
extrait de mon code focntionnel pour mettre a jour tiers et adhérent mais normalement c’est le même principe pour les commandes, factures
[code]
foreach ($resultatsa as $posta) {
$extrafields[$key] = $value;
}
$infomember = [
‹ login › => $current_user->user_login,
‹ morphy › => $current_user->billing_type,
‹ civility_id › => $current_user->billing_civility,
‹ firstname › => $current_user->user_firstname,
‹ lastname › => $current_user->user_lastname,
‹ array_options › => $extrafields
];[/code]
Bonjour,
Merci mais on a déja essayé.
Il semblerait que l’API refuse les mises à jour sur les données existantes d’une commande créée dans l’interface Dolibarr.
Quelqu’un a t il déja eu le problème ?
Bonjour
Quel est le statut de la commande? Avez vous essayé sur une commande en brouillon?
Fred
