what about this? auth.settings.registration_onaccept=lambda form: auth.is_logged_in() or redirect(URL(r=request,f='login'))
On Jul 10, 7:51 pm, Jonathan Lundell <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
