Django-guardian: ANONYMOUS_USER_NAME Aucune valeur

Oui, vous avez raison, cela semble douteux. Besoin d'un moyen de pouvoir définir par défaut «AnonymousUser» sans l'empêcher d'être explicitement défini sur Aucun.

Et si je modifiais le code comme suit? Rien de mieux? Cela devrait définir la valeur par défaut si rien n'est spécifié et permettre de la définir explicitement sur Aucun.

try:
    ANONYMOUS_USER_NAME = settings.ANONYMOUS_USER_NAME
except AttributeError:
    try:
        ANONYMOUS_USER_NAME = settings.ANONYMOUS_DEFAULT_USERNAME_VALUE
        warnings.warn("The ANONYMOUS_DEFAULT_USERNAME_VALUE setting has been renamed to ANONYMOUS_USER_NAME.", DeprecationWarning)
    except AttributeError:
        ANONYMOUS_USER_NAME = "AnonymousUser"

Je dirais simplement de supprimer les deux lignes que j'ai commentées.

Puisque ANONYMOUS_USER_NAME est en fait la valeur de USERNAME_FIELD , ANONYMOUS_USER_NAME pourrait être un e-mail ou quoi que ce soit d'autre. La valeur par défaut de "AnonymousUser" est donc trompeuse. De plus, ANONYMOUS_USER_ID déclenchait la fonctionnalité et ANONYMOUS_DEFAULT_USERNAME_VALUE servait de nom d'utilisateur. Mais maintenant, ils ont été fusionnés en un seul paramètre, qui sert de déclencheur et de valeur. Il est donc inutile de fournir une valeur par défaut.

Je m'en tiendrai donc à:

ANONYMOUS_USER_NAME = getattr(settings, 'ANONYMOUS_USER_NAME', None)

if ANONYMOUS_USER_NAME is None:
    ANONYMOUS_USER_NAME = getattr(settings, 'ANONYMOUS_DEFAULT_USERNAME_VALUE', None)
    if ANONYMOUS_USER_NAME is not None:
        warnings.warn("[...]", DeprecationWarning)

et supprimez les deux lignes susmentionnées.

J'ai des sentiments mitigés sur la syntaxe try...except car, même si la vérité n'est pas une question de nombre, je ne l'ai jamais vue utilisée pour les paramètres. Le classique <SETTING_NAME> = getattr(settings, "<SETTING_NAME>", <default_value>) fonctionne généralement plutôt bien.

Si nous ne fournissons pas de valeur par défaut pour ANONYMOUS_USER_NAME, cela va casser les applications existantes qui supposent qu'une valeur par défaut va être fournie. c'est-à-dire que nous avons changé le comportement lorsque le paramètre ANONYMOUS_USER_NAME n'est pas donné.

Alors pourquoi ne pas passer à 1.5.0, supprimer ANONYMOUS_DEFAULT_USERNAME_VALUE et la valeur par défaut, et avertir de la rupture des changements?

Je pense que l'intention était d'autoriser l'exécution de Django Guardian sans que cela crée automatiquement un utilisateur anonyme. Avez-vous un cas d'utilisation pour cela? Pourquoi ne pas simplement ignorer l'utilisateur anonyme si vous ne le souhaitez pas?

Je pense que créer un utilisateur anonyme par défaut est une bonne chose, je ne vois aucune raison pour laquelle nous devrions changer cela. Cependant, nous avons besoin d'une valeur par défaut de ANONYMOUS_USER_NAME pour que cela fonctionne. Si la valeur par défaut n'est pas adaptée à votre application, vous pouvez toujours la modifier.

La syntaxe try ... except est bonne car elle permet de distinguer les cas de "Ce paramètre n'a-t-il pas été donné?" et "Ce paramètre a-t-il reçu une valeur nulle?" - Vous pourrez peut-être utiliser getattr pour cela, mais j'ai trouvé que cela peut se compliquer assez rapidement, en particulier si vous souhaitez conserver le DeprecationWarning. Je ne suis pas sûr de ce que vous entendez par "même si la vérité n'est pas une question de nombre".

Ce que je voulais dire, c'est que ce n'est pas parce que tout le monde fait une chose que c'est la bonne / meilleure façon.

Forcer la création d'un utilisateur anonyme pourrait être une solution, mais la documentation devrait alors être mise à jour.

Concernant ma situation, j'utilise un champ email comme USERNAME_FIELD par défaut, d'où ma réticence initiale à créer l'instance utilisateur anonyme. Mais je peux gérer.

Acclamations. Et merci de m'avoir laissé éclater vos salopes.

Les gars, je ne pense pas vraiment qu'exiger la création d'un utilisateur anonyme soit une bonne idée. J'utilise django-guardian depuis longtemps et avoir un utilisateur anonyme n'a jamais été nécessaire, alors pourquoi changer cela maintenant?

Donc, ma solution impliquant try ... except a reçu 2 pouces vers le haut, mais lorsque je justifie cette solution, j'ai reçu 2 pouces vers le bas. Déroutant. Comme je ne vois vraiment aucun inconvénient et que je pense que c'est le moyen le plus simple de résoudre la régression sans ajouter de nouvelles régressions, je vais appliquer cette solution.

@brianmay Désolé pour la confusion. : +1: pour le correctif, cependant!