setSave() ne fonctionne pas après création et redirection dans formulaire update

Problem description

Bonjour,

Les méthodes setSave() (et setReadOnly()) a un comportement différent lorsqu’on affiche le formulaire “update” en passant par la vue liste et lorsqu’on accède à ce formulaire après la création.

Steps to reproduce

Cas n°1 : setSave()

  1. J’ai un objet avec le code suivant :
package com.simplicite.objects.FgSandbox;

import java.util.*;
import com.simplicite.util.*;
import com.simplicite.util.tools.*;

/**
 * Business object SbTmpProduct
 */
public class SbTmpProduct extends ObjectDB {
	private static final long serialVersionUID = 1L;
	
	@Override
	public void initCreate() {
		//setReadOnly(false);
		setSave(true);
		setSaveAndClose(true);
		super.initCreate();
	}
	
	@Override
	public void initUpdate() {
		AppLog.info("DEBUG 0706 / SbTmpProduct / initUpdate", getGrant());
		//setReadOnly(true);
		setSave(false);
		setSaveAndClose(false);
		super.initUpdate();
	}
	
}
  1. En vue liste j’ai plusieurs lignes :

  1. Je clique sur une ligne :

Le comportement est bien celui attendu, les boutons “Enregistrer” et “Enregistrer & Fermer” ne sont pas présents (cf. initUpdate).

  1. Je retourne sur la vue liste et je clique sur le bouton “Créer”

Le comportement est bien celui attendu, les boutons “Enregistrer” et “Enregistrer & Fermer” sont présents (cf. initCreate).

  1. J’enregistre ma création. Le formulaire “create” est remplacé par le formulaire “update”.

Le comportement n’est pas celui attendu, les boutons “Enregistrer” et “Enregistrer & Fermer” sont présents alors qu’ils ne devraient pas l’être (cf. initUpdate). Je suis bien passé dans l’initUpdate, je retrouve bien mon log info mais les méthodes setSave() et setSaveAndClose() font rien dans ce cas ci.

  1. Je retourne sur la vue liste et je clique sur la ligne que je viens de créer (T12)

Cette fois le comportement est bien celui attendu, les boutons “Enregistrer” et “Enregistrer & Fermer” ne sont pas présents (cf. initUpdate).

Cas n°2 : setReadOnly()

  1. J’ai un objet avec le code suivant :
package com.simplicite.objects.FgSandbox;

import java.util.*;
import com.simplicite.util.*;
import com.simplicite.util.tools.*;

/**
 * Business object SbTmpProduct
 */
public class SbTmpProduct extends ObjectDB {
	private static final long serialVersionUID = 1L;
	
	@Override
	public void initCreate() {
		setReadOnly(false);
		//setSave(true);
		//setSaveAndClose(true);
		super.initCreate();
	}
	
	@Override
	public void initUpdate() {
		AppLog.info("DEBUG 0706 / SbTmpProduct / initUpdate", getGrant());
		setReadOnly(true);
		//setSave(false);
		//setSaveAndClose(false);
		super.initUpdate();
	}
	
}

  1. En vue liste j’ai plusieurs lignes :

  1. Je clique sur une ligne :

Le comportement est bien celui attendu, le formulaire est en read only et les boutons “Enregistrer” ne sont pas présents (cf. initUpdate).

  1. Je retourne sur la vue liste et je clique sur le bouton “Créer”

Le comportement est bien celui attendu, le formulaire n’est pas en read only et les boutons “Enregistrer” sont présents (cf. initCreate).

  1. J’enregistre ma création. Le formulaire “create” est remplacé par le formulaire “update”.

Le comportement est partiellement celui attendu, le formulaire est en read only mais les boutons “Enregistrer” sont présents alors qu’ils ne devraient pas (cf. initUpdate).

  1. Je retourne sur la vue liste et je clique sur la ligne que je viens de créer (T2)

Le comportement est bien celui attendu, le formulaire est en read only et les boutons “Enregistrer” ne sont pas présents (cf. initUpdate).

Technical information

5.2.6 : Instance /health
Platform]
Status=OK
Version=5.2.6
BuiltOn=2022-06-07 13:52
Git=5.2/473f811f8428d85cf4ef19fcc90ea2b47d774501
Encoding=UTF-8
EndpointIP=
EndpointURL=
TimeZone=UTC
SystemDate=2022-06-07 17:54:59

[Application]
ApplicationVersion=0.0.5
ContextPath=
ContextURL=
ActiveSessions=12
TotalUsers=7
EnabledUsers=4
LastLoginDate=2022-06-07 17:54:45

[Server]
ServerInfo=Apache Tomcat/9.0.63
ServerType=WEB
ServerActiveSessions=12
ServerSessionTimeout=30

[OS]
Name=Linux
Architecture=amd64
Version=5.4.0-107-generic
DockerImageName=centos7
SystemEncoding=UTF-8

[JavaVM]
Version=17.0.3
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.3+7
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=129705
HeapSize=406528
HeapMaxSize=2037760
TotalFreeSize=1760937

[Cache]
ObjectCache=214
ObjectCacheMax=10000
ObjectCacheRatio=2
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0
APIGrantCache=0
APIGrantCacheMax=1000
APIGrantRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=11.14 (Debian 11.14-1.pgdg90+1)
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.3.6
DBDate=2022-06-07 17:54:59
DBDateOffset=0
DBPatchLevel=5;P02;477f47d75700947c2e36d7bae9353a6e
UsingBLOBs=true

