Appel du isCreateEnable 4 fois et sur chaque row

Bonjour
nous avons constaté une régression sur le hook isCreateEnable.
Non seulement il ne s’exécute plus 2 fois (une fois pour les métadatas et 1 fois le ‘vrai’ appel) mais en plus il s’exécute sur chaque record.

/**
 * Business object TestInitCreate
 */
public class TestInitCreate extends ObjectDB {
	private static final long serialVersionUID = 1L;
	
	@Override
	public boolean isCreateEnable() {
		AppLog.info("isCreateEnable" + this.getRowId(), getGrant());
		return true;
	}
}
2020-12-10 20:45:51,852 INFO [com.simplicite.objects.Application.TestInitCreate] SIMPLICITE|http://38bf0484fe96:8080||INFO|p104635|com.simplicite.objects.Application.TestInitCreate|isCreateEnable||Evénement: isCreateEnable1
2020-12-10 20:45:51,852 INFO [com.simplicite.objects.Application.TestInitCreate] SIMPLICITE|http://38bf0484fe96:8080||INFO|p104635|com.simplicite.objects.Application.TestInitCreate|isCreateEnable||Evénement: isCreateEnable1
2020-12-10 20:45:51,852 INFO [com.simplicite.objects.Application.TestInitCreate] SIMPLICITE|http://38bf0484fe96:8080||INFO|p104635|com.simplicite.objects.Application.TestInitCreate|isCreateEnable||Evénement: isCreateEnable1
2020-12-10 20:45:51,852 INFO [com.simplicite.objects.Application.TestInitCreate] SIMPLICITE|http://38bf0484fe96:8080||INFO|p104635|com.simplicite.objects.Application.TestInitCreate|isCreateEnable||Evénement: isCreateEnable1
2020-12-10 20:45:51,846 INFO [com.simplicite.objects.Application.TestInitCreate] SIMPLICITE|http://38bf0484fe96:8080||INFO|p104635|com.simplicite.objects.Application.TestInitCreate|isCreateEnable||Evénement: isCreateEnable
2020-12-10 20:45:51,846 INFO [com.simplicite.objects.Application.TestInitCreate] SIMPLICITE|http://38bf0484fe96:8080||INFO|p104635|com.simplicite.objects.Application.TestInitCreate|isCreateEnable||Evénement: isCreateEnable
2020-12-10 20:45:51,783 INFO [com.simplicite.objects.Application.TestInitCreate] SIMPLICITE|http://38bf0484fe96:8080||INFO|p104635|com.simplicite.objects.Application.TestInitCreate|isCreateEnable||Evénement: isCreateEnable
2020-12-10 20:45:51,783 INFO [com.simplicite.objects.Application.TestInitCreate] SIMPLICITE|http://38bf0484fe96:8080||INFO|p104635|com.simplicite.objects.Application.TestInitCreate|isCreateEnable||Evénement: isCreateEnable

Cordialement
Amandine T.

[Platform]
Status=OK
Version=4.0.P25
BuiltOn=2020-12-08 20:07 (revision 5d1baca2181dc39c8201725ce0a9565a3c8f6e94)
Encoding=UTF-8
EndpointIP=172.17.0.10
TimeZone=Europe/Paris
SystemDate=2020-12-10 20:47:19

Bonjour,

Bizarre en effet, on va regarder.

Il y a eu une évolution sur le hooks isActionEnable (pour éviter de l’appeler depuis le template editor), mais rien de spécial sur le hook isCreateEnable.

Suite à analyse en V4, l’appel de ce hook n’a pas bougé, ça a toujours été fait comme ça.

Il est appelé le “double” de fois pour compatibilité ascendante avec la UI legacy qui a besoin d’un contexte web différent des metadata de UI responsive. Par contre pour les lignes, il ne devrait pas être appelé du tout puisqu’il ne sert pas, il faudra optimiser ça.

Bref on peut essayer de faire évoluer ce traitement avec un risque de régression sur la legacy, donc c’est plus quelque chose à faire évoluer en V5 qui n’a plus de legacy du tout (en plus ça doit se produire pour les autres hooks isCopy/Update/DeleteEnable).

En soit le isCreateEnable n’a pas à aller lire le rowId courant comme vous semblez le faire, en tout ca il n’est pas significatif dans ce hook qui doit être “simple” pour interdire la création en fonction des droits ou de l’objet parent si on est dans une liste fille.

Quel est votre besoin ?

Bonjour

Par contre pour les lignes, il ne devrait pas être appelé du tout puisqu’il ne sert pas, il faudra optimiser ça.

Ce n’était pas déjà le cas ? Il me semble que c’était le cas auparavant. De plus, c’est ce qui est écrit dans votre documentation, c’est pourquoi j’ai cru que c’était une régression.

Dans notre hook, on récupère le parent et s’il s’agit d’un type particulier, on regarde s’il fait partie d’une certaine catégorie.
Nous n’utilisons pas le rowId. Je ne l’ai mis dans notre exemple pour comprendre le contexte d’appel.

Cordialement

Merci pour votre retour,

La V4 fait cohabiter 2 moteurs front (UI legacy fabriquée en back, et UI responsive en front avec des méta-data), car certains composants ou implémentations clientes sont encore anciennes pour compatibilité ascendante.

  • On va pouvoir élaguer drastiquement ces appels en V5 puisque la legacy n’y ait plus du tout
  • mais on va faire ce qu’on peut en V4 pour éliminer ces doubles appels quand c’est possible afin de limiter ce nombre de requêtes dans votre cas

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.