I created an object type of unicyclist, which is just a user, with the acs_objects.object_type set to 'unicyclist', another difference is that the unicyclist's context_id is set to a group of type 'uni_group'. The user is granted admin on this group, but no direct permissions on the unicyclist object.
Because of these differences I set up separate unicyclist__new and unicyclist__delete functions, the latter hooks into acs_user__delete.
This function was failing because of references to the party_approved_member_map.
The problem doesn't show up if you create a party with party__new and then use party__delete. But once a user acquires a membership_rel, or a permission, delete using party__delete will fail.
I modified my delete function to take this into account, but it seems like my changes should go into the party__delete function, something like this:
create function party__delete (integer)
returns integer as '
declare
party_id alias for $1;
rel record;
begin
-- loop over rels
for rel
in
select rel_id from acs_rels where
object_id_one = party_id
or
object_id_two = party_id
loop
PERFORM acs_rel__delete(rel.rel_id);
end loop;
-- end rels loop
-- remove permissions
delete from acs_permissions
where
object_id = party_id or
grantee_id = party_id;
--
PERFORM acs_object__delete(party_id);
return 0;
end;' language 'plpgsql';
Also, I had to reset context_id's for object which referenced my unicyclist objects, otherwise the acs_object__delete would fail. Maybe a column constraint like on delete set null, or an update statement like the following in the acs_object__delete function would work:
update acs_objects set context_id = null
where context_id = object.object_id;
But I think I recall that this might mess up the sort tree index. Anyone have any ideas on this?
