Deleting an account referenced by other objects

Geert Janssens janssens-geert at telenet.be
Wed Mar 10 06:49:08 EST 2010


On Wednesday 10 March 2010, Phil Longstaff wrote:
> > > 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.
> 
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.

Geert


More information about the gnucash-devel mailing list