Forum OpenACS Development: couple of bugs in acs_group__member

1: couple of bugs in acs_group__member_p?

Posted by russell muetzelfeldt on 06/28/07 07:23 AM

I've just run into what looks to me like a bug in acs_group__member_p and hence [group::member_p], as well as something that confuses me (and might be another bug)... short form is relationship types descended from membership_rel break unless p_cascade_membership is set (or [group::member_p] is called with "-cascade")...

if p_cascade_membership is true the implementation is a simple select against the group_member_map view - this considers membership_rel and all it's descendant rel_types as creating "membership" relationships by using the ancestor_rel_type column from group_element_index...

if p_cascade_membership is not true, it does a direct select against acs_rels and all_object_party_privilege_map... this will only return true for membership_rel relationships, but not for any descendant type of a membership_rel ("and rels.rel_type = 'membership_rel'")... also, the join against all_object_party_privilege_map doesn't seem to serve any purpose (it will allow a membership_rel to be considered as long as anybody has the 'read' privilege on it - the sitewide admin for example)...

is this broken, or is it my understanding of what should be happening here that's wrong?

I'm just starting a project that will depend on complex group/group relationships and custom rel_types in order to work... and I'm really hoping it all works at least vaguely as documented...

2: Re: couple of bugs in acs_group__member_p? (response to 1)

Posted by Tom Jackson on 06/28/07 09:52 PM

"is this broken, or is it my understanding of what should be happening here that's wrong?"

Unless you have spent at least two weeks looking at this code, while ignoring all other responsibilities, I would go with probably not broken, after that time, you will probably conclude the same thing, otherwise, you need to spend more time figuring it out. First you need a complete list of what you are trying to achieve via relationships (actually I make a pencil and paper drawing of objects and links/relationships). What users, what groups, what objects will attach, what privileges will apply. Most likely you will need to set this up with custom code. I don't know of any complex examples in core, so that makes it more difficult to develop.

One thing to note is that I don't think that a group-group relationship can use membership_rel, you need to create another rel_type based upon composition_rel. Don't expect to be able to use the simple membership hierarchies to achieve what you want, the data model is more generic than that and the code you are referencing is most likely a special case that doesn't apply in your situation. The only other option is that you are stuck with a fixed set of relationships, which would suck even more than having to figure it out to take advantage of it.

3: Re: couple of bugs in acs_group__member_p? (response to 1)

Posted by Malte Sussdorff on 06/29/07 09:41 AM

As Tom has not written anything specific to your problem but just some general advise, which you probably have done so already anyway, let's be specific:

Cascading does refer to sub_relationship_types, not sub_relationships. That might be confusing, especially as the API doc does not show that . So maybe we should explain that in the doc. My initial assumption (before reading this specific code, albeit only for 10 minutes, not two weeks) was that cascade refers to the direct membership and inherited membership (e.g. group of a group).

For a group (or any other party bar person) you need to create a composite_rel and then use composite_rel__new which triggers party_approved_member__add. In party_approved_member_map you can then see the party_id (which happens to be the group_id you look for IN THIS EXAMPLE (it could be any other party, including users)), member_id (which is the party_id that is a member of the group_id) and tag (which is the rel_id if there is any). It also inserts into group_element_index with the composite_rel relationship type, so you could check it there as well.

What you will probably need for your membership check though, is to create a procedure which checks the direct membership for membership_rels and the membership_rels of any composite_rels. You could achieve this by adding "-include_children" switch to group::member_p .

Hope that helped you out a little bit.

4: Re: couple of bugs in acs_group__member_p? (response to 3)

Posted by Tom Jackson on 06/29/07 11:06 AM

The two weeks suggestion only applies if you think you have found a bug, but as you can see, I've really extended that out to forever. I doubt you will find one, so it is hard to be more specific than I have been: stop looking for the bug and just try to figure out what you don't understand about the code. There are only a few people here that know anything about it, as in either wrote the code or tried to use it, or at least I haven't seen any released code to suggest otherwise. Working examples would be the best place to look for ideas. Anyone?

Forum OpenACS Development: couple of bugs in acs_group__member_p?