Bonjour tomitomas,
Merci beaucoup pour ce super plugin ! 
Il y a un petit problème lors de la duplication d’un équipement avec le bouton consacré :
Source :
Clone :
Les personnalisation (nb sur widget et commande), ainsi que les actions et annivs ne sont pas repris.
Serait-il possible de corriger ça ?
Merci,
Bad
Jeedom Core : 4.3.21
birthday / stable : 2023-11-20 13:10:21
Salut,
La fonction « duplicate » est gérée par le core (cf. plugin template) et à ma connaissance elle n’est pas « interceptable » (out of the box)
my bad (sans jeu de mot 
) !
en preInsert je mets par défaut un certain nombre d’éléments dont ceux-ci …
Comme il m a été dit de faire
Je ne teste pas si qlq chose existe deja…
Puisqu on est sur un insert, je partais en effet du principe que c etait un equipement vierge.
un peu trop fastidieux a faire un test d existence sur toutes les clés… A moins qu une autre methode existe !?
Du coup, ca doit aussi vouloir dire que ca ne doit pas etre le seul plugin touché…!?
Des grands manitou auraient peut etre une idée/solution ? @Mips @Phpvarious @Salvialf @Loic
Hello,
Etant donné qu’avec la class preInsert, il n’y aucun moyen de savoir si elle a été appelée initialement par la fonction copy.
Seul moyen que je vois pour résoudre coté Core, c’est d’ajouter un argument supplémentaire dans eqLogic::save et DB::save pour conditionner l’appel au preInsert()
Ou alors dans la fonction copy() passer l’argument $_direct a true mais cela fait aussi perdre le preSave(), postInsert() ainsi que le postSave().
Edit :
Pour le cas de birthday, tu pourrais conditionner tes setConfiguration comme ceci :
if ($this->getConfiguration('birthdayInfos','empty') == 'empty') {
$this->setDefaultColor();
$this->setConfiguration('breakLine', 'n');
$this->setConfiguration('dateOption', 'always');
...
}
Ca ne me semble pas tres grave, puisqu on veut une duplication.
Les preX et postX n ont pas d utilité a ce moment précis, non ?
C’est ce que je pense aussi.
Non je ne suis pas d’accord là, on ne peut pas globalement faire un save « direct » lors d’un copy.
Peut-être que pour ce plugin ça irait mais il va y avoir des contre exemples.
Mais je n’ai peut-être pas bien compris la proposition?
L inverse doit aussi etre vrai
Tous les plugin qui initialisent certains choix par defaut a la creation d un equipement sont aussi concernés, et du coup je ne pense pas etre le seul dans ce cas.
En 4.3 tu pouvais faire des « selected » directement sur ta page php, ca n est plus vrai en 4.4 (cf echange + haut, pour lequel je n ai pas eu de suite)
A moins d avoir en effet mis en place un test qui a (a mon avis) pas vraiment de sens.
Une idee en particulier ?
On peut vouloir sauver une valeur en cache ou n’importe quel autre traitement lors du save d’un équipement.
Ce n’est pas au core de décider qu’il ne faut pas appeler les pre/post lors de la création d’un équipement que ce soit suite à une copie ou non
Salut,
J’ai sûrement loupé un truc, pas bien compris quelle est la demande d’ailleurs mais la solution ne serait elle pas de surcharger la fonction $eqLogic->copy() en la reprenant dans la classe du plugin et en ajoutant ce qui manquerai ?
Je pense qu’il y a l’embarras des solutions sans devoir modifier le core ou les autres plugins
celle-ci aussi:
C est au mieux un contournement, mais clairement pas une solution !
(merci @Phpvarious pour la proposition)
Je pense qu en l occurrence il ne s agit pas du seul plugin « impacté » par le fonctionnement actuel …!
Elle est somme toute assez simple
On reprend depuis le début du coup.
En 4.3 tu fais un :
<select class="form-control eqLogicAttr" data-l1key="configuration" data-l2key="showNb">
<option value="1">1</option>
<option value="2">2</option>
<option value="3">3</option>
<option value="4">4</option>
<option value="5" selected>5</option>
</select>
le selected permet d obtenir le choix 5 présélectionné par défaut lors de la création d un nouvel équipement.
En 4.4, le meme code fait afficher :
Du coup, choix « vide » par defaut, pas glop …
Comme mentionné plus haut, j ai ouvert un sujet dédié auquel @Loic a répondu qu il suffit d initier les valeurs dans le preInsert.
→ aussi bien en 4.3 qu en 4.4 j ai bien le bon choix par défaut qui est affiché a la création d un nouvel équipement
Notre ami @Bad remonte ici un dysfonctionnement : il essaie de dupliquer un équipement en utilisant le bouton « dupliquer » affiché par le core.
Or une fois l équipement dupliqué, il se retrouve avec tout sauf un équipement dupliqué :
le preInsert pour moi est censé s’appliquer lors de l’insertion, sur un équipement censé être « vierge ».
Il ne me semble donc pas utile de faire des tests sur l’existence ou non d’un paramétrage qui en théorie n’a pas lieu d’être …
donc la question :
comment faire une duplication propre via le core, sans intégrer des tests en principe « inutiles » ?
d’où les réflexions actuelles, et autres propositions faites par @Phpvarious
désolé ca n’a aucun sens, le postulat de base est faux.
Qui dit qu’on veut systématiquement recopier toutes les valeurs de l’équipement précédent?
qui dit que les initialisations sont toujours « en dur » ?
donc c’est au plugin à gérer dans ton preInsert suivant son cas qui n’est pas forcément une généralité.
ce n’est pas du tout un contournement de tester la situation avant de faire des actions.
C’est bizarre car l’objet de base est cloné dont la colonne configuration, j’ai testé vite fait et la configuration de l’équipement d’origine a bien été reprise.
OK c’est ton preInsert qui met une config par défaut si je comprend bien, d’où la proposition adaptée de @Phpvarious et la réponse de @Mips qui confirme également.
je ne dois pas comprendre le sens du mot « duplication » alors …??
d’ailleurs le core parle/utilise le « clone » (ligne 686 plus haut), que je ne dois pas comprendre non plus
Il me semblait que « clone » = copie integralement conforme a l initiale. (J’ai pas fait spé bio, je me trompe peut etre )
Il en a fait plusieurs en effet.
Si tu parles de celle avec le test dans le preInsert, le mot « adaptée » ne me semble pas … adapté
Mais c’est qu’il serait un petit peu chonchon notre ami @tomitomas 
Si je peux me permettre, tu as demandé les avis de 4 personnes quelques messages plus haut et 3 d’entre eux te donnent sensiblement la même réponse
Ou ronchonchon ?
Désolé pour le HS, j’ai eu un flash en te lisant 
[ma-vie-perso]
Grosse sinusite qui m empeche d’aller plonger depuis 3 semaines 
ca commence à me peser un peu c est vrai 
après ça m’empêche pas d’être sympa quand meme hein !!
reçu hier au boulot :
[/ma-vie-perso]
2.5 !
La réponse « faire un test » de @Phpvarious était l’initiale, avant qu’il creuse un peu et propose autres choses qui me paraissent + censées.
à priori à lui aussi …
Je ne veux pas lancer un débat de persévérants, mais je souhaitais à minima que le point soit abordé (et idéalement réfléchi ) d’où le ping à certains d’entre vous.
Si « on » dit que c’est mieux que chaque plugin se démerde à « faire un test lors de la création d’un nouvel équipement pour savoir si une config existe déjà » ( ← et c’est cette partie là qui m’ennuie sur le principe, perso), alors OK go for it, je m’en vais ajouter ce test !
Si on se dit que ya quand même peut etre mieux à faire … ça m’intéresse aussi
( perso la partie initialisation des valeurs par défaut de la 4.3 directement dans le html sans passer par le preInsert m’allait également très bien, et ne générait pas de soucis hein )
Hello,
Je ne pensais pas faire couler autant d’encre (ou taper autant de touches) avec mon « petit problème ».
Dans jMQTT je n’utilise pas preInsert/postInsert, mais uniquement preSave/postSave.
Je sauvegarde des valeurs en preSave dans une variable d’instance et je récup le tout en postSave pour mener d’autres action (en fonction de ce qui a changé).
Je différencie un nouvel eqLogic avec l’id : s’il est null en preSave, c’est un nouvel eqLogic. Selon l’état précédent, je fais aussi les modifs qui vont bien en postSave (et je re save en direct=true).
Bad
bien que je ne sois pas fan de la solution, dispo en beta du 26/12/2023