[Healthcheck]
Date=2022-06-07 17:54:59
ElapsedTime=204
5.1.22 : Instance /health

[Platform]
Status=OK
Version=5.1.22
BuiltOn=2021-12-29 12:46
Git=release/a4a4aafa93310ec3387ad178ae2001072320c3f3
Encoding=UTF-8
EndpointIP=
EndpointURL=
TimeZone=Europe/Paris
SystemDate=2022-06-07 20:31:41

[Application]
ApplicationVersion=SIORG_0.3.6.0
ContextPath=
ContextURL=
ActiveSessions=1
TotalUsers=95
EnabledUsers=83
LastLoginDate=2022-06-07 20:31:37

[Server]
ServerInfo=Apache Tomcat/9.0.58
ServerType=WEB
ServerActiveSessions=3

[OS]
Name=Linux
Architecture=amd64
Version=3.10.0-1160.62.1.el7.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=3421
DiskUsable=1595
DiskTotal=42052

[JavaVM]
Version=11.0.15
Vendor=Red Hat, Inc.
VMName=OpenJDK 64-Bit Server VM
VMVersion=11.0.15+9-LTS
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=442346
HeapSize=929792
HeapMaxSize=1998848
TotalFreeSize=1511402

[Cache]
GrantCache=0
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=50
ObjectCacheMax=10000
ObjectCacheRatio=0
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=11.3
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.3.3
DBDate=2022-06-07 20:31:41
DBDateOffset=0
DBPatchLevel=5;P01;8eec3aaa281ce44b39212dcadbfe22cf
UsingBLOBs=true

[Healthcheck]
Date=2022-06-07 20:31:41
ElapsedTime=7


Bonjour,

Merci pour vos explications.

Votre cas ne semble pas être un cas d’usage nominal en terme d’UX.
Il doit y avoir un problème de rechargement des metadata coté front (flag canSave, canSaveAndClose…), mais ce n’est pas la bonne méthode pour limiter les droits de mise à jour.

De base, l’utilisateur a le droit à l’erreur, et donc s’il peut créer, il peut en général modifier pour corriger ses éventuelles erreurs de saisie. Et une fois qu’il “valide” sa saisie (ex : en passant d’un état brouillon à actif), on peut brider l’accès à certains champs (par contrainte ou code dans l’initUpdate).

On va quand même regarder pourquoi ces metadata ne sont pas bien prises en compte quand le formulaire passe de “create” à “update”.

Mais posez vous la question de votre mode opératoire en terme d’UX, car on ne fait jamais comme ça.
L’accès aux champs est un process basée sur les données, pas uniquement sur une existence en base.

D’accord, merci François.

En effet, dans SI ORG on est dans un cas un peu particulier.
Lorsque l’utilisateur accède au formulaire “update”, celui-ci est par défaut en read only (setReadOnly dans initUpdate + setSave en fonction des cas). Pour pouvoir modifier le contenu, l’utilisateur doit cliquer sur une action custom qui débloque les champs et qui fait réapparaître le bouton “Enregistrer”.
Après la création, l’utilisateur doit donc retourner dans ce mode read only, s’il souhaite faire une correction il pourra toujours le faire en cliquant sur l’action custom.

Bonjour,

Oui le SI ORG est volontairement compliqué en terme d’UX.

Si un utilisateur fait une erreur de saisie, il devra cliquer N fois sur “modifier” pour repasser en mode édition et le perdre à chaque “enregistrer”. C’est une UX très discutable héritée des usages d’un ancien temps.

Dans Simplicité le fonctionnement par défaut est le suivant :

  • si l’utilisateur a des droits de mise à jour, il accède tout de suite en modification aux objets car c’est principalement son travail, on lui évite des click/reload rébarbatifs
  • s’il n’a qu’un doit de lecture, il ne peut que consulter.

Par ailleurs :

  • Pensez au cas du bouton “save & copy” s’il existe = l’initCopy est bien une création par recopie = il faut bien activer les boutons.
  • Le read-only n’agit pas sur les actions mais sur les fields sinon vous ne pourriez pas avoir de bouton “Passer en modification”.

Le front a été revu pour appliquer les metadata modifiées via setSave/setSaveAndClose… dans un initUpdate juste après création. Ce sera livré prochainement en 5.1.47 et 5.2.7.

ok, merci

Je pensais que le setReadOnly avait un impact sur les actions également d’après la description dans la JavaDoc mais ok ^^

public void setReadOnly​(boolean b)
Set globally read only : freeze fields and update actions, keep access to search, select and export

J’ai peut être trouvé un autre cas qui pose problème, cette fois ce n’est pas lors du passage “create” à “update” mais lors du passage “update” à “update” où les modifications dans le premier formulaire update font passer le formulaire en read only pour l’utilisateur dans le second formulaire update après enregistrement du premier (c’est un autre user qui prend la main pour continuer). Pour le moment je n’ai pas encore testé en 5.2.6, le problème vient peut être de mon côté.

Oui je parlais des actions spécifiques.
Je clos ce sujet, ouvrez un autre ticket si on parle d’autre chose.