Forum OpenACS Development: active subsites with different membership groups

1: active subsites with different membership groups

Posted by Roger Williams on 07/30/02 08:39 PM

Since I needed this, I got mad and figured this out the other day.

As far as I can tell, I think I got this to work (although it is tedious). I can document this if there is interest. In the meantime, I am still wokring on the code fixes to make it (more easily) doable from the UI.

Note: I had to add the users to Main Site Parties manually. I presume this is trivial to add to user-add.tcl (or whatever). Also, the SQL is probably not too bad to slam all the existing users either.

The last time I looked I could not find any documentation about how this works in dotLRN (I do not have time to download it and figure it out), so I have continued on my own track.

Regards..

Ref: the other thread about this

2: Response to active subsites with different membership groups (response to 1)

Posted by Don Baccus on 07/31/02 02:11 AM

Yes please document this!

Regarding dotLRN it has its own group management.

In the future I'd like to look into revamping the core and standard subsite package to do stuff much like dotLRN does currently, with an eye towards merging as much as possible.

And another idea I want to explore is getting rid of the group membership altogether, leaving only relation segments around (which dotLRN uses heavily). Relsegs let you define subsets of groups, and there's no reason that "the subset that consists of all members of the group" needs to be special (relsegs were a late addition to ACS 4 and this may be why aD didn't take this approach in the first place).

IMO this might clean up the kernel some and I know for a fact that on a large installation like SloanSpace, with a couple of thousand groups and relsegs, that permission checking would speed up by a third.

Anyway ... if you'd document what you've learned I'd appreciate it.

And yes users should be added to the main site parties group automatically ... and if they register for a subsite they should be properly entered into the hierarchy, no?

3: (cryptic test procedure for) active subsites with different membership groups (response to 1)

Posted by Roger Williams on 08/05/02 05:16 PM

Hey Aldert:

I am working on some fixes and a document that explains this in detail so someone could do it without knowing the internal stuff (i.e. just from screens that have labels and values that make sense..hey there's an idea!).

The screens are completely messed up, but the underlying stuff mostly works. You can find out more about the ArsDigita coder's original intent by running something called Group Admin Pages - Acceptance test which can be found at this location on my server: http://<replace-this-with-your-server>/doc/acs-subsite/group-admin-pages-acceptance-test.html

But from reading your posts, I can see that you have been swimming in the back-end, so here are the raw steps that I performed on an unmolested ACS 4.2b system (not OACS!). I am interested to know if these steps work/look the same on OACS.

create 7 test users
create 2 subsites
create 1 application (e.g. bboard) under each subsite
check and repair the context_id on each application instance to point to the subsites (I did this in sqlplus)
-----------------------------------------------
go to Admin (for Main Site)
group types
select group
add 2 groups of type group
back to Admin
relational segments
select MainSiteParties (in MS mem (MR to MSP)
(your 2 groups should be components)
add each user as a member of MSP
back to Admin
groups
put 3 in one group and 3 in the other
-----------------------------------------------
Site map
select Don't Inherit from .. on both subsite permissions
give the first group permissions to the first subsite
give the second group permissions to the second subsite

At this point you will find that group members can access their respective subsite and that the seventh user you created cannot access either subsite. I will document this later in a more understandable way.

Regards..

4: (the future of) active subsites with different membership groups (response to 1)

Posted by Roger Williams on 08/05/02 06:11 PM

Hey Don:

I have no idea how dotLRN works, but (as I have told you) I have been doing some work in the /packages/acs-subsite. This is related to groups/permissions/site-map. I think many of these changes will be easy to translate to OACS, but I have not looked into this yet.

In terms of group mambership and relsegs, my impression is that it all uses relsegs (and reltypes) now. In fact, I am pretty sure that with minimal changes to the underlying infrastructure (and more extensive corrections to the screens), I think the system wil provide these functions now.

I also have made some progress on how permissions needs to work. I am always not sure how interested the community is in these changes. But I will document this stuff soon.

Regards..

5: Response to active subsites with different membership groups (response to 1)

Posted by xx xx on 08/05/02 11:23 PM

Thanks Roger,

I'll try your method next week. I am a few days off/away. Maybe somebody else can respond earlier to see if it works with OACS.

6: Response to active subsites with different membership groups (response to 1)

Posted by Don Baccus on 08/05/02 11:26 PM

Any ideas you have about permissions would be welcome. In fact I'm planning to start putting together some ideas I've been having in the next week or so. If you've got anything you can share with me now, I'd appreciate an e-mail. I want to organize my thoughts before putting them out for others to rip apar.. I mean comment on.

7: Response to active subsites with different membership groups (response to 1)

Posted by xx xx on 08/11/02 02:44 PM

Roger, as promised, I tried your method but it breaks at "add each user as a member of MSP" (OpenACS 4.5 PG 7.1).
Registered users are not shown. Even if I change /admin/relations/add in a way that all registered users can be picked, the system doesn't allow me to add them to MSP (probably because their element_id is not in application_group_element_map)
Now considering the responses of Don, Reuven, Lars, and the discussion on OpenACS-dotLRN, I'll have to pass, for now. I'll try a new territory. Thanks.