Forum OpenACS Q&A: groups question

Collapse
1: groups question
Posted by Vince T on 04/16/02 04:51 AM
Hi,

I'm trying to understand groups, composition and membership relation. From the docs and forums I've gathered some vague understanding of the concepts. Am I right in that the basic difference between composition and membership is transitivity?

that if user X is a part of (i don't if i should use the word member) Group A and Group A has a composite relalation to Groub B then X has a composite relation to Group B also.

where as if user X is a part of Group A and Group A has a member relation to Group B then user X does not necessarily have a relation to Group B.

Is this right?

My practical purpose is that in my site I would like to create group heirarchies as such:

Company Internal Groups
----Managers Group
-------manageruser1
----Employees Group
-------employeeuser1
Company Customers Groups
----Customers
-------CustCompany1
----------CustCompany1user ...
-------CustCompany2
----------CustCompany2user ...


My implementation in OACS is thus:

Company Internal Groups - Group Type
--Managers Group - Group of group type Company Internal Group
----manageruser1 - User composite of Managers Group
--Employees Group - Group of group type Company Internal Group
----employeeuser1 - user composite of Employees Group

Company Customers Groups - Group Type
--Customers - Group of Group Type Company Customers Groups
----CustCompany1 - Group composite of Customers Group
-------CustCompany1user1 - User composite of CustCompany1
-------CustCompany1user2 - User composite of CustCompany1
----CustCompany2 - Group composite of Customers Group
-------CustCompany2user ... - User composite of CustCompany2


Am I totally off in my take on this? As you can see, I didn't use membership relation at all because they are straight up heirarchies. Is this correct? Also is that the proper use of group type?

Also is there an existing function that will give you a user's immediate group. Or can you define a primary group that the user is a member in? I need this for one of my fields. (In the above example, I need to note always that the userA from custcompanyA)

On a side: I've been looking for a list of basic functions liket ad_system_name and the like. Can't seem to find it in the api browser. Can anyone point me to the right place? In particular I'm looking to find some user and group specific functions.

Thanks a lot in advance. Making some progress but I really am not confident in my grasp of some of the concepts and am reluctant to move forward.
Collapse
2: Response to groups question (response to 1)
Posted by Vince T on 04/16/02 05:58 AM
sorry, I meant component when i wrote composite...and that the users were members of their respective groups...
Collapse
3: Response to groups question (response to 1)
Posted by Andrei Popov on 04/25/02 02:41 PM
I think that what you could actually do is to define membership relation for all employees (including managers) and then define component relation for managers group. This way ``managers'' become a subset of ``employees''. But frankly, my head goes numb with all the acs_object/party/person/user/group flexibility... :(
Collapse
4: Response to groups question (response to 1)
Posted by Tilmann Singer on 04/25/02 07:29 PM
Vincent, if your last correction translates into 
Company Internal Groups - Group Type
--Managers Group - Group of group type Company Internal Group
----manageruser1 - Member of Managers Group
--Employees Group - Group of group type Company Internal Group
----employeeuser1 - Member of Employees Group
Company Customers Groups - Group Type 
--Customers - Group of Group Type Company Customers Groups
----CustCompany1 - Component of Customers Group
-------CustCompany1user1 - Member of CustCompany1
-------CustCompany1user2 - Member of CustCompany1
----CustCompany2 - Component of Customers Group
-------CustCompany2user ... - Member of CustCompany2
then you are definitely on the right track (I think).

As far as I understand, the difference between the two basic relationship types component and membership only applies to groups. Persons (and users) can only be in membership relation to groups. e.g. a user can never be a component of something.

Another source for confusion is that by default there is a subtype of the membership relation called "user profile". I don't know what it is supposed to do. It propably has a special meaning regarding subsites - I just remember that some time ago I tried to add a user to a group and for some reason I could not select this user when using the "User Profile" relation, it only worked with the plain Membership relation.

To check membership take a look at the plpgsql function acs_group__member_p - It should do exactly what you need. Make sure to have a recent cvs checkout though, because this function was fixed not that long ago.

Collapse
5: Response to groups question (response to 1)
Posted by Don Baccus on 04/25/02 07:47 PM
User profile is absolutely hosed.  Naybe even evil.  It wasn't created by default in the Oracle version and I've removed the call to create it by default in the PostgreSQL version.

Creating it makes the groups and related admin UI confusing among other things.

It's not at all clear what was intended with this as the code's obviously incomplete.

Collapse
6: Response to groups question (response to 1)
Posted by Tilmann Singer on 04/25/02 09:38 PM
Don, thanks - that clarifys a lot.

Do you have any similar insight on the purpose of the group type "Application Group"? In what regard are groups that are of this type different from normal groups?

Collapse
7: Response to groups question (response to 1)
Posted by Dave Manginelli on 04/25/02 10:00 PM
I think the benefit of Application Groups is that they include a package_id field which allows them to be easily "scoped" to a specific "application"/subsite.
Collapse
8: Response to groups question (response to 1)
Posted by Dave Manginelli on 04/25/02 10:02 PM
I meant package (instance?)/subsite not application/subsite...
Collapse
9: Response to groups question (response to 1)
Posted by Piyush Shah on 04/26/02 12:16 PM
We've been trying to get our heads round the whole parties/groups/persons structure too. There may be an error in the initial primary membership relationship type that is created. From the dev notes it seems that the membership rel should allow a group to be a member of another group but the master membership rel created in acs-kernel/sql/postgresql/groups-create.sql makes object type two a 'person'. Should this not be 'party' so that both persons and groups can be members of groups?
Collapse
10: Response to groups question (response to 1)
Posted by Don Baccus on 04/26/02 01:47 PM
I think Dave's right in that this is the only difference.  If you're playing around with these groups do a CVS update from the oacs-4-5 branch, I've fixed bugs in their creation in both the Oracle and PG version.  The PG version was thoroughly broken (an inverted tree query, i.e. one that ran in the wrong direction from the start node) and the Oracle version didn't work if you had a subsite tree more than two levels deep.