Bonjour,
J’ai une action avec option de confirmation et un message personnalisé dans “UI template”. Lorsque je clique sur l’action et ensuite sur le bouton “Confirmer”, j’ai toujours la pop-in qui est affichée avec les deux boutons “Confirmer”, “Annuler”.
la version/patchelevel/revision/build date :
[Platform]
Status=OK
Version=5.0.0-beta
BuiltOn=2020-10-07 19:44
TimeZone=UTC
SystemDate=2020-10-14 14:22:48
Je ne reproduit pas le problème que vous décrivez sur une 5.0.0-beta à jour
Vous devez donc être dans un cas particulier qu’il va falloir nous décrire plus précisément.
En attendant d’en savoir plus je requalifie votre post en “Support”.
A nouveau, nous dire “ceci ou cela ne marche pas” sans nous indiquer s’il y a des messages dans les logs et/ou dans la console du navigateur, sans fournir de copies d’écran, sans donner de détails sur votre paramétrage, etc. ne sert à rien. Nous ne pouvons pas investiguer des problèmes en aveugle !
Il n’y a pas des erreurs dans les logs. Je suppose que c’est une ressource qui a sauté car on n’a rien changer au niveau du code, mais je ne parviens pas à identifier la ressource qui a sauté.
Or depuis le passage de la version v4 de simplicité vers v5 le problème est apparue.
Quand vous dites “les logs” vous parlez des logs serveur ? de la console du navigateur ? des deux ?
De ce que je comprend de votre pb c’est un pb purement UI (donc JS) il y a donc forcément des erreurs dans la console du navigateur (y compris si une ressource à “disparue” vous verrez passer des 404, etc.)
Si vous avez écrit du code JS qui marchait peut être en 4.0, il n’est pas forcément garantit qu’il fonctionne encore en V5, ça depend comment il est écrit. Si vous avez ce genre de code copiez collez le ici. A nouveau aussi on ne peut pas investiguer un pb en aveugle. Il faut nous fournir tous les éléments de contexte qui nous permettent de reproduire les pbs que vous indiquez.
PS: Sinon, pour rappel, la 5.0.0 n’est encore en qu’en “béta”. Or nous mettons à dispo cette béta uniquement pour faire des tests préalable à la release. Pas pour basculer vos vraies instances de dev/test/prod car cette “beta” à forcément encore besoin d’être finalisée. Nous sommes bien dans ce contexte dans votre cas ?
Bonjour,
Je pense que le problème n’apparait pas dans les logs. Mais j’ai trouvé un warning tout de même :
Nous somme bien dans le contexte de la v5. Nous avons un peu anticipé la migration.
Cette feuille de style est, d’après son URL celle de la disposition responsive5, par défaut elle ne contient aucun styles:
C’est un héritage historique qui date de l’époque (en 3.x) où la notion de “thème” n’existait pas encore, cette ressource n’a plus vraiment de bonne raison d’être modifiée. Bref si elle n’est pas là ce n’est normalement pas grave.
Si vous y avez mis des styles particulier ce n’est clairement pas le bon endroit pour le faire => des styles custom sont plutôt à mettre au niveau de votre thème (s’ils sont globaux) ou dans une resource de vos objets métier/externes (s’ils sont spécifiques).
En tout état de cause un manque de styles CSS n’est normalement pas de nature à empêcher le fonctionnent d’une page…
Faites un F5 (reload de la page) en surveillant de près la console du navigateur (“console” et “réseau”), traquez y toute erreur (notamment des 404 sur chargement de JS/CSS), la UI Simplicité étant une “one page” une erreur UI peut très bien n’apparaitre qu’une fois.
Mais à nouveau s’il y a du code JS spécifique associé à votre objet/action copiez/collez le ici pour qu’on regarde. Le pb est peut être plutôt à ce niveau.
PS: avoir anticipé un upgrade V4 => V5 de “vraies” instances de dev/test/prod sur une “béta” (qui n’est pas encore une “release candidate”) n’est pas forcément une bonne idée, cela reste en effet une version instable qui contient encore potentiellement des bugs qui peuvent avoir des effets destructeurs, nous la mettons à disposition pour faire des tests d’upgrade, pas pour des upgrades réels. Mais si c’est fait c’est trop tard pour revenir en arrière, il n’existe en effet pas de procédure de downgrade V5 => V4.
Attention. STYLES sert toujours pour surcharger les css au niveau disposition donc pour tous les thèmes.
Si vous l’avez perdu ça peut signifier que la migration a perdu des ressources. Quand on upgrade, ou on développe, il faut toujours avoir les log sous yeux (navigateur et serveur).
Sur le problème d’action je ne vois ce qui bloque.
Il faudrait voir au debugger chrome/network si l’action ajax est bien appelée et regarder la réponse http.
On verra si c’est votre action back qui répond mal ou si c’est la UI qui déclenche rien (pb de lecture d’un champ…).
J’ai fait une comparaison dans le cas où l’action avec l’option de confirmation fonctionne et dans le cas où elle ne fonctionne pas.
Version v4 “Fonctionne”:
Je sélectionne la ligne, puis je clique sur l’action, j’ai la trace dans le navigateur que l’action est appelée
Version v5 “Ne fonctionne pas”:
Je sélectionne la ligne, puis je clique sur l’action, je n’ai pas de trace dans le navigateur que l’action est appelée
L’action est nommée avec le préfixe du module en majuscule suivi d’un underscore et ensuite du nom de l’action en majuscule. L’action est de type Liste qui s’exécute en Back avec un message personnalisé au niveau de l’UI template (<p>Etes-vous sûr de vouloir passer toutes les candidatures sélectionnées à l’état Archivé ?</p>), et j’appelle une méthode en java qui est définie sur mon objet.
Voilà la méthode :
/** Action Archiver une candidature*/
//Archiver une candidature au statut actif
public String archiveCandidature(){
String msgs = null;
List<String> ids = getSelectedIds();
if (!Tool.isEmpty(ids)) {
//La requête qui retourne les candidatures qui sont INACTIF parmi les candidatures séléctionnées
String sQueryStatutInactif = "Select nam_statut_can from nam_candidature where row_id IN ("+String.join(",",ids)+") and nam_statut_can='"+CAND_STATUT_INACTIF+"'";
List<String[]> rsltsQueryStatutInactif = getGrant().query(sQueryStatutInactif);
//Si la requête remonte au moins une valeur "INACTIF", afficher un message ainsi que les valeurs ne changent pas, Sinon une mise à jour est lancée (changer l'état en "Archivé (exclu du vivier)" et le statut en "inactif").
if(!rsltsQueryStatutInactif.isEmpty()){
msgs = Message.formatSimpleWarning("Il n'est pas possible d'archiver les candidatures inactives");
} else {
for (String idSelect : ids){
if (select(idSelect)) {
getField(FIELD_NAM_ETAT_CAND).setValue(CAND_ETAT_ARCHIVCAN);
getField(FIELD_NAM_STATUT_CAN).setValue(CAND_STATUT_INACTIF);
update();
}
}
}
}
return msgs;
}
Peut on avoir la définition complète de votre action (export XML) ?
NB: Grace à ces explications et vos copies d’écran je cerne désormais mieux le contexte de votre cas (une action de liste) qui ne correspond pas au test que j’ai fait sur la base de votre description sommaire du début.
Je vous envoie les XML sur le privé
Je mets le XML ici car il ne contient rien de confidentiel:
<object>
<name>Action</name>
<action>upsert</action>
<data>
<act_name>NAM_ARCHIVER</act_name>
<act_type>L</act_type>
<act_async>0</act_async>
<act_job_depth/>
<act_method>archiveCandidature</act_method>
<act_script/>
<act_url/>
<act_image/>
<act_confirm>1</act_confirm>
<act_confirm_expr/>
<act_confirm_ui><![CDATA[<p>Etes-vous sûr de vouloir passer toutes les candidatures sélectionnées à l’état Archivé ?</p>]]></act_confirm_ui>
<act_plus>0</act_plus>
<act_comment><![CDATA[Bouton permettant d'archiver une ou plusieurs candidatures]]></act_comment>
<row_module_id.mdl_name>name</row_module_id.mdl_name>
<act_exec>BCK</act_exec>
<act_count>1</act_count>
<act_order>20</act_order>
</data>
</object>
Avec votre paramétrage je reproduis effectivement le comportement que vous décrivez.
@Francois est-ce qu’un template d’action qui ne contient qu’un simple message (sans aucun attribut d’action) est un cas géré ?
Je ne pense pas qu’on ait prévu ce cas. Car le champ UI sert à positionner les champs spécifiquement - par défaut les uns sous les autres. S’il n’y a rien, le message de confirmation par défaut s’affiche. On est dans un cas hybride qui doit planter sur la UI.
Ca devrait pas être difficile à priori de gérer ce cas de confirmation “sans champ mais avec un template UI non vide”. On va le faire rapidement.
OK je passe le post en “feature request” (j’imagine que le fait que ça ait marché en V4 relevait donc du miracle…)
En V4, ça fonctionnait car les champs étaient lus de façon synchrone avec l’appel de l’action.
En V5, on peut envoyer des documents et la lecture des champs de l’action est devenue asynchrone, et il manquait juste l’appel du callback dans le cas où il n’y avait pas de champ à lire.
Ce sera intégré au prochain build.
Merci pour votre analyse.
Ce besoin a été livré en 5.1