Deleting an account referenced by other objects

[Derek Atkins]

Geert Janssens <janssens-geert at telenet.be> writes:

>> Yes, making it generic enough is the question.  I'll start with a list
>> for now.  At least that's better than a "sorry, I can't delete this
>> object because something else refers to it and you need to figure out
>> what that other object is" dialog.
>> 
> Agreed.
>
>> > > Also, given that theoretically, new objects with
>> > > links to existing object types can be added providing a list may be the
>> > > best that can be done.
>> >
>> > I don't understand what you mean with this ?
>> 
>> I can add a payroll module or inventory module which contains new object
>> types, some of which may link to existing core or business objects.  The
>> core objects should not know about these new object types.
>> 
> Ok, now I understand. I didn't think of that.

And that's exactly why I didn't tackle the problem.  I didn't want to
make an Account knowledgeable about an Invoice or GncEntry.  So I
basically left it with a "just don't do that".  Which is where we are
now.

Fixing this.....  Would probably be hard.  The EASIEST way I can think
of to do it would be to extend QOF events and let an event handler send
a response back that can prevent an action from occuring.  E.g., you
could do something like:

   if (send_event(QOF_INSTANCE(this_obj), QOF_EVENT_PRE_DELETE) == in_use)
   {
      display_dialog (Sorry, you cannot delete this object; it's in use)
      return;
   }

Of course the follow-up bug will be "what's using it?"..  So perhaps the
dialog should be put up by the denier?

Like I said, it's a HARD problem, and one I didn't want to try to
solve.  It's also why I didn't implement "delete" for the biz objects.

> Geert

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available