Projet

Général

Profil

Actions

Bug #9268

fermé

Formulaire - Saisie contenu dans un champ "Riche Texte" qui n'apparaît pas toujours

Ajouté par Marc Avenel il y a environ 7 ans. Mis à jour il y a plus de 6 ans.

Statut:
Closed
Priorité:
Immediate
Assigné à:
Début:
14/11/2017
Echéance:
% réalisé:

100%

Temps estimé:
Navigateur:
Firefox
Votre version de Silverpeas:
5.15.6
Système d'exploitation:
Votre base de données:
Toutes
Livraison en TEST:
Livraison en PROD:

Description

Nous avons une GED "Ressources Humaines" déployée sur les 45 sites
  • Dans cette GED chaque dossier est associé à un formulaire
  • Des item de type Riche Text sont utilisés
  • La publication est soumis à un workflow de validation
  • Si un utilisateur renseigne ces items "Riche Texte" certains utilisateur ne voient pas le contenu en mode lecture
  • Et si ces mêmes utilisateurs sont en édition du formulaire ils ont dans le champs la valeur 'nul'
    Voir copie écran
    C'est vraiment bloquant.
    45 GEDS

Fichiers

RicheTexte-Pbl.PNG (23,6 ko) RicheTexte-Pbl.PNG Marc Avenel, 14/11/2017 16:43
RicheTexte-Mise à jour Content.PNG (26,4 ko) RicheTexte-Mise à jour Content.PNG Marc Avenel, 14/11/2017 16:45
RicheTexte-Vue.PNG (18,9 ko) RicheTexte-Vue.PNG Marc Avenel, 14/11/2017 16:45
lib-core-5.15.7-SNAPSHOT.jar (2,42 Mo) lib-core-5.15.7-SNAPSHOT.jar David Lesimple, 16/11/2017 10:24

Demandes liées 1 (0 ouverte1 fermée)

Dupliqué par GED - Bug #8676: Champs WYSIWYG d'un formulaire associé à un publication i18n non persistéClosedNicolas Eysseric27/03/2017

Actions

Mis à jour par Sebastien Vuillet il y a environ 7 ans

  • Statut changé de New à Feedback

Quel est le workflow de validation associé à la publication ?
Pouvez-vous nous donner accès à une GED exemple ?

Mis à jour par Marc Avenel il y a environ 7 ans

C'est une GED avec des droits spécifiques
  • Un rédacteur saisit
  • Des valideurs acceptent ou refusent la publication

Je vous donnes les droits avec quel compte ?
C'est cette GED :
EUROPE - MEA > SIE - SIEGE > HUMAN RESOURCES > DEPARTMENT > Recruitment & Notification of Action > Manufacturing Performance Department > 2.Notification of Action > Change situation

Ca devient URGENT.
Merci

Mis à jour par Marc Avenel il y a environ 7 ans

C'est cette publication:
EUROPE - MEA > SIE - SIEGE > HUMAN RESOURCES > DEPARTMENT > Recruitment & Notification of Action > Manufacturing Performance Department > 2.Notification of Action > Change situation > NOA_2017_11_Serge Traclet
J'ai David Lesimple commme Manager.

Mis à jour par Marc Avenel il y a environ 7 ans

  • Priorité changé de Urgent à Immediate

Cette demande est vraiment Urgente
Elle bloque tous les sites sur la gestion RH.
Merci à vous

Mis à jour par David Lesimple il y a environ 7 ans

  • Assigné à mis à David Lesimple

Mis à jour par David Lesimple il y a environ 7 ans

  • Statut changé de Feedback à In progress...

Mis à jour par David Lesimple il y a environ 7 ans

Est-il normal que cette GED soit paramétrée invisible ?

Mis à jour par David Lesimple il y a environ 7 ans

La publication en question est en français.
Il s'avère que seuls les utilisateurs dans cette langue (langue par défaut) voient le contenu du champ remarks.
En copiant sur le serveur une version en du contenu du champ, ça fonctionne.

A confirmer si c'est un bug produit et dans quel contexte on le reproduit.

