Anomalie #14100
ferméChangement de modèle : les données des formulaires privés ne sont pas renseignées (qualification)
Description
Etapes:
-
Faire parti d'un groupe avec ce paramétrage :
-
Importer un courrier par MaarchCapture
-
Ouvrir le courrier dans courrier à qualifier
-
Changer le modèle d’enregistrement pour un modèle privé préalablement crée
Constaté :
Le contenu des champs du formulaire d’enregistrement restent inchangés
Fichiers
Mis à jour par Robin SALDINGER il y a plus de 4 ans
Mis à jour par Support Maarch il y a plus de 4 ans
- Statut changé de A qualifier à A traiter
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de A traiter à Etude planifiée
- Priorité changé de 2-Sérieux à 1-Majeur
Changement par modèle privé OK en fiche de traitement)
Ne reprend pas les données du modèle privé (si donnée présente)
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Tracker changé de Anomalie à Ergonomie
- Sujet changé de Les modèles privés d’enregistrement ne sont pas fonctionnel lors de la qualification d’un courrier injecté par MaarchCapture à Changement de modèle : les données des modèles privé n'écrasent pas les données saisies
- Statut changé de Etude planifiée à 17
- Assigné à changé de EDI PO à Robin SALDINGER
- Priorité changé de 1-Majeur à 2-Sérieux
Comportement "normal" : si une donnée est présente (sur le formulaire donc en base de donnée), elle n'est pas écrasée par celle du modèle.
En indexation, la donnée est remplacée car elle n'est pas en base.
Si ce comportement ne convient pas à terme, il pourra être changé (attente de retours clients)
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Sujet changé de Changement de modèle : les données des modèles privé n'écrasent pas les données saisies à Changement de modèle : les données des formulaires privés ne sont pas renseignées (qualification)
A reproduire (non reproduit par PO)
Mis à jour par Henri QUENEAU il y a plus de 4 ans
- Statut changé de 17 à A traiter
- Assigné à changé de Robin SALDINGER à EDI PO
- Priorité changé de 2-Sérieux à 1-Majeur
Reproduit sur la démo.
Le client ne voit pas l'utilité des modèles d'enregistrement car lors de l'appel des modèles, les champs renseignés dans le modèles d'enregistrement ne sont pas utilisés et mis à jour sur le courrier
voir exemple ci-dessous
Mis à jour par Henri QUENEAU il y a plus de 4 ans
- Fichier Screenshot from 2020-07-17 14-44-49.png Screenshot from 2020-07-17 14-44-49.png ajouté
- Fichier Screenshot from 2020-07-17 14-49-18.png Screenshot from 2020-07-17 14-49-18.png ajouté
- Fichier Screenshot from 2020-07-17 14-50-09.png Screenshot from 2020-07-17 14-50-09.png ajouté
- Fichier Screenshot from 2020-07-17 14-50-18.png Screenshot from 2020-07-17 14-50-18.png ajouté
j'ai un courrier arrivé dans la bannette courrier à qualifier, avec différentes métadonnées déjà fournies par le maarch capture.
Lors de qualification de ce courrier, on constate que ce courrier est un courrier type que l'on rencontre quotidiennement (ex: facture, candidature). Donc le client souhaite utiliser le modèle d'enregistrement pour modifier rapidement les métadonnées en fonction de ce qui a été enregistré par défaut dans l'administration des modèles d'enregistrement.
Ci-dessous l'exemple du modèle d'enregistrement:
Lorsqu'on choisi le modèle d'enregistrement souhaité
Les champs renseignés par défaut dans le modèle d'enregistrement ne remplace pas les informations fournies par les données fournies du maarch capture.
Ceci est pénible car :
- aucun intérêt d'utiliser les modèles
- perte de temps car obligation de modifier les métadonnées
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de A traiter à Complément d'Informations
- Assigné à changé de EDI PO à Henri QUENEAU
Modèles d'enregistrement de données (privés tel qu'expliqué par RSA) ou modèles d'enregistrements génériques tel qu'expliqué maintenant.
Le comportement souhaité est-il le suivant :
*La donnée par défaut (modèle d'enregistrement) ou la donnée utilisateur (modèles d'enregistrement utilisateurs) remplace systématiquement la donnée présente dans le champ cible.
*
Mis à jour par Robin SALDINGER il y a plus de 4 ans
- Statut changé de Complément d'Informations à A traiter
- Assigné à changé de Henri QUENEAU à Emmanuel DILLARD
Explication suite à l'entretien téléphonique du 23/07 :
"Même si la donnée n'est pas renseignée par Maarch Capture et que le champ semble vide dans lors de la qualification, il n'est pas modifié par la donnée présente dans le modèle. Il semblerait d'ailleurs que ces champs ne soient pas "null" en base, comme si une chaîne de caractère vide était renseignée"
2 anomalies possible :
1.la donnée est nulle à la base (pas renseignée par Maarch Capture) et ne se remplace pas par celle contenue par défaut dans le modèle
2.les données sont bien sous la forme d'une chaîne de caractère vide, et c'est ce qui empêche le remplacement.
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Tracker changé de Ergonomie à Anomalie
- Statut changé de A traiter à Etude planifiée
- Assigné à changé de Emmanuel DILLARD à EDI PO
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Statut changé de Etude planifiée à 17
- Assigné à changé de EDI PO à Robin SALDINGER
- Priorité changé de 1-Majeur à 2-Sérieux
Préciser la donnée :
- exemple de colonne Maarch Capture (config WS client) - Fichier XML
- exemple de modèle affiché (donnée vide) - Capture écran
- exemple de modèle choisi (donnée toujours vide) - Capture écran
Mis à jour par Emmanuel DILLARD il y a plus de 4 ans
- Projet changé de 298 à 299
- Statut changé de A traiter à R&D - En cours
- Version cible changé de 20.03 (Fin de vie) à 20.10 Develop
Mis à jour par Florian AZIZIAN il y a plus de 4 ans
- Assigné à changé de EDI PO à Florian AZIZIAN
Mis à jour par Robin SALDINGER il y a plus de 4 ans
- Fichier
MaarchWSClient_standard_sample.xmlsupprimé
Mis à jour par Florian AZIZIAN il y a plus de 4 ans
- Statut changé de R&D - En cours à R&D - Terminé
Mis à jour par Emmanuel DILLARD il y a plus de 3 ans
- Projet changé de 298 à Backlog Courrier
- Version cible changé de 20.10 Develop à 20.10