Forum OpenACS Improvement Proposals (TIPs): Re: TIP: Composable rel types
- to use still the relationship type hierarchy for permissions (maninfested in approved_member_map), which ignores the composable flag on the relationship type, and
- avoids, that the transitive property of a component is inherited by the container (admin-rel of the component ends up as admin-rel of the container).
It is still unclear to me, what should actually happen in a deeper relationship hierarchy, if composable_p is set false for a more general relationship type (e.g. dotlrn-admin) but not for a more special one (e.g. dotrln-course-admin).
member
admin
dotlrn-member
dotlrn-admin
dotlrn-ta
dotlrn-course-admin
dotlrn-student
Rather than setting the composable to 't' it would make more sense to set the composable flag to 'f' for every relationship type. Or if i think loudly, to set the attribute to +1/0/-1, where +1 is the old behavior, 0 is the composable == 'f' and -1 inherits down, such done does not have to provide a user with both 'admin' and 'member' along the composition hierarchy, but to cause the functions and triggers to add automatically the implied relationships to the component when this relationship is added (if admin is set, add automatically the membership, or similar when dotlrn-admin is added etc.)
Anyhow, each time when i look at the code, it took me a while understanding the existing model and its implications on memberships and permissions. I would love to see a simpler model such as RBAC for roles and permissions to simplify the semantics rather than reading through the source to try to understand, what ends up in what materialized table etc. Adding more flags makes understanding more complex and not simpler.
-gustaf neumann
Regarding the first of your two points re: the patch, the composable flag isn't ignored when membership relations are added; if a membership relation (or subtype) is added to a *component* group, the flag is checked to determine whether or not that relationship should be added to container groups. In practice, however the flag will have no effect on most installations because most installations will have no component groups. The second point is correct.
Your question re: semantics when a given type is composable and an ancestor is not is a good one. I think it's unclear because such an organization of subtypes doesn't make much sense. The approach I think I would favor would be to enforce false on all further subtypes of once composable is set to false (via trigger on acs_rel_types). Would that clarify things in your view?
I'm not sure I understand your comment about membership relationships being at the top of the hierarchy thus never being used. Can you explain?
I think it's true generally that membership is what most developers and users will be interested in seeing propagated from component to container and that is usually implicit when you are creating components as subgroups (there are probably some cases where subgroups shouldn't be components but that is another subject). I can think of some benefits of composition in other types, however. For example, part of our type hierarchy looks like:
member
physician
first_year_resident
...
and an example group hierarchy might look like:
Some Healthcare Organization
Hospital X
Department Y
Consider the case where you have have "First Year Residents" in Department Y. When you have an organization with multiple teaching hospitals, it might be useful to see "who are all the first year residents at Hospital X" or even "in the entire organization" or to assign this grouping some privileges at the hospital or organizational level. If the first_year_resident role propagated, this would be easy. I think it's worthwhile to afford (or rather, to not rescind) this flexibility.
I like the idea of automatically adding implied rel types. I think that is what most developers and users would expect when adding a role from a hierarchy. If you look at how the existing code functions however, an admin_rel added using the pgsql functions (or relation_add) results in a new row in both membership_rels and admin_rels but only an admin_rel in group_member_map. This could/should be corrected but I think it is a separate issue and deserves its own discussion/TIP.
Regarding your latest post, I agree about the complexity and its funny you should mention recursive queries; I also wondered whether or not we could use those techniques to simplify the group membership tables/maps while working on the composition issue. That's also a separate issue too but it's related to the type hierarchy issue above.
If we could make a determination regarding the idea of composable relationship types here, we could investigate the other issues in another thread.
i think we have similar goals: to provide for large organization scalable, differentiated and somewhat decentralized membership- and rights management. It seems to me as if the existing code base of OpenACS was developed in various layers (the often deeply nested views), competing concepts (e.g. groups and memberships rels) and APIs (and existing APIs often not used, e.g. in www directories of the admin pages of subsite and friends). Dealing with these code layers is probably the bigger issue than the original problem.
We (mostly victor) have already done some work with membership management and recursive queries that could be used as a basis. Probably, the easiest path might be
- define intended semantics based on recursive queries
- define stored procedures and a new tcl-api
- mark existing infrastruture as deprecated and replace it stepwise
- for the existing sql-structures/queries/api, one has to maintain the materialized tables and triggers for a while (similar as for the recursive queries we did for permissions)
- we have to maintain the existing sql-structures/queries/api for Oracle as well, although i would expect that porting the recursive queries to Oracle is straightforward.
As for the TIP:
- as it is, it does not hurt
- we should make clear that it is not recommended to pursue this way in the future, but to see this tip as a transitory step
- i would recommend to set the flag to false for all reltypes
having this said, i approve if it helps you in a transitional phase...
