New Account Hierarchy problems

Josh Sled jsled at asynchronous.org
Sun Jan 22 15:18:36 EST 2006


[CC'ing gnucash-devel]

On Sun, 2006-01-22 at 19:16 +0000, Neil Williams wrote:

> I don't understand what's happened to this routine. It was created initially 
> to use qof_book_merge but now it picks bad defaults and complains when the 
> book already contains accounts - the entire premise of the function!

Yes, the druid complains when the accounts are different than the ones
that exist ... specifically as you alude to later, when the status of
the placeholder flag is different.



> In the current design, I get an unintelligible error message telling me to 
> resolve a conflict I cannot even see in the dialogue. By arbitrarily clicking 
> on each column until something changed, I realised that it is the mysterious 
> column marked simply 'P' that needs the check mark removed - I thought the 
> point of the function was to handle existing accounts and allow them to be 
> updated with other account details.

Yeah, this is pretty annoying.  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.


> Can't the columns be made resizeable? I think the flags need to be reversed so 
> that *by default* accounts that already exist are NOT made into automatic 
> errors. The error message just doesn't seem to help.

Yeah, I've never been happy about the width of the "placeholder" column;
on my display it's not even a full "P", but instead a truncated one.
Certainly "P" isn't a user-interface universal.  And I believe the "use
existing?" column does have a bit more text, but it is -- again -- not
resizeable.


Also, I'm not super-thrilled with the text here -- either the "use
existing?" column-heading or the error help text.  Suggestions for
improvements are welcome.


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

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

The current logic (basically: match on name and placeholder equality)
was the output of an IRC discussion with David the other weekend [see
line 167 of
http://svn.gnucash.org/trac/browser/gnucash/trunk/GNOME2_STATUS?rev=12336 if you're curious of the discussion].  At the time we believed that the placeholder flag matters much.  After implementing it and playing with it, I don't believe so anymore.

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.

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

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

I'm a fan of (2), personally.  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".

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`


More information about the gnucash-devel mailing list