Bonjour, nous avons détecté un bug lié au initrefselect,
lorsque l’on édite en liste un objet soumis au initref, si on modifie plusieurs champs avant de sauvegarder, seul le dernier est sauvegardé.
référence à ce post, peut etre que le bug vient du fix?
Merci de préciser votre version exacte et d’indiquer Defect quand vous fournissez un moyen de reproduire le problème. Votre pb n’est pas reproduit sur une version 5.2 à jour.
Le hook initRefSelect n’a strictement rien à voir avec la sauvegarde d’une liste.
Il est appelé lorsqu’on ouvre le popup de recherche de référence = filtre la liste des objets liés. Le bug corrigé était au niveau du passage de contexte du parent.
Le “save list” du front boucle sur les lignes à sauvegarder
Si le save remonte des erreurs, elles seront affichées sur chaque ligne concernée.
Sinon la liste se recharge en appliquant les filtres/tris = vérifiez que vos records n’on pas été déplacés suite au tri des colonnes modifiées (donc voir plus du tout présent sur la page courante, mais bien modifié en base, si on change A en Z, il faudra aller sur la dernière page…).
Pour la version il s’agit de la 5.2.20, lorsque je commente mon initRefSelect, le comportement redeviens normal et toutes les valeurs sont enregistrés simultanément.
Seul le champ contraint pose problème, les autres sont changés simultanément
@Override
public void initRefSelect(ObjectDB parent) {
if(parent!=null && parent.getName().equals("RheCmplvCol")){
//setFieldFilter("rheCmplvCmpId", parent.getFieldValue("rheCmplvcolCmpId"));
setDefaultSearchSpec("t.rhe_cmplv_cmp_id = " + parent.getFieldValue("rheCmplvcolCmpId"));
}
}
Merci pour ces précisions.
Effectivement vous positionnez un filtre permanent = une search-spec sur l’objet référencé avec un valeur contextuelle. Une search spec doit être utilisée pour un filtrage de bas niveau (lister certains types par exemple).
Le save refait un test d’existence de la référence sinon il ne change pas le champ.
Du coup il ne fonctionne que pour le dernier popup / row_id utilisé dans la search-spec.
Pourquoi ne faites-vous pas juste un filtre qui peut être effacé ensuite (les filtres setFilter sont des filtres end-user supprimables par le moteur, un search-spec est en général une règle de gestion permanente en fonction du record, des droits… jamais du parent object qui change tout le temps) ?
On va voir si on peut refaire un initRefSelect avant de faire le controle d’existence au save pour couvrir ce genre de paramétrage.
Le problème est résolu en passant par le setFilter, je ne connaissais pas cette subtilité de search-spec.
Merci pour vos explications.
Ok oui le search-spec est un bout de SQL “en dur” ajouté à l’objet, inaccessible à l’utilisateur.
On va tout de même regarder pour appeler l’initRefSelect au save car la search-spec n’est pas supprimable par l’utilisateur alors que le setFilter si : dans votre popup, le filtre peut être retiré, et ce n’est pas forcement souhaitable, dans ce cas on est obligé de passer par une search-spec sur l’objet ou sur le champ (cf field.setAdditionnalSearchSpec).
This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.
Après analyse, il n’est pas possible de rappeler l’initRefSelect au save.
Si vous devez absolument utiliser une search-spec, il faudra la retirer dans le preSelect pour que lorsque Simplicité cherche à savoir si l’enregistrement existe en back, il n’y ait plus le filtrage contextuel pour la UI :
@Override
public void initRefSelect(ObjectDB parent) {
if (parent!=null && parent.getName().equals("RheCmplvCol"))
setDefaultSearchSpec("t.rhe_cmplv_cmp_id = " + parent.getFieldValue("rheCmplvcolCmpId"));
}
@Override
public void preSelect(String rowId, boolean copy) {
setDefaultSearchSpec("1=1");
super.preSelect(rowId, copy);
}