For the record I am providing the transcript of emails between Don and myself
***********
Hazi wrote:
Do you have any ideas how we want to approach this. I don't really understand how roles are defined (side one/side two!!!)
My approach is to take a simple scenario and try to build any easy way to implement it. Please let me know if this is acceptable, and if you have a different scenario, let me know.
In an organization all staff are members of registered users.
Registered users are then divided up in departments
Departments have a variety of groups (managers, staff, admin, etc.)
There should also be groups that go across departments (All managers, all admins)
Roles are defined and each group are is assigned a role. (Don's help)
If you have time can you give me an outline the most efficient way of creating the above scenario. Have I missed on something important?
*************
Don Responded
<blockquote> Do you have any ideas how we want to approach this. I don't
really understand how roles are defined (side one/side two!!!)
</blockquote>
Roles should be defined using relational segments. My notion was that for
each subsite, we'd create an "admin" relseg along with the "member" relseg we
now create in the post-instantiation proc called by the APM.
If you've not explored relational segments, you should start reading dotLRN
and feel free to ask me questions as you do. It helps if you realize that
"relational segments" are, in effect, "subgroups".
dotLRN's approach to this isn't bad, i.e. add someone to the subsite as a
member, an admin, etc. In dotLRN you can only have one role in a community,
is this what we want in general ? I'm not sure. We may want to provide
for some flexibility.
<blockquote> In an organization all staff are members of registered users.
</blockquote>
As of 4.6, for the main subsite the membership group *is* registered users.
To be a member of a sub-subsite you must be a member of the parent subsite.
Every subsite has a membership group defined (other than the main subsite
which, again, just uses registered users.) Every subsite also has a member
relational segment.
This is where things get a bit confusing:
To check if someone belongs to the subsite, you need to check to see if they
belong to the subsite group. If you want to see if they belong but in a
particular role (only a member but not an admin, for instance) you need to
check the relevant relational segment.
It's less confusing in dotLRN as there is no relsegment (roll) called
"member", the least privileged community member in a class is called
"student". Maybe our member relseg should be called something like "ordinary
member" or the like to reduce confusion?
Anyway ... relsegs are implemented using acs rels but all the "side one/side
two" stuff's hidden from you. There's Tcl API to deal with relsegs and
groups and it's quite complete.
<blockquote> Registered users are then divided up in departments
Departments have a variety of groups (managers, staff, admin,
etc.)
</blockquote>
Each department would be represented by a group and possibly implemented by
giving each its own subsite (in .WRK at the moment .LRN communites are used,
in essence our goal is to eventually move subsite to where it has .LRN
community-like capability but without the rigid predefined structure of a
.LRN community.)
You'd then have the relational segments (subgroups) "managers, staff, admin"
and you'd add members to those relsegments.
<blockquote> There should also be groups that go across departments (All
managers, all admins)
</blockquote>
There are two approaches possible:
1. the ".LRN approach" - define global groups and relational segments for each
role and put users into those as you add them to the system. In practice in
.LRN these roles are meaningless - you can add a "professor" to the system
who is later a "student" in a group - and that's the way it should be.
2. don't represent them in the datamodel directly at all, but synthesize them
with appropriate views that sweep up all managers etc. This is perhaps more
flexible and should be efficient as all groups and all relsegs are mapped to
the acs-rels table, i.e. they're all mapped to one big flat table that's
indexed several ways.
I'd start, at least, with #2 as you can create additional views as you think
of new functionality you want to support, without having to physically modify
data in the system.
**********
Hazi wrote
Just to make sure that I understand what you want is with the creation of a sub-site(site-map sub-folder) an "admin" relseg and a "member" relseg gets created. We would then add a link from site-map to a page to manage those relsegs.
*************
Don responded
The member relseg is already created. I think it makes sense to create an
admin relseg then assign the "admin" priv to that relseg automatically (but
no members.) Of course anyone who can admin the parent site can admin the
child subsite automatically so this new relseg is for adding child subsite
admins who can't admin the parent or sibling sites.
I think the link would be added to the current admin page, replacing the
current "group" management link. We'd keep the old admin pages around but
would perhaps name the link "advanced group/relseg management" or some
similarly scary name that would warn off those who don't know how the
datamodel works. That's the problem with the current UI - it exposes the
datamodel so you need to understand the underlying SQL to understand the UI,
which is *wrong* since admins shouldn't need to be programmers.
