Projet

Général

Profil

Development #6705

Possibilité de redirection initiale vers une page de bienvenue

Ajouté par Frédéric Péters il y a environ 9 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
11 mars 2015
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Lors d'une première connexion sur la page d'accueil (i.e. pas en cas d'arrivée sur une autre page), possibilité de rediriger vers une page particulière.


Fichiers

Révisions associées

Révision ea08a764 (diff)
Ajouté par Frédéric Péters il y a presque 7 ans

general: add possibility to redirect to an "initial login" page (#6705)

Historique

#1

Mis à jour par Frédéric Péters il y a plus de 8 ans

  • Assigné à mis à Serghei Mihai
#2

Mis à jour par Serghei Mihai il y a plus de 8 ans

Proposition de patch à discuter.
Je me base sur la comparaison des champs utilisateur last_login et date_joined afin de detecter si c'est une première connexion.

#3

Mis à jour par Frédéric Péters il y a plus de 8 ans

  • Patch proposed changé de Oui à Non

Ça ne m'a pas l'air comme ça qu'il faut faire, c'est plutôt lors du login, et non pas lors de la consultation d'une page, qu'une évaluation doit être faite. (et astuce, une comparaison sur le delta de deux secondes saute aux yeux comme un hack qu'on voudrait éviter). Et aussi, on veut envoyer l'utilisateur vers la page, et non se substituer à la page qui devrait être affichée.

#4

Mis à jour par Thomas Noël il y a plus de 8 ans

Frédéric Péters a écrit :

Ça ne m'a pas l'air comme ça qu'il faut faire, c'est plutôt lors du login, et non pas lors de la consultation d'une page, qu'une évaluation doit être faite. (et astuce, une comparaison sur le delta de deux secondes saute aux yeux comme un hack qu'on voudrait éviter).

Je plaide coupable, cette idée tordue de comparer les dates est de moi. Mais je n'ai pas d'autre idée pour savoir si un compte est nouveau, django ne propose vraiment rien pour cela, on a que deux dates :
  • date_joined : la date de création du compte (typiquement, pour un nouveau compte venant du SSO, c'est "maintenant" moins quelques centièmes de secondes)
  • last_login : la date du dernier login, dans notre cas l'utilisateur vient juste de se loguer, c'est donc "maintenant".

Le cas (last_login-date_joined) < 2 secondes est donc un cas "ce gars c'est surement la première fois qu'il arrive ici" (perso j'aurais mis 30 secondes, si le premier login foire, ça revient). Mais ça ne couvre pas tous plein d'autres cas...

Si on veut quelque chose sans astuce, je crois qu'il faut modifier le modèle User de combo, par exemple y ajouter un attribut genre "post_last_login". On peut, il faut le décider maintenant.

Ensuite, quand on aura trouvé comment repéré qu'un utilisateur est nouveau, pour faire en sorte que ça ne soit que lors du login, j'imagine ça : on aurait une url/vue "post_login" qui serait envoyée comme le "next" du login, le vrai next étant transformé en "next2", genre /login?next=/post_login&next2=celuidavant. Et c'est dans post_login qu'on chercherait à savoir si le compte est nouveau ou pas (aïe), si oui redirect vers la page de bienvenue (settings.WELCOME_PAGE_URL) sinon vers next2.

Et aussi, on veut envoyer l'utilisateur vers la page, et non se substituer à la page qui devrait être affichée.

Ok.

#5

Mis à jour par Thomas Noël il y a plus de 8 ans

Autre piste qui évite de jouer avec le modèle user : écouter le signal django.contrib.auth.signals.user_logged_in(user,request). Si user.last_login est None, alors ce cas ajouter un "user_is_new" dans la session. Mais il faudra encore regarder si user.last_login est "proche" de user.date_joined, toujours cette foutue astuce, parce que last_login est mis à jour par ce même signal... :/

Rappel (signalé à Serghei par ailleurs) : https://docs.djangoproject.com/en/1.8/releases/1.8/#abstractuser-last-login-allows-null-values (et c'est Django 1.8 notre cible, donc c'est bien).

#6

Mis à jour par Serghei Mihai il y a plus de 8 ans

Pour moi, la décision de redirection vers la page de bienvenue doit être faite immédiatement après l'authentification de l'utilisateur. Cette décision doit se faire au niveau de combo et non django-mellon(qui gère la création de l'utilisateur et l'authentification).

La comparaison des 2 champs date de l'utilisateur n'est pas une meilleure option, mais je suis de même avis que Thomas qu'on devrait se baser sur le champ last_login afin de detecter la première connexion. On pourrait débrancher le signal par défaut de Django et y brancher le notre qui vérifie si last_login est rempli. Un truc du style:

from django.contrib.auth.signals import user_logged_in
from django.contrib.auth import models

user_logged_in.disconnect(models.update_last_login)

def logged_in(sender, request, user, **kwargs):
    if not user.last_login:
        request.session['first_login'] = True
    models.update_last_login(sender, user)

user_logged_in.connect(logged_in)

Sinon, on peut partir sur un AUTH_USER_MODEL personnalisé dans lequel on rajouterait un flag spécial pour detecter la première connexion

#7

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

Le handler updata_last_login est connecté dans le fichier django/contrib/auth/models.py, si tu connectes ton signal dans le fichiers models.py d'une application lancé avant il devrait s'exécuter avant, les signaux étant exécuté dans l'ordre de leur enregistrement. Dans ce cas pas besoin de reproduire son comportement.

C'est casse gueule, mais pas plus que de déconnecter le handler d'origine, car dans ce cas il faudra être sûr de s'exécuter après.

#8

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

Serghei Mihai a écrit :

Pour moi, la décision de redirection vers la page de bienvenue doit être faite immédiatement après l'authentification de l'utilisateur. Cette décision doit se faire au niveau de combo et non django-mellon(qui gère la création de l'utilisateur et l'authentification).

La comparaison des 2 champs date de l'utilisateur n'est pas une meilleure option, mais je suis de même avis que Thomas qu'on devrait se baser sur le champ last_login afin de detecter la première connexion. On pourrait débrancher le signal par défaut de Django et y brancher le notre qui vérifie si last_login est rempli. Un truc du style:
[...]

Sinon, on peut partir sur un AUTH_USER_MODEL personnalisé dans lequel on rajouterait un flag spécial pour detecter la première connexion

last_login est None seulement en Django 1.8, en Django 1.7 il faut quand même comparer last_login à date_joined (je sais pas pour vous mais moi j'ai pas vu encore de paquet 1.8 dans nos dépôts).

#9

Mis à jour par Victor Claudet il y a plus de 8 ans

Juste pour apporter mon point de vue après discussion avec Sergheï (je suis peut être hors sujet)
J'avais réfléchis aux mockups pour la page de bienvenue ici : https://dev.entrouvert.org/projects/combo/wiki/Mockup_page_de_bienvenue

J'étais parti sur un div et pas une page indépendante parce que j'imaginais les choses comme ça :
L'usager se connecter pour la première fois, apparaît un message de bienvenue avec éventuellement plusieurs pages (quand on aura une procédure d'inscription). Tant que l'usager n'a pas cliqué sur "terminer" ou sur la croix de fermeture du div (en haut à droit du div), la page de bienvenue reste affichée.

Sous-entendu, si je perds la page, je ferme mon navigateur accidentellement... quand je reviens sur le portail, le message est à nouveau affiché. Ce que je comprends avec la discussion actuelle, c'est que le message de bienvenue n'est affiché qu'une seule fois quoi qu'il arrive. Je trouve ça boffe. Le fait que ce soit une page autonome aussi je trouve ça pas top, parce l'utilisateur n'arrive pas réellement sur son portail la première fois, mais sur une sous-page de combo.

#10

Mis à jour par Frédéric Péters il y a plus de 8 ans

Tu serais donc pour l'option "ajouter au profil de l'usager l'info comme quoi il a vu (et validé) la page de bienvenue" (aka "Sinon, on peut partir sur un AUTH_USER_MODEL personnalisé dans lequel on rajouterait un flag spécial pour detecter la première connexion").

Sur la présentation de la page, ce n'est pas encore, selon moi, le moment de s'en inquiéter. (i.e. gardons l'affichage d'une page dédiée pour le moment, il reste possible de lui donner un style différent, et plus tard d'agir différemment sur détection dans la session de l'info comme quoi c'est la première connexion / la page doit être affichée).

#11

Mis à jour par Victor Claudet il y a plus de 8 ans

Frédéric Péters a écrit :

Tu serais donc pour l'option "ajouter au profil de l'usager l'info comme quoi il a vu (et validé) la page de bienvenue" (aka "Sinon, on peut partir sur un AUTH_USER_MODEL personnalisé dans lequel on rajouterait un flag spécial pour detecter la première connexion").

oui

#12

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

Changer de modèle User en cours de route n'étant pas évident (je vous jure je l'ai fait 2 fois sur authentic déjà), un modèle Profile serait plus indiqué.

#13

Mis à jour par Frédéric Péters il y a plus de 8 ans

Oui oui, techniquement je favorise aussi le modèle extérieur.

#14

Mis à jour par Serghei Mihai il y a plus de 8 ans

  • Fichier 0001-local-user-profile-storing-welcome-message-view-stat.patch ajouté
  • Fichier 0002-redirect-user-to-welcome-page-6705.patch ajouté
  • Patch proposed changé de Non à Oui

Voilà, modèle pour le profil utilisateur séparé.
La page de redirection peut être spécifiée dans les settings.

Je n'ai pas d'idée pour l'instant de ou et comment on sauvegarde le fait que l'utilisateur ait fermé le pop-up, probablement dans une cellule particulière.

#15

Mis à jour par Frédéric Péters il y a plus de 8 ans

Ça va planter sur tous les utilisateurs existants qui n'ont pas de profil, non ? Il faudrait une migration créant les profils pour tous les utilisateurs déjà existants, et mettant leur welcome_message_viewed à True.

return hasattr(settings, 'WELCOME_PAGE') and settings.WELCOME_PAGE

Plutôt poser un COMBO_WELCOME_PAGE = None dans le settings.py, et virer le hasattr().

#16

Mis à jour par Serghei Mihai il y a plus de 8 ans

  • Fichier 0001-local-user-profile-storing-welcome-message-view-stat.patch supprimé
#17

Mis à jour par Serghei Mihai il y a plus de 8 ans

  • Fichier 0002-redirect-user-to-welcome-page-6705.patch supprimé
#19

Mis à jour par Benjamin Dauvergne il y a plus de 8 ans

C'est pas pour faire mon chieur mais un profile, created = Profile.objects.get_or_create(user=request.user) dans display_welcome_message aurait suffit plutôt qu'une migration.

#20

Mis à jour par Frédéric Péters il y a presque 7 ans

  • Assigné à changé de Serghei Mihai à Frédéric Péters
  • Patch proposed changé de Oui à Non

Je reprends parce que ça va être nécessaire pour le guichet grand lyon.

#21

Mis à jour par Frédéric Péters il y a presque 7 ans

Et donc, sur base des discussions précédentes :

  • objet Profile (mis dans une nouvelle app combo.profile, plutôt vide pour le moment mais avec des questions de tableau de bord personnalisable, de préférences, etc. ça pourrait évoluer)
  • utilisation de .get_or_create pour ne pas avoir de migration (cela veut cependant dire que si une page de bienvenue est ajoutée à un site existant tous les utilisateurs y seront basculés, ça peut avoir du sens, l'inverse aussi)
  • utilisation d'un timestamp comme attribut, dans l'idée d'à l'occasion permettre de réenvoyer vers une page de bienvenue les anciens utilisateurs. (pas sûr que ça serve mais ça ne coûte rien de stocker ça plutôt qu'un booléen)
  • redirection uniquement lors d'une visite sur la page d'accueil. (je me dis que ça aussi ça peut se discuter et pourrait faire l'objet d'un paramétrage)
  • nommage du paramètre COMBO_WELCOME_PAGE_PATH pour bien indiquer que ça doit être un chemin vers une page; l'idée derrière c'est qu'une évolution où on afficherait le contenu en popup plutôt qu'en faisant une redirection, ça marchera mieux en forçant dès maintenant le fait qu'on renseigne un chemin.
  • un test

Reste un manque par rapport au commentaire de Victor "si je perds la page, je ferme mon navigateur accidentellement..." mais ça obligerait à demander de quoi explicitement enregistrer le fait que c'est bon, l'usager a validé qu'il était passé par la page de bienvenue, qui n'est pas un truc souhaité partout. Et au-delà du temps de bienvenue, un site devrait permettre de jouer sur ce qui est présenté sur la page de bienvenue (par exemple le paramétrage des fédérations).

Bref, c'est minimaliste mais dans la lignée des discussions d'il y a deux ans, et j'en ai besoin :)

#22

Mis à jour par Frédéric Péters il y a presque 7 ans

Discussion hier suite à quoi plutôt que "page de bienvenue" on appellerait plutôt celle-ci "page de première connexion". Patch qui ne change rien à part ça.

#23

Mis à jour par Thomas Noël il y a presque 7 ans

s/welcome_message/initial_login_page/ ?

#25

Mis à jour par Thomas Noël il y a presque 7 ans

Ack

#26

Mis à jour par Frédéric Péters il y a presque 7 ans

(notéle ack mais le dernier patch zappait la migration, la revoici).

#27

Mis à jour par Frédéric Péters il y a presque 7 ans

  • Statut changé de En cours à Résolu (à déployer)
commit ea08a76477ea174456872a532c2e096996bfb5c1
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Apr 10 14:17:45 2017 +0200

    general: add possibility to redirect to an "initial login" page (#6705)
#28

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF