Forum OpenACS Development: Re: acs_rels: why and when to use

Collapse
Posted by Randy Ferrer on

Ok...I'm a bit confused. If I may, let me try another example:

Let's start with the current set-up where once a user registers, that user then has a "Membership Relation" to "Registered Users" relational segment as is standard now.

Now, for a specific package I would like to create various groups that would be permissioned to view or read only certain pages of the output presented by the package. In other words a user must first be a "Registered User" and then needs to be permissioned to see specific pages or sections of the output for the package. Of course, a user that is only a "Registered User" can't see any pages generated from this package." To do this, would I need to create an acs_rel relation "Registered User" -> "Group 1" and so on for all my other groups? Or am I spinning my wheels here. The idea is that an admin can then assign individual viewers to the section they are permissioned to see. Another use of this might be to authorize someone to view say a set or reports after purchasing them on line. Is this the way to go or is there a better approach?

Thanks for any insights into this.

Collapse
Posted by Tom Jackson on

You might also check out the thread on Relational Segments: how do you use them.

Create your group for your application, the one that can see everything. Give a membership_rel to all users you want to be able to 'read', for instance. A membership_rel is a specific type of acs_rel. It puts a row in membership_rels, which triggers a bunch of pl code to at least create rows in party_approved_member_map. Any general permissions you want everyone to have could be assigned to the group, or you could create a relational segment. Lets say the group_id is 100. If you created a relational segment that said "all users with rel_type = 'membership_rel' to group 100 are part of this segment", then you would end up with two rows in party_approved_member_map, one for the group and one for the rel_segment. You can assign permissions to either of these. If you wanted a different grouping of users, say the 'advanced readers', you would first create a subtype of membership_rel say 'advanced_readers_rel'. Once you have this subtype, you can create a relational segment that says "users with rel_type = 'advanced_readers_rel' to group 100 are part of this segment, named 'Group 100 Advanced Readers'. Then you would use membership_rel__new, or whatever the tcl api call is to add the new rel. You use the same call, but for the rel_type, you just substitute 'advanced_readers_rel' instead of the default 'membership_rel'.

Shoot, now I'm confused.

Collapse
Posted by Randy Ferrer on

jajajaja. Ok...scary thing is I think I follow you Tom. Ok - let me see if I can make this example even clearer. Here are the users on my system and what they will be able to see.

  • Public user - This user can see content for which no registration is necessary. Like forum, blog etc. has no write permissions anywhere.
  • Registered user - This user can comment on blogs, forums and can do the general stuff most registered users do like on say openacs.org
  • Group A Viewer - This viewer is a registered user who is also permissioned by virtue of being a member of Group A, to view content on a specific package - let's call it "Special Reports". So this package generates specific reports for different viewers. Let's say this group is the Southeast Marketing group and they will see the Southeast Market Sales Reports. Registered users who are members of this group are the only one's who can see this content.
  • Group B Viewer - This viewer sees the Northeast Market Sales Reports.
  • And so on....

An admin can then make a user part of the group for the reports they are authorized to view. I'll need to read all this again - now I'm confused again - not that it was clear to begin with...jajajaja. Does you description help achieve this???