> Alternatively, you could create separate tables that are simply linked
to the auth_user table.
This is what I did, and so far it works out well. I followed the 'party'
pattern and added the
party.id to the auth_user table.
Kind regards,
Annet
--
---
You received this message because yo
Thank you very much for your response
On Monday, August 19, 2013 6:22:33 AM UTC-7, David Ripplinger wrote:
>
> In my situation, I'm offering two completely different services to my two
> types of users: one is getting budgeting software and the other is getting
> advertising options. So in my ca
In my situation, I'm offering two completely different services to my two
types of users: one is getting budgeting software and the other is getting
advertising options. So in my case, I have decided that it makes sense to
have two separate applications placed under two separate URLs. However, I
ha
I just bumped into the same situation, can you tell me which route you
took? did you decide to have two applications or the other way?
On Saturday, April 13, 2013 10:53:47 AM UTC-7, David Ripplinger wrote:
>
> Okay, that makes sense. It might not be worth modifying web2py for this
> behavior whe
I just bumped into this situation also, my case is students and employers,
when I register employers I want to have
"auth.settings.registration_requires_approval
= True" and a different profile, but students can just register without
requiring approval from admin
On Saturday, April 13, 2013 11
Interesting use case -- I think cases like that have come up before (i.e.,
where different roles need different types of profiles). May be worth
supporting somehow, but not sure about the best approach.
For now, you might consider putting all the profile fields in the auth_user
table, and just
Okay, that makes sense. It might not be worth modifying web2py for this
behavior when there may be a cleaner way of doing it. I had considered
using the inherent roles and permissions, but there are several reasons why
this would be awkward for my particular case. The main reason is that I
over
I think the problem is that Auth creates an object called "auth" in the
session, and the name of this session object is fixed. So, once someone
logs in with one of your Auth instances, the other instance will pull the
"auth" object from the session and think they are logged in with that
instanc
8 matches
Mail list logo
