Forum OpenACS Q&A: Relationship between permissions grantee and granter

Collapse
1: Relationship between permissions grantee and granter
Posted by Gregor Obernosterer on 08/23/02 12:51 PM
Dear All,

we are trying to build an interface that shows all users that have been granted a certain permission (in our case it is called 'unido_write_in_name_of') from the current user. Meaning I am the user, and I want to see all the people I gave the right to write in my name. The missing link is the relationship between the grantee and the granter.

We set up two users called Eddi Editor and Freddi Editor that the admin user granted the permission 'unido_write_in_name_of':

33824 | 16917 | unido_write_in_name_of 33824 | 16919 | unido_write_in_name_of

We made an attempt of a query, but it returns 0:

SELECT p.first_names || ' ' || p.last_name, p.person_id FROM persons p WHERE p.person_id in ( select grantee_id from acs_permissions where object_id = '2537' and privilege = 'unido_write_in_name_of' ) ORDER by p.last_name

Any hints? Greetz from Austria

Collapse
2: Response to Relationship between permissions grantee and granter (response to 1)
Posted by Gregor Obernosterer on 08/27/02 12:07 PM
... an excerpt from our internal bboard discussion, posted by Tilmann.

To find out all persons that may write in the name of Freddie: 

unido-dev=# select person_id from persons where acs_permission__permission_p(16919, person_id, 'unido_write_in_name_of')='t';
 person_id 
-----------
      3105
     16917
(2 rows)
(For the fun of it I added Gregor too, who is the 3105). The only problem with this query is that it takes ages to finish - about 30seconds on the test server, which is inaccaptable. Selecting from the priv map view directly is blazingly fast compared to the previous one: 
unido-dev=# select grantee_id from acs_object_grantee_priv_map where object_id=16919 and privilege='unido_write_in_name_of';
 grantee_id 
------------
       3105
      16917
(2 rows)
Beware though that these are parties, e.g. one of those id's returned could be a group as well. I think this can be reflected in the UI (e.g. list groups along with individuals) and let's do with it for a start. What it also leaves out are permissions acquired via a relational segment, of which I have no idea what it is, so no idea how to take care of it. I'd suggest adding a comment to whereever this query is going to reside in the system like that: 
# returns party_id's. does not deal with relational segments.