I've had my CoA sorted by account code for years without any problem and I just tested again with a new account and it kept the sort-order. (GC 2.6.11, OS X 10.11.3)

You can examine the sort-order setting in ~/Library/Application Support/Gnucash/books/account-file-name.gnucash.gcm, making the obvious substitution.

So you're doing something unusual. Please give a detailed click-by-click account of what.

Here is my click-by-click account. Assume that I have a CoA that shows Account Code in the first column, name in the second, and others following. 
1) Click on the Account Code column heading to sort by Code. 
2) Edit an account description by adding a space after the description to make the file dirty. 
3) Save the file.
4) Close the file.
5) Reopen the file. CoA is sorted by Account name.

Sort order setting in relevant gcm file reads:

[Account Hierarchy]
column_order=account-code;name;type;commodity;description;lastnum;present;present_report;balance;balance_report;balance-period;cleared;cleared_report;reconciled;reconciled_report;last-recon-date;future_min;future_min_report;total;total_report;total-period;account-color;notes;tax-info;placeholder;
account-code_visible=true

Created attachment 322820 [details]
CoA Sorted by Code

Created attachment 322821 [details]
File reopened

Created attachment 322822 [details]
Sample file in images

Created attachment 322823 [details]
Associated gcm file

The gcm item we're interested in here is "[Account Hierarchy]sort_column" and it's set to "name" (it's the last entry in the [Account Hierarchy] group).

Try this: Make the Account Name column as leftmost. The treeview works better that way anyway. Click the Account Code column to make the CoA sort on it and quit GnuCash. Since the sort order is saved in the .gcm file you don't need to dirty and save the book. Check the .gcm file and see if it changed sort_column.

Well, it does work with Account Code in the second column, unfortunately.

I say "unfortunately" because I prefer to have the column upon which a list is sorted in the first position. I wouldn't begin to hazard a guess as to why the sort on Code sticks only when it's not the first column.

For completeness, let me say that I tried moving the Code column back to the first position after successfully having the sort stay on code in the second column, but GnuCash went right back to second column sorting. 

I don't understand why GnuCash would save the sort for Account Name in the first column, but not Account code.

I don't either, but it at least offers a hook to look for.

Created attachment 332614 [details] [review]
Save sort order on Account Tree

Came across this and thought I would have a look.

The default Account Treeview sort order when created is the name column which happens to be column 0. When saving the sort order, column 0 is checked to see if it is the sort column and if it is the sort order is not saved.

The patch changes the check for the sort column not being 'name' and then save the order.

Created attachment 332615 [details] [review]
Save sort order on Account Tree

Forgot to add bug number to patch title

Bob--

Thanks for looking into this. I haven't tested the fix, but I looked at your change. 

I profess only to know enough to cause trouble, but I wonder whether it would be easier overall to simply check if there is a sort column, and if there is, just to save the name of that column? Seems cleaner and less ambiguous to me...

David

(In reply to Bob from comment #11)
> Created attachment 332615 [details] [review] [review]
> Save sort order on Account Tree
> 
> Forgot to add bug number to patch title

Bob, you're right on with the source of the issue and I was about to apply your patch.

On the other hand David's remark got me wondering as well. My first reflex was "we shouldn't store a default value", which is exactly what you have implemented and how it was implemented before.

With David's comment in mind I believe this shows the logic of a developer and not the expectations of a user.

It looks like a detail and it probably will remain one. There is only one situation where David's proposal *visually* will behave differently from how things are currently coded: suppose we developers in the future come up with a good reason to change our mind about what should be the default sort column. It's easily done in code, just flip a couple of values in the code.

With your (and my initial) fix for this particular bug, all users that had sorted explicitly on the name column will see their account hierarchy suddenly sorted on another column. I think we shouldn't do that. Changing things behind the user's back is the best way to upset that very user.

So the right thing to do in theory would be do what David suggests and I initially meant to alter the patch to do so.

However while looking at it I found there are multiple similar situations in GnuCash like that and just changing this single one will make the behaviour inconsistent with the others, which is equally bad.

In addition I'm less certain about how to handle this for users that never explicitly changed the sort order (or sort direction or column order or any other like this). Do they care ? Do they want to keep how things are set up when we change a default, or do they prefer it changes for them automatically. I don't even know if we can distinguish between users that have explicitly chosen to sort on name or users who have just stuck with the defaults.

Consider finally that changes in defaults are extremely rare, I doubt it's worth spending much effort ironing this out. There are more flagrant user experience inconsistencies to deal with.

So with my train of thoughts written down here, in the end I have decided to commit the patch as is.

However, thanks for pointing this out David!

Thanks for implementing a fix. I appreciate it.

However, Geert, I have a little trouble with your explanation about not implementing a setting that is always stored. I honestly don't understand why you wouldn't just store the sort order in all cases. By all means, if developers come up with a fancy new default setting, then that setting should apply to all *new* installations, but any pre-existing installations should remain as the user has come to expect things to be. Just because a developer likes something new, doesn't mean the user will. Consider, if you will, the ways in which Yahoo! has changed its web mail client over the years--and take a look at the responses from users who had their mail clients changed out from under them. Not pretty. Storing a sort order in all cases eliminates ambiguity--ambiguity that already has caused me trouble. Holding to a principle that "no defaults should be stored" just doesn't make sense to me.

David, I fully agree to your reasoning.

My decision to not implement it is a practical one. I implicitly also considered
- complexity of the code changes (this kind of issue is sprayed all over the code base). I don't consider it useful to only fix one spot where all the others are still behaving differently. As said before I consider inconsistent behaviour at least as bad. Because that's not only bad for the user but also for the developer who has to maintain the code.
- developer time (very sparse)
- risk of running into this in reality - the devs have always been extremely conservative about changing default values as far as I remember, so it's unlikely we'll end up in this situation.

This makes the fix a rather low priority one IMO and given the small set of developers I went for leaving it as is.

I probably should have ended with: it will not be implemented in the short term.

I propose you create a new bug report for this. All the gui settings will need review at some point in the future when the final decision is made on the future gui toolkit to go with. That would be the right time to keep your very valid design consideration in mind.

Geert, All fair points, and I appreciate your reply. I will consider creating a new bug report, although my expertise on global issues (such as toolkits)--and the underlying design principles that guide them--is fabulously limited.

Thanks again!

David, I understand this is pretty technical, so I have chosen to create the reminder bug myself: bug 771346

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=762901. Please update any external references or bookmarks.