Bonjour
Avant d’aller plus loin dans une éventuelle déclaration de bug (je suis au top maintenant…) quelqu’un peut il me dire si la constante SOCIETE_KEEP_PRESELECT_CURRENT_USER_AS_SALESREP_ON_CREATE est toujours utilisée ou obsolète en V19.
Si obsolète, comment peut on paramétrer proprement le même résultat (quand un utilisateur créé un tiers il lui est automatiquement affecté. La modification manuelle dans la fiche tiers restant faisable évidemment).
Elle était bien cette constante…
Francis
Bonsoir,
elle sort d’où celle la ??? je suis remonté jusqu’à la version 10.0 et je ne l’ai pas trouvé dans le code source 
un passage sur github nous amène ici
et donc on peut remonter sur le dépôt git suivant
mais rien dans l’arbre du dépot git officiel …
Éric
Bonsoir
Merci pour cette recherche.
Ce qui veut dire que cette constante a été abandonnée ? Et qu’il n’existe pas de solution pour gérer ce mode fonctionnement ?
Francis
Bonsoir,
en fait ma question initiale reste sans réponse: elle sort d’ou ? dans quelle version aviez vous cette variable ? une fois qu’on aura identifié ça on pourra « remonter le fil » …
Bonjour
Répondre à la question : d’où vient elle ? s’avère bien compliqué…
Après moult recherches dans mes mails, mes fichiers et papiers diverses, je ne retrouve aucune trace de l’origine de celle-ci…
Le fait est que cette fonctionnalité (affectation en tant que commercial au user qui créé le tiers) est par défaut dans les versions inférieures à la V8. En V8 cette fonctionnalité disparait pour ne s’appliquer que dans le cas où l’utilisateur n’a pas les droits de voir les tiers ne lui étant pas affectés.
J’ai donc commencé à utiliser cette constante lors de mon passage en V8…
Cette fonctionnalité étant pour moi indispensable.
Je ne me crois pas capable de l’avoir créer seule à l’époque… pourtant j’aurais aimé être son auteur tellement je la trouve magnifique…
Bref, je m’en vais donc la réimplanter dans ma V19, le passage par les paramétrages des valeurs par défauts et l’utilisation de USER_ID n’étant pas fonctionnel (a priori pas de nom HTML sur cette variable).
Faut-il la réintroduire dans le core ? Suis-je seul à avoir ce besoin?
Sur le principe, je tague ce sujet à résolu. A voir si les « dolibarr Bosses » veulent s’emparer du sujet…
Francis.
NB : elle est vraiment belle cette constante…
en fait c’était bien ça ma question
Mais le hic c’est que j’ai beau me mettre sur le dépôt git de la version 7.0 je ne voit pas cette variable !!!
rgrep SOCIETE_KEEP_PRESELECT_CURRENT_USER_AS_SALESREP_ON_CREATE *
→ rien
Oui je suis d’accord.
Jusqu’à la V8 c’était standard (sans constante) : extrait du code V7 → lignes 1326
// Assign a Name
…
print $form->select_dolusers((! empty($object->commercial_id)?$object->commercial_id:$user->id),‹ commercial_id ›,1); // Add current user by default
…
Lignes de code de /societe/card.php.
En V8 on trouve la version actuelle sans l’attibution du $user->id par défaut dans le champs lors de la création.
Francis
okééééééééééé mais pour ce qui est de la vie de cette variable SOCIETE_KEEP_PRESELECT_CURRENT_USER_AS_SALESREP_ON_CREATE elle n’a jamais été dans le core on est d’accord ?
donc si on rembobine: entre v7 et v8 il y a eu un changement de mode de fonctionnement: lors de la création d’un tiers l’utilisateur qui créé le tiers n’est plus automatiquement lié comme contact commercial
je viens de faire un comparatif entre 7 et 8 en fait l’amélioration de fonctionnalité de la 8 par rapport à la 7 sur ce point est qu’en version 8 il est apparu la possibilité de choisir qui est le contact commercial du tiers alors qu’en 7 il n’y avait pas le choix c’était l’utilisateur qui créé le tiers point
donc il semble effectivement qu’il manque un truc qui serait le choix par défaut dans la liste déroulante … mais pourtant on dirait bien que c’est dans l’idée de ce bout de code extrait de la 8.0
$selected = (count(GETPOST('commercial', 'array')) > 0 ? GETPOST('commercial', 'array') : (GETPOST('commercial', 'int') > 0 ? array(GETPOST('commercial', 'int')) : (empty($user->rights->societe->client->voir)?array($user->id):array())));
Je n’arrive pas à lire ce genre de code … alors un petit coup de convertisseur me donne ça
if (count(GETPOST('commercial', 'array')) > 0) {
$selected = GETPOST('commercial', 'array');
} else {
if (GETPOST('commercial', 'int') > 0) {
$selected = array(GETPOST('commercial', 'int'));
} else {
if (empty($user->rights->societe->client->voir)) {
$selected = array($user->id);
} else {
$selected = array();
}
}
}
et donc à moins que je me soit planté dans la déconstruction du ternaire imbriqué … c’est que c’est le développeur qui s’est planté dans la fin et à inversé le selected = du selected = user_id
donc je vous invite à déconstruire le double ternaire et me dire s’il est bien ou pas ?
à mon avis il faudrait plutôt avoir
$selected = (count(GETPOST('commercial', 'array')) > 0 ? GETPOST('commercial', 'array') : (GETPOST('commercial', 'int') > 0 ? array(GETPOST('commercial', 'int')) : (!empty($user->rights->societe->client->voir)?array($user->id):array())));
ou
$selected = (count(GETPOST('commercial', 'array')) > 0 ? GETPOST('commercial', 'array') : (GETPOST('commercial', 'int') > 0 ? array(GETPOST('commercial', 'int')) : (empty($user->rights->societe->client->voir)?array():array($user->id))));
mais bon …
On est d’accord ! Elle est belle mais n’est pas dans le core (ce que je découvre grâce à vos recherches et les miennes…).
Pour répondre à mon besoin, la condition liée à la belle constante est introduite dans la 3ème boucle if :
if(empty($user->rights->societe->client->voir) || "MaBelleConstante > 0))
Donc en positionnant MaBelleConstante à autre chose que 0, à la création du tiers le $user->id est affecté en tant que commercial par défaut. On peut le supprimer ou le modifier, en ajouter un autre mais par défaut une affectation existe à la création du tiers, et j’ai besoin de ce type de fonctionnement.
On doit pouvoir faire la même chose plus proprement avec les valeurs par défauts mais a priori ça ne fonctionne pas faute de nom sur le champs HTML.
Francis
non non @Le_Reparateur je pense qu’il s’agit uniquement d’un bug de l’écriture des double ternaires …tout est déjà prêt mais il n’y a qu’une inversion à la fin qui fait que la variable est affectée à un array() (vide) au lieu de user-id !
(je suis en train de tester)
bingo c’est ça !
un dolibarr 18 classique:
et après avoir ajouté le ! au bon endroit dans la fin du 2° ternaire
le commercial est affecté par défaut à l’utilisateur qui est en train de saisir la fiche
la soluce est
Je viens de faire la PR sur dolibarr-14 … j’aurais pu remonter jusqu’à la 8 mais bon ça commence à faire loin
Parfait
Merci pour le test
Je duplique sur ma V19 de test !
Novice sur Github : est ce qu’il faut aussi faire quelque chose pour la V19 ou ça va « remonter » tout seul ?
Francis
Francis
Hello,
ça devrait remonter tout seul, mais pour le moment ce n’est pas merger.
C’est une des magie de git, ça « remonte » facilement pour peu que le code n’ai pas bougé de trop entre les versions
donc dans ce genre de situation quand on identifie un bug on regarde depuis quand il est « actif » et si son estime que sa « remontée » sera automatique alors on pousse un correctif sur une version assez ancienne pour que tout le monde en bénéficie
pour ma part j’ai conclu (tout seul) une sorte de principe de prendre la 14.0 comme point de départ en guise d’entraînement pour un truc plus global: nous sommes un petit nombre à aimer voir sortir un jour une version LTS officielle de dolibarr (LTS = maintenance longue).
OpenDSI/Easya le fait déjà avec leur version « rebrandée » de dolibarr et ils s’appuient justement sur la 14 donc tout ce qu’on peut faire comme correctifs en prenant la 14 comme base permet indirectement de faire que « leur » version LTS bénéficie des correctifs
Donc autant que ma montée en compétence sur git bénéficie aux copains en espérant que si un jour on arrive à faire sortir cette LTS toute cette expérience accumulée serve à quelque-chose … Par ce biais j’ai compris cette histoire de « remontée automatique d’un patch le long des versions » et les limites (d’ou ma remarque concernant « si le code n’a pas trop bougé »).
À l’inverse un correctif envoyé sur la 19 n’a quasi aucune chance de retomber en 14 et donc c’est « moins sympa » pour les utilisateurs qui restent sur des versions précédentes.
oui je pense que pour le moment Laurent est en train de se gratter la tête en se demandant quel est le doux dingue qui a osé produire ce code si peu lisible … oups c’est lui 
Bonsoir,
Merci pour ces explications claires et précises !
Je regrette juste cette belle constante…
Je la remets ici pour qu’elle puisse être inhumée dignement :
SOCIETE_KEEP_PRESELECT_CURRENT_USER_AS_SALESREP_ON_CREATE
RIP !!!
Francis
Hello le forum,
Sans toucher au code, je parviens au même résultat via Valeurs/filtres/tris par défaut
et la configuration suivante
C’est très pratique les valeurs/filtres et tris par défaut, quoique parfois un peu compliqué à configurer pour ceux qui ne lisent pas le code source de la page …
Bonne soirée à tous
Bonsoir
Sur quelle version ?
Merci
Bonsoir,
vraiment la je dis … 
niveau maîtrise de dolibarr et connaissance des possibilités … waw ! 
Dire que nous avons passés des heures à creuser le bug pour que la solution finale soit de un caractère … et voila que le même résultat était finalement « si facile » avec isamuse !!! J’admire et j’aime beaucoup ce genre de choses !!!
