Les modifications réalisées sur un champ de l'objet dans la pop-up de confirmation d'une action ne sont pas postées

Request description

Bonjour,

Si on modifie la valeur des attributs dans une pop-up de confirmation d’action les nouvelles valeurs ne sont pas conservées après avoir cliqué sur le bouton “Confirmer”.

Nous avions constaté le même comportement il y a un peu plus d’un an lors du passage d’une version mineure de la 5.1 à une autre. Je n’ai pas réussi à retrouver le post dans le forum mais ce comportement n’avait pas été considéré comme un bug mais comme une demande d’évolution de votre côté. Une nouvelle version de la 5.1 était sortie peut de temps après avec l’évolution pour conserver les modifications réalisées dans la pop-up (la Doc Simplicitié est KO je n’ai donc pas pu regarder les releases notes de la 5.1 pour retrouver la version en question :confused:).

Steps to reproduce

En partant du module de Demo :

  1. J’ai créé une nouvelle action pour l’objet DemoOrder avec le paramétrage suivant :

  1. Dans le code de DemoOrder j’ai ajouté les méthodes suivantes :
    @Override
	public void initAction(Action action) {
		
		String actionName = action.getName();
		String lang = getGrant().getLang();
		
		if ("DEMO_ORD_STATUS-P-V".equals(actionName) || "DEMO_ORD_CUSTOM_VALIDATION".equals(actionName)){
			
			ObjectField f = action.getConfirmField(lang, "demoOrdDeliveryDate");
			f.setUpdatable(ObjectField.UPD_ALWAYS);
			f.setRequired(true);
		}
		
	}
	
	public String customValidation(Map<String,String> params) {
		
		for (Map.Entry<String,String> entry : params.entrySet()) {
			AppLog.warning("DEBUG / customValidation / " + entry.getKey() + " : " + entry.getValue(), null, getGrant());
			setFieldValue(entry.getKey(), entry.getValue());
		}
		
		setStatus("V");
		
		try {
				
			var bot = new BusinessObjectTool(this);
			bot.validateAndUpdate();
			
		} catch(ValidateException | UpdateException e) {
			
			AppLog.error("Error", e, getGrant());
			return e.getMessage();
			
		}
		
		return null;
		
	}
  1. J’ouvre le formulaire d’une commande à l’état “En attente”. La date de livraison est “21/09/2023 08:00:00”.
  2. Je clique sur l’action “ORD CUSTOM VALIDATION” :

  1. La pop-up de confirmation s’ouvre, je modifie la date de livraison pour mettre “10/09/2023 08:00:00” et je clique sur “Confirmer” :

  1. La commande passe bien à l’état “Validée” comme indiqué dans le code Java, mais la date de livraison indiquée dans la pop-up de confirmation n’a pas été conservée :

Dans les logs on peut voir que la méthode “customValidation” ne reçoit pas dans le paramètre “params” la nouvelle valeur pour la date de livraison :

Avec Simplicité 5.1.62 et 5.2.47 je n’ai pas ce problème, les modifications réalisées dans la pop-up sont bien conservées après avoir cliqué sur “Confirmer” et avec le même code Java.

Technical information

Instance /health

[Platform]
Status=OK
Version=5.3.14
BuiltOn=2023-09-14 16:00
Git=5.3/3426322921bcc8643efdc55d9062fa8fd800eeb8
Encoding=UTF-8
EndpointIP=
EndpointURL=
TimeZone=UTC
SystemDate=2023-09-18 15:43:05

[Application]
ApplicationVersion=1.0.0
ContextPath=
ContextURL=
ActiveSessions=1
TotalUsers=7
EnabledUsers=5
LastLoginDate=2023-09-18 15:43:00

[Server]
ServerInfo=Apache Tomcat/9.0.80
ServerType=WEB
ServerActiveSessions=1
ServerSessionTimeout=30
CronStarted=true

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

[JavaVM]
Version=17.0.8.1
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.8.1+1
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=296822
HeapSize=512000
HeapMaxSize=2007040
TotalFreeSize=1791862

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

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=13.12 (Debian 13.12-1.pgdg120+1)
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.6.0
DBDate=2023-09-18 15:43:05
DBDateOffset=0
DBPatchLevel=5;P03;6fe15f9e90e4e748520be6bc2eee7a45
UsingBLOBs=true

