Deleting an account referenced by other objects

[Phil Longstaff]

On Wed, 2010-03-10 at 12:16 +0100, Geert Janssens wrote:
> On Wednesday 10 March 2010, Phil Longstaff wrote:
> > Bug 140400 (https://bugzilla.gnome.org/show_bug.cgi?id=140400) says that
> > you can delete an account even though business objects still refer to
> > that account.  I want to tackle this bug.
> > 
> Great ! I think it's the oldest critical bug still open.
> 
> > In general, no object should be deleted if there are other objects that
> > refer to it.  What do we want gnucash to do if the user tries to do
> > this?
> > 
> > If I try to delete an account that still has splits, I am given a dialog
> > box so that you can move the splits to another account.  Suppose I try
> > to delete a tax table that still has vendors or billterms that refer to
> > it?  Get an option to move them to a new tax table?  Simplest response
> > would be to show me a list of objects that have references ("Customer
> > ABC, Vendor V, ...") and let me clean them up, only allowing the delete
> > to go ahead once the references were gone.  Not as user-friendly
> > perhaps, but easier to implement given the number of different object ->
> > object references.
> I think offering a list is sufficient. A nice extra would be if the list also 
> contained a dropdown per entry that would list all the available alternatives. 
> So in your "remove tax table" example, the list would show your vendors still 
> using the tax table and after each vendor a dropdown with the list of 
> available tax tables, bar the one you are trying to delete.
> 
> I'm not sure the last part can be made generic enough to work in all cases 
> though. Do we have some overview of all the possible object->object references 
> that are currently possible ?

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.

> 
> > 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.

Phil