Bonjour,
Je reviens sur ce ticket car le paramétrage ne répond pas complètement à mon besoin.
Je cherche, pour un profil donné, à n’autoriser que les transitions d’état sur un objet.
Un valideur peut valider l’objet mais ne doit pas pouvoir le modifier.
J’ai tenté getStatusField().getList().getItem(getStatus(),false).setReadOnlyFields(true); dans le initUpdate mais ça ne met pas les champs en lecture seule … est-ce que j’ai raté quelque chose ?
Problème subsidiaire ( ) :
il me semble que les attributs d’action sont aussi en lecture seule quand j’utilise une transition à partir d’un état en Read Only Fields
C’est impossible, une transition d’état sous forme de “bouton” est une mise à jour du champ statut = un call ajax “save” avec mise à jour du statut.
Il faut donc nécessairement avoir le droit de mise à jour sur l’objet et que le champ statut soit modifiable en back. Je ne vois pas d’autre solution que d’interdire tous les champs sauf le statut pour ce profil, par contrainte ou par code.
Autre option :
Créer une action qui restera accessible même si le record est en read-only. Et le code back devra faire la mise à jour du statut en changeant les droits temporairement.
Un besoin similaire et qui revient souvent est de pouvoir surcharger les propriétés :
de visibilité des attributs, des zones d’attributs, des vues/links
ou de rendre un champ obligatoire/facultatif ou modifiable/en lecture seule
pour certains états ou transitions d’état, et pour des profils donnés
On peut le faire par code ou contrainte, sans que ce soit proprement modélisé, ce serait intéressant d’avoir au delà du “read-only fields” sur un état (pratique surtout sur un état terminal), une modélisation plus précise du qui/quoi/quand.
Le cas par exemple de rendre un champ 1) obligatoire uniquement en cas de transition vers un état donné, mais le laisser 2) facultatif si on reste sur l’état courant en mise à jour d’autres champs, reste compliquer à réaliser :
signaler en terme d’UX que le champ est “semi” obligatoire
et coder le validate pour traiter les 2 cas pour passer ou bloquer
Ces mécanismes pourraient être modélisés et gérés nativement.
Je passe ce besoin en feature request.
je pirate le thread …
J’ai rencontré des problématiques similaires et les éléments de solutions évoquées m’intéressent aussi.
Pour ce qui concerne la problématique d’information de l’utilisateur de ce qui doit / pourra se passer en fonction des ce qu’il fera (enregistrer, actionner une fonction/transition, etc…) est il envisageable que les mécanismes de liste de messages aujourd’hui gérées par exemple lors du preValidate soient transposés dans le contexte initUpdate ? Cela permettrait de passer des points de contrôles spécifiques avant que le user n’enregistre (dès l’ouverture du formulaire) et par la même occasion d’informer le user des possibilités (champ obligatoire pour autoriser une transition par exemple).
En effet de mon côté j’ai rendu dans le preValidate des champs obligatoires à partir d’un certain état.
Pour ma problématique :
j’ai un statut “A valider” pendant lequel il ne doit pas pouvoir y avoir de modifications. Pour ce cas j’ai utilisé le Read Only Fields mais cela verrouille aussi les attributs d’actions : quand le valideur choisir le statut “A revoir”, un champ apparaît lui permettant d’entrer les raisons de son rejet mais il est en lecture seule.
De façon générale, pour garantir le respect des process nous avons établi qu’un valideur ne peut pas modifier et qu’un modificateur ne peut pas valider (séparation des rôles). On a donc besoin que les champs soient ReadOnly pour certains statuts et certains rôles seulement.
Ca serait super que ça soit une feature, en attendant je vais verrouiller champ par champ
Un champ d’action de confirmation est modifiable si c’est un champ additionnel dédié à l’action, mais si le champ appartient à l’objet il est proposé en lecture seule = justement pour confirmer sa valeur saisie dans le formulaire.
Rien à voir aves le flag “read-only fields” du statut. Regarde si hook initAction peut modifier ce comportement par défaut pour un champ à valider de l’objet :
@Override
public void initAction(Action action) {
ObjectField f = action.getConfirmField("myFieldName");
f.setDefaultValue("aValue");
f.setUpdatable(true);
f.setRequired(true);
}
) :
…
