From: alex b. <en...@tu...> - 2001-05-21 15:22:07
|
> > Don't agree. I think user groups are essential. Imagine a module called > "forum". It's a generalized module implementing the forum functionality. You > have db tabels for lets's say "forum_posts", "forum_categories", > "forum_logs", "forum_topics" and "forums". So having usergroups (that > holding the permission pattern) you can use them for assigning some forums > to the group "developer" other to "user" some to "anonymous" so that they > can't be accessed by the other group. We don't need _midguard's_ user groups, as bc r1 already has that, and r2 will have an expanded/groovier version of it. So I'm not saying "user groups are dumb" which would be, well, dumb. I'm saying that we already have this and don't need to go looking elsewhere for it. > If you need more, take Workspaces. Workspaces can combine usergroups or > users. So a workspace called "Customers" contains the usergroups "ad > clients", "normal clients", "web clients" or whatever, another "intranet" > contains your intranet users. So forums belonging to the workspace > "Customers" are available for all users beloning to "Customers". This > applies also for documens etc. The functional elements in r2 auth/perm are users/roles. We could easily add a faux hierarchy to that, i.e. be able to classify users in groups simply to make them easy to deal with. I like that idea, it will probably be added as part of the entityEditor. > Groups may also be interesting in mapping unix groups to the database. Don't > especially know a application for that, but I think sourceforge does this > way. At an even lower level, there are pam modules for doing db auth in unix machines, SF uses ldap because of the number of users - which is nice. I think it's called pam_ldap > Maybe this is all a bit complicated and narrow-minded. But I think there is > a real usage for usergroups. Workspaces maybe interesting for the CMS > module. User groups are absolutely necessary. But we don't need midguard's :) _a |