Allow direct recording in JS of the fields below

[lmag]

Feature Request

Use case

1. Click to edit
2. Choice of field
3. Click to save

there are fields for direct modification like

Suggested implementation

@todo GIFF UI.UX

Suggested steps

@todo

[hregis]

@lmag tu fais de la régression ?? 😄 on peut aussi se servir d'un bloc note, d'une calculatrice et d'un stylo !!

[lmag]

Et oui je note cela à l'arrache pendant le GIFF UI/UX ...Écouter, comprendre, noter, valider en même temps avec mon petit cerveau cela ne passe pas :) mais après je le reprends ...

[lmag]

Là c'est un peu mieux @hregis

[hregis]

@lmag ça serait en effet un gain de temps non négligeable que j'ai essayé d'implémenter depuis le début mais le fait de devoir garder l'application fonctionnel sans Javascript ça devient vite décourageant car ça oblige souvent à faire du code en double...

[hregis]

@lmag il existe déjà un fonctionnement de ce type que j'avais implémenté il y a un bail mais qui est caché au fin fond d'une constante : MAIN_USE_JQUERY_JEDITABLE et qui permet d'éditer rapidement des champs, mais il faut convaincre à nouveau le grand chef ! 😄

[hregis]

@lmag ça utilise les retours ajax "/core/ajax/loadinplace.php" et "/core/ajax/saveinplace.php"

[hregis]

@lmag et dans la fonction "editfieldval()" il y a :

// When option to edit inline is activated
if (getDolGlobalString('MAIN_USE_JQUERY_JEDITABLE') && !preg_match('/^select;|day|datepicker|dayhour|datehourpicker/', $typeofdata)) { // TODO add jquery timepicker and support select
	$ret .= $this->editInPlace($object, $value, $htmlname, ($perm ? 1 : 0), $typeofdata, $editvalue, $extObject, $custommsg);
}

[hregis]

je viens de regarder le code en v20 et l'utilisation de "editfieldval" a été limité qu'à certains champs et si on active edit inline il y a des erreurs avec MAIN_SECURITY_CSRF_WITH_TOKEN
peut-être corriger et améliorer ce mode afin de ne pas réinventer la roue ?

[hregis]

C'est dommage que ce mode de fonctionnement n'est pas été amélioré car ça permet justement de cliquer sur la valeur, le champ devient éditable, on le modifie et tape entrée ou on clique ailleurs et ça enregistre sans recharger la page.

[hregis]

@lmag jquery jeditable n'est plus maintenu et doit être remplacé par celle-ci qui n'a pas de dépendance avec jquery

https://github.com/deltablot/malle/

la démo : https://deltablot.github.io/malle/

je peux regarder pour faire la migration dans la dev ?

[hregis]

@lmag je vais implémenter Malle "https://github.com/deltablot/malle", ç'est du Typescript / Javascript sans aucunes dépendances et bien plus performant.

[hregis]

https://deltablot.github.io/malle/api/interfaces/Options.html

[lmag]

Un grand merci @hregis ! @john-botella ça à l'air bien cela https://deltablot.github.io/malle/api/interfaces/Options.html un avis ?

[thersane-john]

J'apprécie beaucoup cette approche du point de vue du code, car elle suit une logique événementielle similaire à celle du live edit que j'avais créé sur les modules ScrumProject et AdvancedKanban d'ATM. Cependant, cette classe JavaScript va encore plus loin, ce qui est vraiment intéressant.

Une petite remarque qui me vient à l'esprit : il serait important, lors de la mise en place initiale, de créer une fonction JavaScript spécifique à Dolibarr ou une classe JavaScript pour offrir une interface simple avec ce système. Cela permettrait, si nécessaire, de le remplacer plus facilement à l'avenir. Il serait préférable d'intégrer cela dès le début, car les premiers éléments serviront de base pour la suite.

Cela me fait aussi penser qu'il serait utile d'avancer sur la P.O.C. de la classe JavaScript DoliContext, qui serait chargée sur chaque page de Dolibarr. Elle permettrait d'offrir des outils préétablis avec un mode de fonctionnement basé sur les événements (un concept que l'on retrouve en partie dans le module Kanban d'ATM). Cela inclurait notamment la gestion et la protection du token dont "malle" aura besoin. Mais avant tout, il faudrait que je prenne le temps de créer une issue pour expliquer en détail ce concept, ainsi que les bénéfices qu'il apporte tant aux intégrateurs qu'à Dolibarr.

[lmag]

@hregis A priori, tu as visé juste ! Il te reste plus qu'a venir au prochain DevCamp à Valence et/ou au point sur le GIFF UI/UX

[hregis]

@john-botella
@lmag tu m'en vois ravi 😃

j'ai eu l'accord de @eldy pour enlever "jQuery-Jeditable" (non fonctionnel) et de mettre en test "Malle",
par contre "Malle" utilise des input de type "date" et "datetime-local' et ce type de champ posait des soucis à l'époque,
voici la réponse de Laurent :

"Les calendrier qui se basent sur le html du navigateur ne sont actuellement pas compatible avec dolibarr, 
car ils s'appuient sur la langue du navigateur et non la langue configurés dans Dolibarr. 
Il y a déjà dans dolibarr une option pour s'appuyer sur le calendrier du navigateur
Mettre MAIN_POPUP_CALENDAR = html
et prendre la dernier dev (j'ai corrigé ce jour un buginou dessus)

Toutefois, cela reste pas suffisant. La compatibilité avec dolibarr sur la langue n'est pas complète actuellement. 
Il y avait d'autres pb vis à vis du timezone ou du caractère de séparation de date mal géré pour les langues exotiqueset d'autres trucs mais me souviens plus...."

à voir si depuis il ne serait pas possible de régler ces soucis.

sinon je pensais aussi rajouter pour test un Typescript de "Select2" :

https://github.com/ivkan/ts-select2

ou celui là

https://bluzky.github.io/nice-select2/

[hregis]

un peu de doc :
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local
https://youmightnotneedjquery.com/