Setting a field's "writable" attribute to False prevents users from
inputting values in forms, and setting the "readable" attribute to False
prevents the field from appearing at all. Note, you can set these
attributes dynamically, so they can default to False, but you can
selectively set them to True in particular contexts.
Anthony
On Monday, May 20, 2013 12:13:48 PM UTC-4, Chris Teodorski wrote:
>
> Sorry - it is a one to one relationship. So if I include it as part of
> the auth_user table -- I will need to prevent users form directly editing
> the challenge fields (and not expose them on registration) -- so I guess I
> now need to figure out how to do that.
>
> Thanks again for the help.
>
>
> On Monday, 20 May 2013 11:43:13 UTC-4, Anthony wrote:
>>
>> I assumed this was a one-to-many relationship, but given that it is
>> actually one-to-one, you certainly could just put the t_teams fields
>> directly in the auth_user table.
>>
>> Anthony
>>
>> On Monday, May 20, 2013 10:02:11 AM UTC-4, Chris Teodorski wrote:
>>>
>>> Let me try again to explain what I'm striving for and see if that helps
>>> you guys help me. I'm really trying to explain as concisely as possible,
>>> without explaining the nitty gritty of what I'm trying to do.
>>>
>>> In my ideal situation, when a user registers, they create a team name as
>>> part of the registration process. When registration occurs a row is added
>>> to the the t_teams table which contains a field for their team name and
>>> their status on all of the challenges.
>>>
>>> Now that I'm explaining it -- perhaps the 'right' solution is to just
>>> add the extra fields to the auth_user table and not bother with having a
>>> secondary table.
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>> On Monday, 20 May 2013 09:47:14 UTC-4, Chris Teodorski wrote:
>>>>
>>>> I'm going to give this a try -- but I'm honestly not sure exactly what
>>>> this field definition does. I'm going to play with it a bit and RTFM to
>>>> see if I can figure it out.
>>>>
>>>>
>>>>
>>>> On Monday, 20 May 2013 09:26:23 UTC-4, Anthony wrote:
>>>>>
>>>>> Would it work for you to just have a foreign key reference to the
>>>>> auth_user primary key, which is the id field? You could set the
>>>>> "represent"
>>>>> attribute of the "name" field to display the "team_name" value from the
>>>>> referenced auth_user record.
>>>>>
>>>>> db.define_table('t_teams',
>>>>> Field('name', db.auth_user,
>>>>> requires=IS_IN_DB(db, 'auth_user.id', '%s(team_name)s'),
>>>>> represent=lambda id, r: db.auth_user(id).team_name))
>>>>>
>>>>> Anthony
>>>>>
>>>>> On Monday, May 20, 2013 7:49:49 AM UTC-4, Chris Teodorski wrote:
>>>>>>
>>>>>> What I'm trying to do -- and obviously not explaining well is to have
>>>>>> t_teams.name to be a foreign key for the field custom field in
>>>>>> auth_users.
>>>>>>
>>>>>> Does that explain it any better?
>>>>>>
>>>>>> On Monday, 20 May 2013 02:59:00 UTC-4, Niphlod wrote:
>>>>>>>
>>>>>>> uhm.
>>>>>>> what do you want (as examples) in auth_user.team_name and what on
>>>>>>> t_teams.name ?
>>>>>>> if you want e.g. "a-team" in auth_user.team_name and "a-team" in
>>>>>>> t_teams.name, and a record in t_teams must exist only with a "name"
>>>>>>> that is one of the team_name values of the auth_user table (i.e. you
>>>>>>> have
>>>>>>> to create the user BEFORE the t_teams), then you can't create that
>>>>>>> reference.
>>>>>>>
>>>>>>> You should use a Field('name', requires=IS_IN_DB(db,
>>>>>>> 'auth_user.team_name'))
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
--
---
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/groups/opt_out.
