>Please open a ticket for improvement and list APIs you would want to have. I will probably add them.
I'll take a look at what posters have described so far and if I find that the functionality is still lacking, I'll add a ticket for it. >2) you can use auth.define_tables(username=True) so that email is not used for login. The problem is that you still need to communicate with users and this is what the email field is for. In principle you can hide the email field if you do not need to comunicate with users. Awesomeness. Perhaps document it in the book though in that section to clarify it for users: http://web2py.com/books/default/chapter/29/09#Customizing-Auth In particular, the "Field('email', length=128, default='', unique=True), # required" makes it seem like the email field is still necessary. >login_bare() is documented: http://web2py.com/books/default/chapter/29/09#Manual-Authentication That's great. However, it seems to me that most of the options in the user function of the default controller should have an equivalent programmatically callable function call that is documented in the book. > Maybe we could add an option to auth.define_tables() to automatically hide or exclude the email field. As long as the user can omit it in his customer auth_user db definition and everything that doesn't specifically require email functionality still works, I think most users will be happy. Thanks for all the feedback guys. It really helps. On Thursday, 29 November 2012 10:48:08 UTC-5, Anthony wrote: > > On Thursday, November 29, 2012 10:34:13 AM UTC-5, Massimo Di Pierro wrote: > >> 1) good point. We have the following functions but they are not >> documented: >> >> def get_or_create_user(self, keys, update_fields=['email']): >> def login_bare(self, username, password) >> > > login_bare() is documented: > http://web2py.com/books/default/chapter/29/09#Manual-Authentication > > Also, note that auth.logout() is not form-based and can be called > programmatically. > > >> >> 2) you can use auth.define_tables(username=True) so that email is not >> used for login. The problem is that you still need to communicate with >> users and this is what the email field is for. In principle you can hide >> the email field if you do not need to comunicate with users. >> > > In addition to hiding the email field, you can also define a custom > auth_user table that excludes the email field. In either case, everything > should work fine, except of course the Auth actions that require sending > emails to users (e.g., verify registration, retrieve password, etc.). Maybe > we could add an option to auth.define_tables() to automatically hide or > exclude the email field. > > Anthony > --
