Come to think Anthony, the best way to do it will be similar to this. Having hidden field and tables and once selected the user_type, all the other fields or tables shows up.
https://stackoverflow.com/questions/17380476/web2py-authenticating-two-types-of-profile But the implementation is wrong. hidden_fields = (user_extra_fields if request.args(1) == 'tutor') request.args(1) will never get satisfied like that. Need to process the table and then set the argument. I am thinking...but I could be wrong. On Monday, February 1, 2016 at 4:27:46 PM UTC-5, Ron Chatterjee wrote: > > Yes Anthony. Thank you again! It works just like you explained. > > On Monday, February 1, 2016 at 3:53:30 PM UTC-5, Anthony wrote: >> >> Calling .process will already do an insert into the db.Education table -- >> your code is inserting an additional record. Instead, *before* calling >> .process, set db.Education.education_of.default = auth.user_id. Also, the >> education_of field should not be readable or writable. >> >> Anthony >> >> On Monday, February 1, 2016 at 3:47:54 PM UTC-5, Ron Chatterjee wrote: >>> >>> Thanks for the help Anthony. I appreciate that. >>> >>> For some reason this below don't work: >>> >>> form = auth(); >>> form2 = SQLFORM(db.Education).process() >>> if form2.accepted: >>> db.Education.insert(education_of = auth.user.id) >>> return dict(form=form, form2 = form2) >>> >>> >>> Or even if I do this: >>> db.Education.update_or_insert(education_of = auth.user.id) #basically >>> updating the education with the auth.user.id (it shows up as None) >>> >>> But strange enough, if I insert the Education.education_of from the >>> table itself (from the admin), it works just fine. >>> >>> >>> >>> >>> >>> On Monday, February 1, 2016 at 1:58:41 PM UTC-5, Anthony wrote: >>>> >>>> I just meant you won't be able to use the built-in auth.profile() >>>> functionality -- your example is custom code. >>>> >>>> Anthony >>>> >>>> On Monday, February 1, 2016 at 1:33:54 PM UTC-5, Ron Chatterjee wrote: >>>>> >>>>> Thank you Anthony, >>>>> >>>>> Very good discussion. Just one question regarding when you say we >>>>> "have to create own register/profile"... >>>>> >>>>> Let's say my model is: >>>>> >>>>> >>>>> #---------------------------------------------------------------------------------------------- >>>>> db.define_table("Education", >>>>> Field("education_of", 'reference auth_user', >>>>> widget=SQLFORM.widgets.options.widget, requires= IS_EMPTY_OR(IS_IN_DB(db, >>>>> db.auth_user.id))), >>>>> Field("Title", "string", label='Education Title', >>>>> requires=IS_NOT_EMPTY(),default=None)) >>>>> >>>>> #---------------------------------------------------------------------------------------------- >>>>> controller: >>>>> >>>>> form = auth(); >>>>> form2 = SQLFORM(db.Education).process() >>>>> if form2.accepted: >>>>> db.Education.education_of.default = db.auth_user.id >>>>> return dict(form=form, form2 = form2) >>>>> >>>>> >>>>> #------------------------------------------------------------------------------------------------------------------------- >>>>> >>>>> And in view we add the education as a folding or something: >>>>> >>>>> <div class="container"> >>>>> <button type="button" class="btn btn-info" data-toggle="collapse" >>>>> data-target="#demo">Add Education</button> >>>>> <div id="demo" class="collapse">{{=form2}}</div> >>>>> </div> >>>>> >>>>> >>>>> We can make the education_of as readable = False. So, it gets >>>>> updated/inserted as auth_user.id >>>>> >>>>> Do I still need to code up profile separately? We can add other >>>>> tables the same way. No? >>>>> >>>>> >>>>> On Monday, February 1, 2016 at 12:25:43 PM UTC-5, Anthony wrote: >>>>>> >>>>>> If there aren't too many fields, it might just be easiest to put them >>>>>> all in auth_user and just make some conditionally readable/writable >>>>>> depending on the type of user. Otherwise, you could create separate >>>>>> profile >>>>>> tables and have them reference auth_user. In that case, you would have >>>>>> to >>>>>> create your own register/profile actions, as web2py Auth won't handle >>>>>> the >>>>>> separate tables for you. >>>>>> >>>>>> Finally, it might be possible for you to conditionally change the >>>>>> names of the Auth tables based on user type: >>>>>> http://web2py.com/books/default/chapter/29/09/access-control#Renaming-Auth-tables. >>>>>> >>>>>> However, you would have to be able to identify the user type *prior* >>>>>> to registration/login (e.g., based on some identifier in the URL), as >>>>>> the >>>>>> Auth table names must be determined in order to process any Auth actions. >>>>>> >>>>>> Anthony >>>>>> >>>>>> On Monday, February 1, 2016 at 12:30:04 AM UTC-5, [email protected] >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hello web2py community. I am a new user and I have to say, web2py >>>>>>> saves the day by saving so much time over a full stack framework which >>>>>>> requires so much work. Anyway, going to ask a question tothe community. >>>>>>> How >>>>>>> to custom create auth_user so instead of adding extra fields to the >>>>>>> auth_user we can have multiple tables for the profile with various >>>>>>> attributes. I am creating an application for gym membership and I need >>>>>>> to >>>>>>> have the user register based on their job, current address, prior >>>>>>> fitness >>>>>>> routines, current fitness routine, activities they are >>>>>>> interested...etc. >>>>>>> Put all in one tables with various fields seems make a table >>>>>>> disproportionately long. Would be nice to split them to different >>>>>>> tables >>>>>>> and user can pick and choose which tables they like to fill up or they >>>>>>> don't. >>>>>>> >>>>>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
