Bug #13261
ferméLes valeurs par défaut ne sont pas appliquées
Ajouté par David Lesimple il y a environ 2 ans. Mis à jour il y a presque 2 ans.
100%
Description
Sur l'éditeur de formulaires, seul le champ radio permet d'indiquer une valeur par défaut :
C'est correct sur la prévisualisation dans l'éditeur:
mais pas dans la saisie coté application.
Pour les autres champs liste , heure , date et case à cocher, texte il manque l'ajout de la valeur par défaut.
Fichiers
radio2.png (4,54 ko) radio2.png | David Lesimple, 14/10/2022 12:29 | ||
radio1.png (9,34 ko) radio1.png | David Lesimple, 14/10/2022 12:29 | ||
radio3.png (4,63 ko) radio3.png | David Lesimple, 14/10/2022 12:31 |
Mis à jour par Nicolas Eysseric il y a environ 2 ans
- Version cible changé de Version 6.3 à Version 6.4
Mis à jour par David Lesimple il y a environ 2 ans
- Statut changé de New à In progress...
- % réalisé changé de 0 à 40
Mis à jour par David Lesimple il y a environ 2 ans
- La gestion du contexte (pageContext.creation) est mieux prise en compte dans les applications :
kmelia
kmax
classifieds
formsOnline
webPage
yellowPages
gallery
+ directory
- La valeur par défaut est gérée sur les champs :
Texte
Text multiligne
URL
E-mail
Bouton radio
Case à cocher
Liste déroulante
Date (+ mot clé now)
Heure
Adresse/Carte
Vers 6.3.x :
PR https://github.com/Silverpeas/Silverpeas-Core/pull/1243/files
PR https://github.com/Silverpeas/Silverpeas-Components/pull/796/files
Mis à jour par David Lesimple il y a environ 2 ans
- Statut changé de In progress... à Resolved
- % réalisé changé de 50 à 100
Mis à jour par Miguel Moquillon il y a presque 2 ans
- Statut changé de Resolved à Integration in progress...
Mis à jour par Miguel Moquillon il y a presque 2 ans
Pour information, je ne reproduis pas le problème de la valeur par défaut non appliquée pour un bouton radio dans une application. En l'occurrence, la valeur par défaut est bien mise avec le bouton radio d'un formulaire utilisé comme contenu d'une publication dans un Kmelia.
Mis à jour par Miguel Moquillon il y a presque 2 ans
J'ai observé dans Kmelia et dans Gallery que les valeurs par défaut des différents champs d'un formulaire ne sont pas pris en compte lorsqu'un formulaire a été choisi soit comme contenu (Kmelia), soit comme formulaire de métadonnées associées à un média (Gallery).
Pour Kmelia, après investigation, lorsque je sélectionne comme modèle de contenu d'une publication un formulaire, les champs qui comportent une valeur par défaut ne sont pas valorisés avec cette valeur par défaut parce que justement pageContext.isCreation()
retourne false
!
En fait dans kmelia, c'est xmlForm.jsp
qui est chargé d'afficher le contenu d'un formulaire comme contenu d'une publication. Or dans ce dernier, il n'y a pas de valorisation de l'attribut creation
de PagesContext
à true
lorsque l'on est en création du contenu.
Je suppose que le soucis doit être le même que pour Gallery : une JSP est sûrement chargée d'afficher le formulaire en édition mais celle-ci ne met pas à jour l'attribut creation
à true
de PagesContext
pour une première édition.
Je n'ai pas vérifié pour les autres composants. Je te laisse regarder ça.
Mis à jour par Miguel Moquillon il y a presque 2 ans
Après un passage sur l'ensemble des applications, les valeurs par défaut d'un formulaire ne fonctionnent pas lorsque celui-ci est utilisé a posteriori dans l'édition du profil d'un utilisateur existant (pour l'annuaire). Par contre, à la création d'un nouvel utilisateur, le mécanisme des valeurs par défaut fonctionne.
Mis à jour par Miguel Moquillon il y a presque 2 ans
Pour Gallery, lors de l'import d'une image par glisser-déposer dans un album, il est nécessaire d'éditer a posteriori le formulaire choisi pour des méta-données additionnelles. Et c'est lors de son édition a posteriori que les valeurs par défaut des champs du formulaire ne sont pas affichées.
Mis à jour par David Lesimple il y a presque 2 ans
Problème sur Galler, Kmelia et Directory corrigé.
(modification du formulaire après création de l'entête)
Mis à jour par Miguel Moquillon il y a presque 2 ans
- la page de modification d'un média existante plante : NullPointerException
- l'import d'un nouveau média via le bouton correspondant conduit aussi à faire planter la page d'import : NullPointerException
Exemple des traces générés par le dernier cas:
Stacktrace:: org.apache.jasper.JasperException: JBWEB004038: An exception occurred processing JSP page /gallery/jsp/mediaPhotoEdit.jsp at line 40
40
37:
38: <c:set var="isViewMetadata" value="${requestScope.IsViewMetadata}"/>
39:
40: <gallery:editMediaLayout mediaType="${mediaType}" supportedMediaMimeTypes="${supportedMediaMimeTypes}">
41: <jsp:attribute name="headerBloc">
42: <jsp:useBean id="media" scope="request" type="org.silverpeas.components.gallery.model.Photo"/>
43: <jsp:useBean id="isNewMediaCase" scope="request" type="java.lang.Boolean"/>
[...]
Caused by: java.lang.NullPointerException
at org.apache.jsp.tag.websilverpeas.gallery.editMediaLayout_tag.doTag(editMediaLayout_tag.java:356)
at org.apache.jsp.gallery.jsp.mediaPhotoEdit_jsp._jspx_meth_gallery_005feditMediaLayout_005f0(mediaPhotoEdit_jsp.java:284)
at org.apache.jsp.gallery.jsp.mediaPhotoEdit_jsp._jspService(mediaPhotoEdit_jsp.java:137)
... 114 more
Mis à jour par David Lesimple il y a presque 2 ans
Miguel Moquillon a écrit (#note-14):
Des nouvelles erreurs suites aux corrections dans Gallery, dans le cas où aucun formulaire n'y a été défini :
- la page de modification d'un média existante plante : NullPointerException
- l'import d'un nouveau média via le bouton correspondant conduit aussi à faire planter la page d'import : NullPointerException
Exemple des traces générés par le dernier cas:
[...]
C'est corrigé, testé, commité et poussé.
Mis à jour par Miguel Moquillon il y a presque 2 ans
J'ai découvert un autre soucis mais celui-ci est déjà présent en 6.3.x :
dans Gallery, si le formulaire défini comporte un champs texte avec pour identifiant title et que ce dernier est obligatoire, qu'il y ait ou non une valeur par défaut, que ce champs soit ou non valorisé, à chaque fois que le bouton "Valider" est cliqué, une popin apparaît informant l'utilisateur que ce champs est obligatoire et qu'il doit être valorisé.
Est ce que tu veux David en profiter pour corriger ce point ou j'intègre ?
Mis à jour par David Lesimple il y a presque 2 ans
Miguel Moquillon a écrit (#note-16):
J'ai découvert un autre soucis mais celui-ci est déjà présent en 6.3.x :
dans Gallery, si le formulaire défini comporte un champs texte avec pour identifiant title et que ce dernier est obligatoire, qu'il y ait ou non une valeur par défaut, que ce champs soit ou non valorisé, à chaque fois que le bouton "Valider" est cliqué, une popin apparaît informant l'utilisateur que ce champs est obligatoire et qu'il doit être valorisé.Est ce que tu veux David en profiter pour corriger ce point ou j'intègre ?
Je vais regarder si je peux le corriger.
Mis à jour par David Lesimple il y a presque 2 ans
Il est maintenant possible d'utiliser l'identifiant "title" comme champ de formulaire, le champ title de l'entête ayant été nommé différemment.
Mis à jour par Miguel Moquillon il y a presque 2 ans
Les PR ont été intégrés dans leur branche respective : 6.3.x et master.
Mis à jour par Miguel Moquillon il y a presque 2 ans
- Statut changé de Integration in progress... à Closed