Forum OpenACS Development: Is party__delete correct?

Collapse
Posted by Tom Jackson on

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?

Collapse
Posted by Don Baccus on
acs_object__delete already deletes any permissions on it, so party delete should only have to delete the grantee_id case.  This certainly looks like an oversight.

It would seem that acs_object__delete would be the place to remove the acs-rel rows ... looks like another oversight.

Both of these problems appear to have been there since ACS 4.x day one.

The context_id thing seems dangerous IMO, as you're changing who can do what to your orphaned objects.  This is why the standard idea of "deleting" a user is to change their status rather than "nuke" them.

Some day remind me to through out the datamodel and to rewrite it using "on delete/update cascade/set default/set null" operators to maintain referential integrity as the SQL standard anticipates one will do, OK?