> On May 2, 2020 w18d123, at 4:44 AM, Geert Janssens > <[email protected]> wrote: > > Op zaterdag 2 mei 2020 08:23:19 CEST schreef Adrien Monteleone: > > Indeed, I clicked Edit on an Asset account and I can only change it to: > > > > Bank > > Cash > > Asset > > Credit Card > > Liability > > > > I get the first three if there is going to be a limitation, but allowing the > > last 2 and not allowing even another debit balanced account like Expenses? > > > > Strange. > > > > I’m starting to wonder if this is a bug. If not, can someone shed light on > > the reasoning for not being able to refactor accounts except within their > > current parent type? > > The idea here is that you can't put expense accounts under the an Asset > parent account. So if you want to change an asset account to become an > expense account, you will first have to select a parent account that is an > expense account. That will then allow you to change the account type.
Thanks for the info Geert, I keep forgetting the need to assign a new parent first, my apologies. > > I agree the UI can use some more polish to make this a better experience. The > UI's original idea was to show the valid account types that are available for > a given parent account. I think this would be more easily understood if the > parent account and the accountype widgets would switch places. It is more > intuitive if a lhs selection (for left to right interfaces) affect what can > be selected in a rhs selector. Not the other way around. Interesting musing on the UI. I see now, having the type first can lead one to think the order is to select it rather than parent first. But as you mention, handedness is a concern. How difficult would it be to show all types, but with some indication that certain types are allowed, and if other types are chosen, a warning is issued that a new parent matching it *also* needs to be selected, otherwise the change will not commit? This would keep the restriction in place, but make the process discoverable. > > Playing with this a bit more I wonder if other combinations make sense or > possibly conflict with gnucash' internal assumptions. For example, are there > valid use cases to store an income account under an expense account or the > other way around ? I could see a case for various mess in the tree, probably to track performance of jobs, properties, etc. This would be abusing the tree as an analysis or tracking tool, rather than a classification tool. There is a more proper way to handle such cases, so allowing it would likely just introduce mess and confusion. As it is, some people go through the trouble of creating elaborate trees for such things when some additional means of classification or tagging would work better. > > And another minor glitch: when you start from for example an Asset account, > then change the parent to a liability account and back to an asset account > without closing the window in between, the asset account now suddenly has > become a Liability account. Hmm.. Sounds like a bug. I would expect whatever was the last thing I had selected would be what would be saved. If any other preference worked this way, I could imagine some confusion. I like the idea of real-time preferences without `Apply` or `Okay` but it seems then the last change isn’t getting applied even with one of those buttons. (as in the first change seems ’sticky’) Regards, Adrien _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
