On Jul 10, 2009, at 5:34 PM, mdipierro wrote: > I do not like the idea of a paremeter dependent on another parameter. > What do other people think? > I think people should propably override this variable anyway.
The problem is that there's no way to override the variable(s) to get the desired (by me, anyway, but I think it's logical) distinction between being logged in or not. That's crucial, isn't it? Either the user is logged in and ready to go, so we go to login_next (regardless of whether we got there via login or registration-and-auto-login), or the user is not logged in and we don't. The problem is that registration_next takes us to the same place regardless of whether the registration resulted in a login or not. Perhaps there should be three nexts: login, registration+login, registration+pending. > > Massimo > > On Jul 10, 7:10 pm, Jonathan Lundell <[email protected]> wrote: >> On Jul 9, 2009, at 3:05 PM, mdipierro wrote: >> >> >> >>> You are right. Uploading your fix to trunk. Thanks. >> >> There's a remaining problem, I think. >> >> The current behavior (after this patch) is to log in after >> registration and go to index. The problem is that (and I think that >> Fran brought this up), after registration you really want to go to >> login_next if you're logged in, but to registration_next if you're >> not >> (which would be the case if you're using email verification). >> >> Making them both index fixes simple apps like welcome, because its >> login_next (index) doesn't really care if you're logged in. But if >> you've got (as I do) login_next that uses (say) auth.user.id, you'll >> get a ticket if you go there after a registration that doesn't do a >> login. >> >> I think the behavior should be: go to login_next after a successful >> login *or* after a registration that performs a successful login. Go >> to registration_next if the registration process went OK but for some >> reason (like email verification) the user isn't logged in. >> >> On a somewhat related matter: there ought to be a way to request the >> sending of another email verification. If the message gets lost for >> some reason, there's no way for the user to deal with it, excepting >> maybe trying to get some administrator's attention to manually edit >> the user table. >> >> >> >>> Massimo >> >>> On Jul 9, 4:09 pm, Jonathan Lundell <[email protected]> wrote: >>>> On Jul 9, 2009, at 1:48 PM, mdipierro wrote: >> >>>>> You should not ne already logged in after registration. That is >>>>> not >>>>> default behaviour >> >>>> That's how welcome is working. This is immediately after >>>> registering: >> >>>> pastedGraphic.tiff >>>> 57KViewDownload >> >>>>> On Jul 9, 3:11 pm, Jonathan Lundell <[email protected]> wrote: >>>>>> From the pov of a novice... >> >>>>>> The default auth.settings.register_next (user/login) is confusing >>>>>> in >>>>>> that after registration you're already logged in, but user/ >>>>>> login is >>>>>> asking for a login again. f=index might be a better choice. >> >>>>>> Yes, I know it's easy to override, but the confusion starts >>>>>> with a >>>>>> new >>>>>> user playing with the welcome application. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
