Forum OpenACS Development: Re: Best Practices for permissions, straw man

"Adding a create privilege is unnecessary, and doesn't even make sense in the context of the OpenACS permission system, since privileges apply to objects." I think the answer is that we do have a create privilege, and the trick is that, when you want to create an object, you have to figure out what the "parent" object should be and test for "create" on that object.

It depends on what your object is and its intended use if create should be assigned to it, since privileges have no inherent meaning until one is enforced via the UI (or API depending how the corresponding object is accessed). Like with CR folders, create privilege assigned on the folder object can be taken to mean a given user/group has permission to create objects/documents in the folder.

"Instead of checking if a user has the 'admin' or 'create' privilege on an object, you could check if the user belongs to a relational segment, that is, the user has a certain relationship with a group." I thought that the point of the permissions system was that this is all behind the curtain from the perspective of permissions testing. My assumption is that for UI we always test with user_id, and if the user ('belongs to a group which ...' or 'belongs to a rel_seg for a group and that rel_seg ...') has been granted a priv on an object, then permission_p sorts that out automagically. Is this correct?

You can check for permission with any party_id which means group or user ids. permission::require_permission [ -party_id party_id ] -object_id object_id -privilege privilege

I think what was being said was that the flexibility inherent in OACS perms system lets the developer decide (via her access UI/API) how fine grained of permissions she needs enforced. You could check via the permission::require_permission call if the current user requesting to perform an action has explicit or implicit permissions set (via direct grants, grants from some group they belong to, or from inheritance up the context_id hierarchy). This gives you pretty tight, explicit control over the permissions on the object (especially if you turn off context inheritance since this sometimes inherits more perms than you want by default -- or explicity set your "top" level context object for your app to the package_id or a custom object whose perms you have dwindled down to a restricted set).

If you don't require really fine grained perms (don't have a lot of different actions on your objects with unique sets of those actions being granted to each user), you could just use membership in a subgroup (rel_seg) to mean that permission to do X on this object is implied. Theoretically, verifying membership in a group is faster than running up the explicit perms, implicit perms, context inheritance hierarchy. Though the group membership setup is a hierarchy too I believe. But likely more shallow than the perms on a given object. True? I'm just throwing out what I've gleaned trying to grok this myself!

For functions that grant permissions to other people, check for the "admin" privilege.

I would only add that the admin privilege implies you also have read/write/create/delete since you can grant any privileges you want.

Where is The Public defined?

openacs-dev=# select * from groups ;
 group_id |         group_name                 | join_policy 
-----------+-----------------------------------------+-------------
       -1    | The Public                                 | open
       -2    | Registered Users                     | open
     7417 | Personals (7316) App Group | open
     5498 | Authors                                      | open
(4 rows)

openacs-dev=# select * from rel_segments ;
 segment_id |   segment_name    | group_id |    rel_type    
------------+-------------------+----------+----------------
       2114 | Main Site Members |       -2 | membership_rel
(1 row)

How can I inspect it in the UI?

http://your.openacs_server.com/permissions/one?object_id=-1

Something neat I noticed... If you go to SiteMap and click on "Set Permissions" for your package instance (application) or folder, you can see permissions (privileges) that are inherited by your application (via its context object hierarchy) and those directly set on your application via direct grants to users/groups.
I think the Children displayed here refer to children via context inheritance.
You can also tack any object_id on the URL http://your.openacs_server.com/permissions/one?object_id=-1 and view it's privileges and inherited privileges there.

NOT UPDATED PAST HERE YET: On the index page, which lists all of the records, we do not test for permissions because we want this list to be visible to everyone. If we wanted to restrict access to a specific group, we would grant a permission: permission::grant -party_id 'specific group's id' -object_id 'the package id' -privilege read

To test this permission, we put the code permission::require_permission -object_id 'the package id' -privilege read at the top of the page.

Or I think it's also valid if we have created groups that we've decided implicitly define a specific role, we could just test for group membership. group::member_p [ -user_id user_id ] [ -group_name group_name ] [ -group_id group_id ] [ -cascade ]