New Account Hierarchy problems

Neil Williams linux at codehelp.co.uk
Sun Jan 22 15:52:18 EST 2006


On Sunday 22 January 2006 8:18 pm, Josh Sled wrote:
> On Sun, 2006-01-22 at 19:16 +0000, Neil Williams wrote:
> Here's a summarization of the situation: 
>
> - The new-account-hierarchy druid's revised merge complains and prevents
> the merge if the new account-tree is different than the existing one,
> even in placeholder status.
>
> - The example-account trees have changed to have more reasonable
> placeholder values.
>
> - Since many users (Neil and myself included) have created account-trees
> from the *previous* version of the example accounts, where the
> placeholder flags were different, the druid complains in about conflicts
> in the most basic use-case.

Ah! That was the clue I was missing - this is related to old data files.

> > I think this section is wrong:
> >   if (xaccAccountGetPlaceholder(existing_acct) !=
> > xaccAccountGetPlaceholder(new_acct))
> >     return GNC_ACCOUNT_MERGE_DISPOSITION_ERROR;
> >
> > If the new account (which is generated and arbitrary) is marked as a
> > placeholder, that's sign enough that the existing account takes
> > precedence and therefore the reading should be
> > GNC_ACCOUNT_MERGE_DISPOSITION_USE_EXISTING
>
> [deletia]
>
> > I think the GUI should just "do the right thing" which would be to use
> > the existing accounts wherever they exist and NOT complain.
>
> [I don't know what you mean that "new" accounts are generated and
> arbitrary, I wouldn't consider them either.  I also don't understand the
> implication regarding precedence ... but both are immaterial...]

(I meant that the new accounts that conflict with the existing ones are 
created from a static example with a new GUID and are therefore generated and 
contain a GUID that is - to all intents and purposes - arbitrary in that it 
has no relation to existing accounts. Such accounts can be safely omitted 
from the merge without causing any problems, as opposed to the existing 
accounts that "clash" whose GUID's are integral parts of the existing data.) 
We would not want to allow a new Assets account to override the GUID of the 
existing one . . . would we?

> You seem to be saying:  "Difference in the value of the placeholder flag
> on an account should not prevent a merge".  I agree.

Yes.

> However, that does introduce a problem in the UI ... the
> example-accounts on disk are marked Placeholder, and (presently) the UI
> indicates them as Placeholder.  If an existing account of that name
> exists with a different Placeholder value, then we have 3 options:
>
> 1/ update the existing account to match the placeholder flag of the
>    example account.

Only if the other details of the account have changed. How many parameters of 
the account are checked for equality?

> 2/ fix the UI so that the placeholder column reflects post-merge
>    reality (effectively the current state of the existing account).

If all other details are the same.

> 3/ extend the UI so the user is prompted and can choose to use either
>    the existing-account or example-account Placeholder value.

This is why I based the original on qof_book_merge because it has all this 
logic available.

> I'm a fan of (2), personally.

Certainly if these are only ever to be our own sample accounts being merged 
into existing data files, (2) is a sensible default.

> We then treat the example account's 
> Placeholder flag as "advisory" or non-normative, and defer to how the
> user has their existing books configured ... but new users have their
> accounts setup "correctly".

If we can discount the possibility that the incoming accounts are intended to 
actually modify the existing accounts, then (2) is the best option.

Are there ANY situations where New Account Hierarchy will actually be expected 
to MODIFY Account descriptions or other parameters? It may be more intuitive 
just to make it explicit that New Account Hierarchy always assumes that 
incoming accounts are either NEW or DUPLICATE. Duplicates give way to the 
existing version, new get added without questioning.

Under what circumstances can New Account Hierarchy actually generate a 
conflict?

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060122/c7475761/attachment.bin


More information about the gnucash-devel mailing list