Produits Entr'ouvert » Authentic 2

evaluate_condition a un paramètre on_raise pour déterminer une valeur par défaut si l'expression échoue, c'est ça qu'il faut utiliser.

• condition qui échoue -> caché
• condition qui échoue -> visible

À défaut d'en passer par là, une valeur par défaut à True me paraît plus sûre; lors du debug d'une condition avoir la mire de login qui disparaît par défaut c'est un poil embêtant.

Benjamin Dauvergne a écrit :

Je t'embête encore un poil, je me dis que puisque qu'on a un attribute self.enabled on pourrait s'en servir comme valeur par défaut, ça permet d'avoir les deux comportements :

• condition qui échoue -> caché
• condition qui échoue -> visible

Si self.enabled est faux on n'arrive même pas à l'execution de evaluate_condition: https://git.entrouvert.org/authentic.git/tree/src/authentic2/utils/__init__.py#n179

À défaut d'en passer par là, une valeur par défaut à True me paraît plus sûre; lors du debug d'une condition avoir la mire de login qui disparaît par défaut c'est un poil embêtant.

Je pense aussi que c'est mieux de ne pas perdre un bloc de connexion.

Au délà de la valeur de fallback en cas d'échec d'evaluation de la condition il faut quand même logguer quelque part le fait que les variables n'existent pas.

On peut logguer en warning au lieu de error dans:

        try:
            return evaluate_condition(show_condition, ctx)
        except Exception as e:
            logger.error(e)

pour éviter les mails.

pour éviter les mails.

S'il y a des erreurs il faut les voir (dans un mail ou dans sentry, comme aujourd'hui), personne ne va aller les chercher dans les logs.

Et si on considère que c'est le comportement correct d'afficher (ou cacher) le bloc en cas d'exception à l'évaluation, je trouve qu'il n'y a pas à encombrer les logs (de quelque chose qu'on considère correct).

Pour moi c'est une fonctionnalité à utiliser à la marge, en gros c'est bien sympa de cacher/afficher un truc au bon public, mais dans le cas où ça ne marche le mieux c'est de laisser les gens pouvoir agir, donc comme je le disais à minima la valeur devrait être True.

C'est moins grave d'afficher un bouton en trop que de bloquer tout le monde (je trouve); déplacer le fonctionnement du flag enabled c'était la cerise sur le gâteau (une fois que l'expression de condition d'un bouton agent fonctionne on le désactive).

Nicolas Roche a écrit :

Et du coup je réalise que je ne comprend pas la dernière remarque de Benjamin :

déplacer le fonctionnement du flag enabled c'était la cerise sur le gâteau (une fois que l'expression de condition d'un bouton agent fonctionne on le désactive).

"déplacer" ça voulais dire qu'il fallait modifier le comportement de ' utils.get_backends() ' ?

Oui.