While I actually observed this in release 2.6.19 running in Ubuntu 18.04, I believe it is still true in release 3.6, all OSes. Start by opening a 'with sub-accounts' view of an expense account that already has existing sub-accounts. Choose a transaction that is already a member of a sub-account. In the Account field, change the text after the delimiter to a new sub-account name. Accept the warning that the account does not exist, and create the new sub-account. As the edit is committed, the transaction disappears, which is expected. If the user was smart, he would first have jumped to the other account in the transaction so that he could see what was happening. Then, after saving the new account and committing the transaction, he could jump to the new account to verify that it exists as a new sub-account of the same parent account. Now, return to the 'with sub-accounts' view of the parent account. Note that the transaction is missing. Click on the View > Refresh menu button. Expected: The transaction assigned to the new sub-account would appear. However, it does not. Later, after I am done with all the search windows in this session, I will close GnuCash and re-open it, where I expect I will finally see the new sub-account transaction in the existing 'with sub-accounts' window without needing to open a new 'with sub-accounts' window.
I have closed GnuCash and re-opened it. I found that the newly created account with it's transaction does now appear in the existing 'with sub-accounts' view.
Looking at this...
I have hopefully fixed this and will be in the next release 3.7. The query for the sub-account register was not being updated with the new sub-account just being rerun and closing and opening recreates the query and this time does include the new account. If you can build the update is in maint now. Please close bug if the changes fix your problem or add further comments and I will have another look.
Closing as fixed.