Mis à jour par Marc Avenel il y a environ 7 ans

Cette GED a des droits par dossiers
Ma question:
  • Pourquoi le champs "Remark" ne fonctionne pas comme les autre champs avec n'importe quel langue
je ne comprends celle-ci:
  • En copiant sur le serveur une version en du contenu du champ, ça fonctionne

Mis à jour par David Lesimple il y a environ 7 ans

Marc Avenel a écrit :

Ma question:
  • Pourquoi le champs "Remark" ne fonctionne pas comme les autre champs avec n'importe quel langue

Son contenu n'est pas stocké en base de données mais sur le serveur.

je ne comprends celle-ci:
  • En copiant sur le serveur une version en du contenu du champ, ça fonctionne

C'est sans importance, c'est ce qui m'a permis d'identifier le problème.

Mis à jour par Marc Avenel il y a environ 7 ans

J'ai fait le test.
  • Comme de fait si dans mon profil je change de langue
  • Je vois le commentaire

Mais il faut que ce commentaire soit visible dans les deux langues
Ce n'est pas possible autrement...
Comment faisons nous ?
Merci à vous

Mis à jour par David Lesimple il y a environ 7 ans

C'est bien un bug produit.

Le contexte :

- Multilangue activé
- formulaire xml avec surcouche HTML (pas de problème si pas de surcouche)
- champ de type wysiwyg

Si l'utilisateur n'est pas dans la même langue que la publication, le contenu du champ wysiwyg n'est pas affiché.

Si vous n'utilisez la surcouche HTML, tout fonctionne bien.

Mis à jour par David Lesimple il y a environ 7 ans

  • Statut changé de In progress... à Qualified

Mis à jour par Marc Avenel il y a environ 7 ans

Vous me dites

Si vous n'utilisez la surcouche HTML, tout fonctionne bien.

Je ne comprends votre remarque.
Merci à vous?

Mis à jour par Marc Avenel il y a environ 7 ans

En fait je viens de comprendre
  • Si je n'utilise pas le HTML mai je laisse les champs telque;
  • Ceci fonctionne bien.
  • Mais justement la présentation est trop importante pour éviter le HTML.

Avez vous vu la présentation?

Mis à jour par Marc Avenel il y a environ 7 ans

Vous travaillez dessus ?
Merci à vous..

Mis à jour par Nicolas Eysseric il y a environ 7 ans

  • Statut changé de Qualified à Resolved

Bonsoir,

J'ai reproduit le problème également en v6...
David, tu trouveras la correction sur le commit https://github.com/NicolasEYSSERIC/Silverpeas-Core/commit/afa441113122fd734544f6abb0da5d915d8d4d7e (sur mon repo v6).
Je pense qu'elle est facilement "reportable" en v5.
Désolé mais je ne peux pas faire plus pour l'instant (et en déplacement demain).

Mis à jour par David Lesimple il y a environ 7 ans

correctif manuel en préparation.

Mis à jour par Marc Avenel il y a environ 7 ans

Super.
Vous me prévenez dès que je peux récupérer le correctif.
Merci à vous. Bien cordialement

Mis à jour par David Lesimple il y a environ 7 ans

voici le patch manuel adapté à votre contexte (lib-core repris de votre installation contenant les optimisations de la 5.15.7).
A valider en test avant.

Mis à jour par David Lesimple il y a environ 7 ans

  • % réalisé changé de 0 à 50

Mis à jour par Marc Avenel il y a environ 7 ans

Pouvez nous livrer la version définitive?
Nous mettons à jour le portail ce soir.
merci à vous.

Mis à jour par David Lesimple il y a environ 7 ans

Marc Avenel a écrit :

Pouvez nous livrer la version définitive?
Nous mettons à jour le portail ce soir.
merci à vous.

Le correctif n'a encore pas été intégré à la 5.15.7, celle-ci n'est donc pas encore sortie.

Mis à jour par Marc Avenel il y a environ 7 ans

