Modification d'un champ enumération par code Java

Bonjour,

Dans mon projet, j’ai un champ “Status” qui contient une ENUM
Selon certaines actions de l’utilisateur, je souhaiterai que ce champ enum soit automatique modifié
Voici mon code en partie:

AppLog.info(getClass(), "azeaze", "1", getGrant());
					pwoPurchPerimeterAssignment.setFieldValue("pwoGenStatus", "VALIDATED");
					AppLog.info(getClass(), "azeaze", "2", getGrant());
					pwoPurchPerimeterAssignmentTool.validateAndSave();
					AppLog.info(getClass(), "azeaze", "3", getGrant());
					pwoPurchPerimeterAssignment.setFieldValue("pwoGenStatus", "DRAFT");
					AppLog.info(getClass(), "azeaze", "4", getGrant());
					pwoPurchPerimeterAssignmentTool.validateAndSave();
					AppLog.info(getClass(), "azeaze", "5", getGrant());

(J’ai mis deux setFieldValue du meme champ seulement pour le test)

Voila mon résultat:

Le passage au statut “VALIDATED” ne provoque aucune erreur alors que passer au statut “DRAFT” m’indique ERR_ENUM: status

Pourtant ces deux valeurs existent dans la list of value du champ

La seule différence notable entre ces deux statuts est que DRAFT est le statut par défault du champ mais je ne pense pas que cela soit impactant

Auriez-vous une idée de ce qui ne va pas dans mon code, ou bien une solution alternative

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-07-21 16:40 (revision 28d01f4adf37b49491b6e7991d397e64a1965f86)
DBPatchLevel=P24;394e13c6adf5ffaffdf62cb93ac6ce12

Cordialement,
KWu

Un attribut enumeré ne peut pas prendre n’importe quelle valeur => il ne peut prendre qu’un des code de la liste de valeur, sinon vous aurez un message d’erreur.

Si la liste de valeur en question porte ne plus un state model vous ne pourrez faire que les transitions explicitement autorisées au user qui fait la manip (i.e. le user qui a instancié l’objet sur lequel vous faites la transition)

Justement les deux valeurs testé (“DRAFT” et “VALIDATED”) sont des valeurs présentes dans l’enum d’où mon interrogation sur le message d’erreur

Pour les transitions explicitement autorisées, si cela se configure via l’onglet “State transition permission” cela à déjà été fait


Et je possède la responsabilité “MSD_UPDATE_MOA”
Existe-t-il une autre fenetre pour la configuration des transitions autorisées ?

Cordialement,
KWu

Non si les valeurs existent, si la transition existe et si le user qui instancie l’objet est habilité à cette transition, automatiser la transition par du code marchera forcément.

Par contre je pense qu’il faut être dans un contexte où la old value est correctement positionnée. Si vous ne savez pas si c’est le cas dans votre contexte particulier faites le explicitement :

ObjectField s = getField("myStatusField");
s.setOldValue("MYOLDSTATUS");
s.setValue("MYNEWSTATUS");
(...)

Pour recharger la liste des statuts éligibles après un “save”, il faut refaire un “select(row_id)” de l’objet.

Les trois existent, les valeurs dans l’enum, la transition et le user qui a les droits, cependant ca marche pour “Validated” mais pas pour “Draft” alors qu’ils ont exactement les mêmes formats

A savoir que pour mon code, il n’y aura pas les deux changement de statut à la suite, pour mon post, j’ai mis les deux statuts seulement à titre d’exemple, mais dans mon cas concret, il n’y aura que un seul changement de statut, soit l’objet est au statut draft et passe à validated, soit l’inverse et c’est là où le probleme arrive, c’est que ca marche de draft à validated mais quand j’essaye de faire de validated à draft, a chaque fois j’ai le message d’erreur ERR_ENUM: status
Du coup, je suppose qu’il ne devrait pas y avoir de probleme de oldValue vue même si je fais qu’un seul changement de statut (validated vers draft) je reçois quand meme une erreur

Il faut que la old et new value soient cohérentes vis à vis du state-model chargé en mémoire.
Donc comme pour toute mise à jour le pattern est le suivant :

  • synchronized(obj)
    • obj.select(id) : si on n’est pas déjà sur l’enregistrement
    • obj.setStatus(“B”) : le select a permis de valoriser oldvalue=“A” et de charger les bons états
    • validateAndSave() : ok si A=>B habilité

Si on fait N mises à jour, il faut faire N fois ce traitement.
Le synchronize est obligatoire pour éviter les concurrences d’accès sur l’instance. (sinon entre le select et le save, le statut peut être écrasé par un autre thread dans la même session)