Champs qui n'est pas sauvegardé. (attribut modifiable avec contrainte)

4.0
Champs qui n'est pas sauvegardé. (attribut modifiable avec contrainte)
0
Tags: #<Tag:0x00007fcf175a9f90>

(Gilles SADELER) #1

Bonjour à tous,
Je rencontre un bug… peut être est il déjà connu : Lors de la création d’un impact de contrainte sur l’attribut modifiable d’un champs. Celui ci n’est pas sauvegardé à l’enregistrement. Il faut absolument re-sauvegarder pour que ça fonctionne. Plus de détail dans la vidéo suivante :

Le bug a été constaté sur une version 4.0 patch level P21 (database patch level P21)
La vidéo a été réalisée sr une version : 4.0 patch level P22b (database patch level P21)


(David AZOULAY) #2

Je ne vois pas de “defect” ici, en attendant d’en savoir plus je requalifie en “support”…

En effet un champ non modifiable n’est effectivement pas pris en compte à la sauvegarde c’est normal

Je ne peut pas deviner votre use case mais pour avoir un champ rendu non modifiable par contrainte que vous voudriez voir enregistré quand même il faut une autre approche


(Gilles SADELER) #3

Je me suis peut être mal exprimé. Par défaut le champs est non modifiable, mais en passant par une contrainte, il devient modifiable grâce à la valeur d’un autre champs (voir la vidéo). Mais lors dans le cas ou le champs devient modifiable (la première fois) la valeur renseignée n’est pas sauvegardée.


(David AZOULAY) #4

Comment votre contrainte est elle paramétrée ?


(Gilles SADELER) #5

La contrainte est paramétrée par une égalité de le champ expression


(David AZOULAY) #6

J’ai besoin de la contrainte et de ses impacts pour pouvoir investiguer, pas juste d’un impact


(Gilles SADELER) #7

C’est une contrainte qui est appliquée tout le temps (expression true).
Préférez vous l’export xml ?


(François Genestin) #8

Effectivement je reproduis ce cas, la contrainte s’applique (champ non modifiable) car l’objet n’a pas encore chargé la nouvelle valeur du champ qui permet de rendre son champ “voisin” modifiable.

On va devoir faire une évolution pour permettre une double lecture des données en entrée du service de mise à jour :

  • une première pour charger les données reçues sans contrôler le caractère modifiable des champs
  • appliquer les contraintes de champs pour mettre les champs modifiables en fonction des données reçues
  • remettre les valeurs initiales de l’objet (de la base de données)
  • une seconde passe, pour ne charger que les données finalement modifiables