Donc j’intègre ce fichier " lib-core-5.15.7-SNAPSHOT.jar" tel que sur la Production?
Merci

Mis à jour par David Lesimple il y a environ 7 ans

Marc Avenel a écrit :

Donc j’intègre ce fichier " lib-core-5.15.7-SNAPSHOT.jar" tel que sur la Production?
Merci

oui.

Mis à jour par Marc Avenel il y a environ 7 ans

Ok. c'est ce qui est prévu ce soir en Production.
Merci à vous

Mis à jour par Marc Avenel il y a environ 7 ans

  • Statut changé de Resolved à Closed

Mis en production avec succès le 20/11/2017 au soir
Merci à vous.

Mis à jour par David Lesimple il y a environ 7 ans

  • Statut changé de Closed à Re-opened
  • Version cible mis à Version 5.15.7
  • % réalisé changé de 50 à 90

Je réouvre le ticket car l'intégration de la correction reste à faire en 5.15.7

Mis à jour par Marc Avenel il y a environ 7 ans

vous nous tenez au courant dès que l'intégration est faite en 5.15.7
  • Que l'on mette à jour "lib-core-5.15.7-SNAPSHOT.jar" sur notre serveur de Production
    Merci à vous

Mis à jour par David Lesimple il y a presque 7 ans

  • Dupliqué par Bug #9403: GED-Item "Wysiwyg"-valeur par défaut "NULL" ajouté

Mis à jour par David Lesimple il y a presque 7 ans

  • Dupliqué par Bug #9403: GED-Item "Wysiwyg"-valeur par défaut "NULL" supprimé

Mis à jour par Marc Avenel il y a presque 7 ans

Le problème sur les deux champs de type RichText avec NULL dans le contenu en valeur par défaut est revenu.
Merci à vous.

Mis à jour par Nicolas Eysseric il y a plus de 6 ans

  • Statut changé de Re-opened à In progress...
  • Assigné à changé de David Lesimple à Nicolas Eysseric

Mis à jour par Nicolas Eysseric il y a plus de 6 ans

Marc Avenel a écrit :

Le problème sur les deux champs de type RichText avec NULL dans le contenu en valeur par défaut est revenu.
Merci à vous.

Bonjour,

Pouvez-vous m'indiquez où cela se reproduit exactement ?

Merci

Mis à jour par Marc Avenel il y a plus de 6 ans

Oui la dernière mise à jour a été sur cette publication:

CORPORATE > BD - BUSINESS DEVELOPMENT > MWS-MECHANISMS AND WASHING SYSTEMS > PRODUCT LINES > Project Workspace > O : Mechanisms (SYF COI-COE) > PSA > K9 > COI > F13015A > Accueil > METHODES INDUSTRIALISATION > 50 - Analyse systèmes de mesure

Mis à jour par Marc Avenel il y a plus de 6 ans

Toutes mes excuses je me suis trompé de ticket

Mis à jour par Marc Avenel il y a plus de 6 ans

Pour le RichText à null c'est toutes les GEDS RH
Vous pouvez regarder sur : EUROPE - MEA > CHA - CHAMPFROMIER > HUMAN RESOURCES > DEPARTMENT > Recruitment and Notification of Action

Mis à jour par Nicolas Eysseric il y a plus de 6 ans

  • Dupliqué par Bug #8676: Champs WYSIWYG d'un formulaire associé à un publication i18n non persisté ajouté

Mis à jour par Nicolas Eysseric il y a plus de 6 ans

  • Statut changé de In progress... à Resolved
  • % réalisé changé de 90 à 100

Intégré à la 5.15.7

Mis à jour par Yohann Chastagnier il y a plus de 6 ans

  • Statut changé de Resolved à Integration in progress...

Mis à jour par Yohann Chastagnier il y a plus de 6 ans

  • Statut changé de Integration in progress... à V6 pending

Intégré en 6.0.x

Mis à jour par Yohann Chastagnier il y a plus de 6 ans

  • Statut changé de V6 pending à Closed

Intégré en 6.x

Actions

Formats disponibles : Atom PDF