Forum OpenACS Q&A: Problem with acs_permission__permission_p?

Hi,

I created a new privilege type with:

select acs_privilege__create_privilege('terms_signed');

I then assigned this privilege to a user thus:

permission::grant -party_id [ad_conn user_id] -object_id [apm_package_id_from_key epas] -privilege terms_signed

This worked ok, and the entry existed in the permissions table.

However when I try to check for the existence of the permission like this:

set terms_p [permission::permission_p_not_cached -party_id [ad_conn user_id] -object_id [apm_package_id_from_key epas] -privilege terms_signed]

The $terms_p is 0.. which is incorrect.

Digging down a bit its the

acs_permission__permission_p

postrges call that is returning 'f' (false). However I'm not quite sure I fathom what this query is doing i.e. its source is

return exists (select 1
          from acs_permissions p, party_approved_member_map m,
acs_object_context_index c, acs_privilege_descendant_map h
where p.object_id = c.ancestor_id
and h.descendant = permission_p__privilege
and c.object_id = permission_p__object_id
and m.member_id = permission_p__party_id
and p.privilege = h.privilege
and p.grantee_id = m.party_id);

Interestingly, if I use the privilege 'write' instead of my own it works as it should.

Am I doing something incorrectly or is this a bug?

Thanks

Collapse
Posted by Jade Rubick on
This doesn't really answer your question, but creating custom privileges is not recommended practice any more. It works fine, but there are performance implications.. it really slows things down if every package does this.

Otherwise, I'm not sure what's going on. It's supposed to work..

Collapse
Posted by Simon at TCB on
Oh, ok, thanks for that. Didn't realise. Mind you it has been a while :)

Is there a 'best practices' or similar available? i.e. what should I do as an alternative?

Cheers

Collapse
Posted by Jade Rubick on
I would just use the standard permissions:

read
create
write
delete
admin

I've updated these docs:

https://openacs.org/doc/current/permissions-tediously-explained.html

but that hasn't been regenerated yet.

Collapse
Posted by Don Baccus on
are you sure ad_conn user_id is the same in both cases?
Collapse
Posted by russ m on
re: just using the standard permissions - I tend to create an additional "readwrite" permission that has both "read" and "write" as children and is presented to the users (where appropriate) as if it were the "write" permission. Although things like file storage need a write permission that doesn't imply read (so drop boxes etc. work) there are many cases where "write" should imply "read" and having a single permission to grant and revoke in that case simplifies the UI and stops the users from getting confused.
Collapse
Posted by Simon at TCB on
Yes, pretty positive. I even tried replacing the ad_conn with the literal id's involved.

I also tried calling the acs_permission__permission_p call with the literal ids, and it still failed to work.