Deleting an account referenced by other objects

[Phil Longstaff]

On Wed, 2010-03-10 at 09:56 -0500, Derek Atkins wrote:
> 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
> 

What I'm going to do is add a QofInstance routine which will return a
list of objects which refer to my instance.  If NULL, the object can be
safely deleted.  If not NULL, I can present the list - for each object,
call a new qof_instance_get_display_name() routine which returns a
string (e.g. "Account ABC, Customer CCC, Tax Table X") which can be put
into a gtk list so that the user can make changes to remove the
references.

To generate the list, for each object type, the code will call a "give
me a list of your type of object of this type refer to my object?".  In
some cases, the answer is a clear NO (no customer refers to lots, for
example).  In some case, (what splits refer to an account), there is
already a routine to get the list.  In some cases (what customers refer
to an account), the code can loop through the customer collection.  In
the future, if there is unloaded data in the database, a query may be
required to see if there are any references.

This means that the object referred to doesn't need to know about new
object types.  An object just needs to know what it refers to.

Phil