I would extend auth_group with the additional fields you require. You can extend any table without modifiying web2py source in the same way you can extend auth_user. Just define the table before calling auth.define_tables() and make sure the current fields and validators are in there. If you define auth_group manually, you also have to define auth_user the same way.
On Mar 17, 11:33 pm, weheh <[email protected]> wrote: > Sorry, hamdy, but I don't think you answered the question. I have read > the doc many times and understand how to operate groups, memberships, > and permissions. The question is about structure. > > Consider the following situation. Users can register with the site. > Users can create common interest groups CIGs and invite other users to > join. Users can also search CIGs and request to join those in which > they have an interest. > > The question is how to structure this within web2py. Should CIG be an > extension of auth_group? Or should CIG be a separate table > db.define_table('CIG',Field('auth_group',db.auth_group),Field('name'),...)? > > One way to do this is with a CIG table, as just described, and then > use permissions to let people access or modify the CIG, and access or > modify the list of users who belong to the CIG. So auth_group would > not be extended, as I originally thought. auth_group roles would be > something like 'CIG Admin' or 'CIG Member', and then depending on your > group membership, you would get permission to 'read' 'update' 'delete' > members or content from the CIG. > > Is this the right way to be approaching this? -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
