Bonjour,
Nous essayons de rendre obligatoire un champ de type multidoc lors d’une transition d’état
Steps to reproduce
Nous avons testé deux solutions :
A. Par le code
En utilisant le hook pre-update, et en vérifiant la condition suivante :
if ((getOldStatus().equals("INIT") && getStatus().equals("COMPLETED")) ||(getOldStatus().equals("LACK_INFOS") && getStatus().equals("COMPLETED")) ){
//si au moins un doc n'est pas chargé, alerte
//vérification de ce que ressort la méthode "getDocuments"
AppLog.info("===================doc="+ getField("evlValReporting").getDocuments(this, getRowId()), Grant.getSystemAdmin());
if(getField("evlValReporting").getDocuments(this, getRowId())==null ) {
return Message.formatError("EVL_ERROR_COMPLETION", "Merci de compléter le Compte de résultat.", "evlValReporting");
La partie AppLog.info ressort ceci, bien qu’un doc a été chargé. La contrainte par le “if” n’est donc pas appliquée
On perd la fonctionnalité qui nous indique quel champ nécessite d’être renseigné + son emplacement.
Nous avons fait le test pour un doc simple, cela fonctionne parfaitement.
On détecte donc deux problématiques sur l’utilisation des multidoc :
La méthode getDocuments ne retournent rien, même si au moins un document est renseigné. Elle n’est donc pas exploitable. D’ailleurs cette méthode n’est pas dans la javadoc, bien qu’elle apparaisse ici : Doc simplicité
L’utilisation des contraintes sur des champs multidoc ne reproduit pas le même comportement que pour des champ “simple” document.
Voici la correction, il y a une erreur dans votre approche, mais c’est compréhensible, l’API n’étant pas très sympathique dans ce contexte.
@Override
public String preUpdate() {
if (!getOldStatus().equals(getStatus())){
// la bonne façon de compter le nombre de docs
int countDocs = getField("demoOrdMultiDoc").getDocuments(this, getRowId()).getDocuments().size();
// quelques explications sur votre ligne de log plus bas (*)
AppLog.info("===================docs="+ getField("demoOrdMultiDoc").getDocuments(this, getRowId()), getGrant());
if(countDocs==0) {
return Message.formatError("ERROR_MULTIDOC", "Merci de compléter le multi-doc.", "demoOrdMultiDoc");
}
}
return null;
}
Concernant votre ligne de log:
getDocuments renvoie un type com.simplicite.util.DocumentDB
ici, ça revient à appeler DocumentDB.toString() qui renvoie {size:0,contenttype:} où size est la taille du document et contentype son type. Pour un multiDoc, la réponse devrait plut être un array du genre [{size:32546,contenttype:image/jpeg}]|
je conviens qu’il est confusant que ObjectField.getDocuments ne renvoie pas directement une liste de DocumentDB et que DocumentDB fasse double-emploi pour du single et du multi-doc, l’API laisse un peu à désirer sur ce point. A minima elle devrait remonter des exceptions si on utilise des méthode single-doc sur un DocumentDB multiDoc… (cc @Francois )
field.getDocuments n’est pas un accesseur à une liste de documents mais au document chapeau qui les regroupe tous. Il aurait fallu l’appeler loadDocuments car ça charge la définition des documents et retourne le document chapeau.
oui field.toString() n’est pas très malin, et devrait retourner une liste
Pour rendre obligatoire un document, il suffit juste de mettre une cardinalité dans le Document/Bookshelf associé au champ, tout comme les mime-types autorisés :
Non car elles retournent déjà null si c’est pas le bon type. Le code peut déjà tester si c’est non null, pas un try/catch…
On peut cependant ajouter un warning explicite dans les logs. Ce n’a pas à être une exception au sens java (trop d’impact / breaking change peu utile = il faut refactorer tous les appels, non compatibilité ascendante du code spécifique… à éviter).
Ca oui, on va améliorer la java doc et le toString qui est confusant dans ce cas.
Jamais implémenté, on va l’ajouter ça doit pas être méchant à faire en front et back.
Ok j’avais pas cette info, dans ce cas petite une question fonctionnelle : si 1 des documents est obligatoire à une certaine étape, pourquoi ne pas modéliser :
un champ Document unique “principal”, comme un contrat (forcement PDF et qui devient obligatoire à un certain moment)
et les autres dans un champ documents multiples et optionnels : les documents annexes ou PJ sans controle
Là si on insère 10 documents, je vois pas très bien lequel était obligatoire parmi les 10, si ça se trouve l’utilisateur n’a pas renseigné le contrat, juste des annexes. Le test > 0 n’est pas vraiment métier. Généralement on met les champs obligatoires/engageants à part pour ne pas les mélanger avec des données optionnelles.
