Bonjour,
certains objets ont un titre redéfini (via obo_title / Titre complémentaire) dont les valeurs des champs constituant l’expression peuvent contenir les caractères ‘[’ et ‘]’.
Dans ce cas, une erreur système est générée dans les logs lors de l’évaluation de l’expression et tout ce qui se trouve entre crochets n’est pas intégré dans le titre.
ERROR|system|com.simplicite.util.ScriptedObjectDB|getTitle||Event: Unknown field P&C in title of object BCSISpecBusnDomain: [VALUE:BusnSpecDomainName]
Comment pouvons-nous formuler l’expression pour résoudre ce problème?
NB: les indexes fulltext contiennent bien ce qui est entre crochets…
Historiquement (en 2.x) les blocs [xxx] étaient preprocessés en valeur de l’attribut xxx à de nombreux endroits. Cela a été maintenu pour compatibilité (en fallback) car la syntaxe recommandée depuis au moins la 3.0 est [VALUE:xxx]
Je propose d’abandonner définitivement cette compatibilté pour éviter des effets de bord comme celui là. @Francois tu es d’accord ?
merci beaucoup pour ta réponse rapide.
J’ai finalement pu contourner en implémentant le hook getUserKeyLabel (mais ça ajoute du code spécifique alors que la fonction standard devrait suffire)…
OK mais ca ne remet pas en cause le fait qu’on doit se poser la question d’abandonner la compatibilité sur les syntaxes [xxx] car plus personne n’est sensé s’en servir depuis la 3.0 et ça pose régulièrement des pbs. Ici je ne sais pas si c’est bien de ça qu’on parle…
A la base c’est quoi l’expression de ton titre complémentaire ?
Il s’agit d’un cas particulier d’objet dont la clé fonctionnelle est composée de deux champs et le métier ne veut voir dans le titre que la première partie… du coup l’expression contient uniquement “[VALUE:clé1]”.
Le contenu du champ BCSISpecBusnDomain qui provoque l’erreur est dans le cas présent “[P&C] Metrics & Indicators” (utilisateur métier cruel, fourbe et qui me veut de mal)…
Dans ce cas c’est bien un bug de parsing en double, normalement le “replace” ne doit se faire qu’une fois par block [VALUE] et pas être récursif… je vais corriger
@david oui on peut aussi retirer la vieille compatibilité [xxx] en V5, en V4 ce serait méchant de le faire à ce stade de release stable. donc s’il y a bien un gros warning “deprecated” dans les logs de la V4 lors du processing de cette vieille syntaxe.
C’est corrigé, ça ne devrait plus remplacer un texte déjà remplacé.
Ce sera poussé dans le build journalier.
J’ai laissé la compatibilité ascendante de syntaxe car cette partie de code est confinée au seul traitement du Titre, et ne semble pas poser de pb depuis la V2. En fait le titre n’est pas processé comme les autres expressions car on ne peut y substituer que des valeurs de champ.
Ok mais la syntaxe [xxx] a toujours posé des pbs (surtout depuis l’arrivée de Rhino en 3.0). Je pense qu’il est temps avec la v5 de s’en débarrasser définitivement avec le § qui va bien dans les “compatibility breaking changes”.
En v4 il faudra mettre un warning de deprecation si ce n’est pas déjà le cas.