managing users with no email

[Vlad]

Trying to figure out how to manage the following: 

some users will manage themselves. this means that they have email and they log into the system and do whatever they want. 

other users don't use email (and generally aren't online altogether). so I want an admin to manage them, i.e. they would call in or walk in and the admin would do whatever needs to be done for them.

the challenge is the email field. I don't want an admin to create a unique email account for each user (simply because in real life they don't use email and have no email account - though those always have a phone number instead of email, if that helps), so an admin should be able to create a customer who would never login by himself, but the admin would manage what's going on in their account on their behalf. 

What's the best way to handle it? 

[Vlad]

seems to me that the ideal solution would be to allow an email field in auth_user to contain something other than email (for example, a phone number). but besides that I am not sure how to relax this requirement on the email field in auth_user, this solution seems to be politically incorrect, as this field is really expected to be an email (i.e. in a way how auth functions?) - 

so I am wondering what's the best way to make the thing to alternate between an email and a phone number for users as a unique account identifier...

greatly appreciate ideas... hope there is a simple and easy way to achieve this... 

[Val K]

As far as I remember, it is possible add extra fields to auth_user table 

+  you can make your own login form (phone/password)

+ you can retrieve record (and email that could be a fake) from  auth_user, using extra field (phone number) - db(auth_user.phone == form.vars.phone).select(auth_user.email)

+ and you can login user using auth.login_bare(email, password)    

[Vlad]

sounds like a perfect solution

thank you!

p.s. I've made one enhancement: instead of fake email I created a catch-all email for the domain, and will instruct the admin to specify a "real" email for a new customer (like "customer.first...@mydomain.com") - it will be a fake, of course, but for all practical purposes it will forward all the invoices and receipts and whatever to the default inbox), so this will create a useful illusion for the admin that he is creating a "real" email for the customer...