[Healthcheck]
Date=2023-09-18 15:43:05
ElapsedTime=113

Bonjour Florent,

Merci pour le niveau de détail. Je ne me rappelle pas de ce ticket.

Actuellement dans une action :

  • Les champs qui appartiennent à l’objet servent à en confirmer la saisie, donc en lecture : l’idée centrale est bien de controler la valeur saisie dans le formulaire qui lui seul doit porter les règles de saisie, contraintes, code front éventuel inter-champs, formatage ou autre…
  • Les autres champs de l’action sont bien en saisie pour préciser ce que doit faire l’action en back, en dehors de l’objet = paramètres de l’action.

Si on ne valide pas le popup (une date, un PDF… de l’objet), on revient à la saisie sur le formulaire qui lui seul est garant des données saisies en front.

Dans ton exemple donné sur la démo, il faudrait vérifier que la date est modifiable en fonction du statut de la commande (contrainte ou autre règle de validate…), ce n’est pas le rôle du popup.
Il faudrait créer un autre champ date dédié, et dans le code back venir écraser la date de livraison par celle-ci si l’état permet de le faire = réimplémenter les règles sur la date de livraison.

Bref autoriser la re-saisie dans le popup d’un champ de l’objet, impliquerait d’y réimplémenter toute la logique métier, ce qui n’est pas souhaitable. Ce besoin va vite devenir d’y ré-appliquer des contraintes, d’afficher des listes N,N en pillbox, etc. On peut toujours mettre du script dans le template de l’action mais c’est peu maintenable.

La confirmation d’une action ne doit pas avoir trop d’intelligence, car ce serait y déporter la logique métier.

Pour un cas simple, si on veut juste changer un champ sans règle comme un commentaire, on peut effectivement imaginer envoyer la valeur si le champ est devenu modifiable, et la recopier dans l’objet puis le re-sauvegarder.
Mais le fait de ne pas appliquer une règle de l’objet ne pourra pas être considéré comme une anomalie, ce n’est pas son rôle.

Dernier point, tu peux écrire la callback directement avec l’action en paramètre, et accéder aux attributs sans langue :

public String customValidation(Action action) {
   String val = action.getConfirmField("myField").getValue();
   // ...
}

En effet, c’est un usage détourné de la pop-up de confirmation ^^, mais c’est une demande qui revient plusieurs fois.

J’ai essayé en v5.3 de mettre un champ virtuel dédié à la pop-up de confirmation et de récupérer la valeur côté back afin d’écrase la valeur dans le champ physique présent dans le formulaire. C’est ok en faisant comme ça, je vais partir sur cette solution.

Merci François :slight_smile:


Il me semble que c’était cette version de la 5.1 qui contenait l’évolution permettant d’envoyer au back la nouvelle valeur d’un champ du formulaire qui a été modifiée dans la pop-up de confirmation :

image

ok je vais regarder, les actions ont tellement évoluées qu’on a peut être fait régresser ce point qui n’est pas un cas de test bien identifié.

Je viens de refaire des tests, avec un champ virtuel dédié à l’action on est obligé d’ajouter du code JavaScript afin d’afficher dans la pop-up la valeur présente dans le champ physique du formulaire :confused:

J’ai essayé avec une contrainte, mais on doit mettre le champ virtuel dans le formulaire du coup on revient au problème initial où la valeur entrée par l’utilisateur dans la pop-up n’est pas transmise au back si le champ est présent dans le formulaire également.

Si on peut avoir le même comportement qu’en 5.1 et 5.2 pour la 5.3 ça serait top :sweat_smile:

pour valoriser un champ ajouté à l’action, il faut passer par le hook initAction(Action) qui prépare l’action avant affichage, les champs se présentant comme dans une création, il faut modifier la valeur par défaut du champ de l’action :

String value = getFieldValue("x1"); // from object
action.getConfirmField("x2").setDefaultValue(value); // to action field

Merci, ça fonctionne :slight_smile: