Nous avons objet A avec un lien N,N vers un objet B.
Cet objet B est le père d’un objet hérité B2.
Dans les Links de A, j’ai B avec Visible panel = oui et B2 avec Visible panel = non.
Si je merge deux instances de A, dans la vue de merge en bas, je vois bien les lignes de B à cocher ou non, mais pas les lignes de B2.
Même si je coche toutes les lignes de B, quand je clique sur Merge, elles sont supprimées.
En effet, en parcourant les links, le merge passe sur B, conserve, puis sur B2 et supprime.
Mes questions sont les suivantes :
est-ce voulu qu’en cas de merge, on ne puisse choisir que les links visibles ? Les non visibles doivent-ils être gérés par code ? Sinon ils sont supprimés automatiquement
comment gérer le cas d’objet hérité décrit plus haut ? Est-ce que ça doit aussi être géré par code ?
S’agit-il bien d’une N/N ? Dans le cas des N/N, ce serait plutôt l’objet de relation portant la N/N qui apparaîtrait dans les links de A?
Je vais partir du principe qu’on parle d’une 1/N pour reproduire ton cas.
2) Quelques tests
J’ai pu reproduire les cas suivants dans le cas d’une 1/N simple
avec panel visible, le merge:
propose de merger les objet liés
supprime les objets liés non sélectionnés
avec panel non visible, le merge
ne propose pas de merger les objet liés
supprime les objets liés non proposés
On peut d’ores et déjà se prononcer sur ta première question :
Je vais reboucler en interne, mais que ce soit voulu ou non, la suppression lors d’un merge d’objets liés du simple fait de la non visibilité du panel me semble un peu brutale.
Je te confirme que le cas de la visibilité du panel n’est pas correctement géré et que ça devient un point d’interrogation / design. En effet la visibilité du lien contrôle effectivement la visibilité du panel, mais c’est conceptuellement plus large et ça contrôle le droit des utilisateurs à voir ce lien. Par conséquent, ce lien n’apparaît pas, et le merge doit :
soit avoir un comportement par défaut (si l’utilisateur n’a pas les droits, alors on merge / on supprime / on interdit le merge)
soit avoir un comportement modélisé au niveau du lien, mais ça tient de la feature request
Sans envisager de modif socle, j’aimerais essayer avec toi une alternative: modifier la visibilité du lien dans le cadre des instance de merge dans le postLoad de l’objet A (cf javadoc getLink):
public class ObjetA extends ObjectDB {
private static final long serialVersionUID = 1L;
@Override
public void postLoad() {
// Hack to avoid Simplicité's behaviour of "deleting invisible links on merge".
if(isMergeInstance())
getLink("ObjetB2", "idObjetA").setVisible(true);
}
}
Pourrais-tu tester cette solution et me dire ce que tu en penses dans ton cas d’usage? On pourra dans un second temps ouvrir le débat sur le comportement idéal du merge.
Attention: il y a un bug connu qui va t’affecter dans ce cas et qui est corrigé dans la 5.3.26 à venir, qui fait qu’après un merge, Simplicité s’emmêle les pinceaux, et utilise l’instance merge en lieu et place de la main. Pense donc dans le cadre de ce test à vider le cache après ton merge pour rétablir les bonnes visibilités de panels.
Merci de ton retour rapide !
Dans notre cas le comportement attendu sera de garder par défaut ce qui n’est pas visible. J’ai donc mis ça dans le delete(), ça te semble correct ?
J’ai un peu refactoré ton code pour réduire sa complexité, en gros tu inhibe le delete pour les mergepanels quand le lien n’est pas visible.
L’approche postLoad que je t’ai proposée est un peu dans le même état d’esprit (hacker le comportement par défaut) et a la même conséquence (garder ce qui n’est pas visible), mais garde ma préférence. Elle te force certes à attendre la 5.3.26 pour être utilisable, mais est plus concise et donc plus facile à comprendre et maintenir, moins sujette aux changements de comportement de Simplicité.
Le souci c’est que (si j’ai bien compris) si j’utilise la méthode que tu proposes, les onglets non visibles vont apparaître dans l’écran de merge et ça va perturber les utilisateurs
Je vais, en parallèle, mettre à l’ordre du jour la modification du comportement par défaut dans le cas des liens non visible, de suppression à conservation.
