Deleting an account referenced by other objects

[Derek Atkins]

John Ralls <jralls at ceridwen.us> writes:

> On Mar 10, 2010, at 6:56 AM, Derek Atkins wrote:
>
>> 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.
>
> Could the QOF event include sender information, which the handler could use to populate a list?

The event can.  the response.... Currently there's not much room in the
event response for anything; I was thinking we could just overload the
return value, but even that might be challenging without a rototill of
the code.  Adding room for ancillary data in the response would be even
more challenging.

> Regards,
> John Ralls

-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