Both sides of internal transfers' accounts not changed

Bug #1663789 reported by Kinnin Vo-Shay
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
HomeBank
Fix Released
Medium
Maxime DOYEN

Bug Description

Homebank seems not to update both sides of an internal transfer when changing the transaction's accounts. There are also issues with dealing with the problem after it arises.

Below I describe what I see with the example I have attached, which has 3 accounts, and a single transfer from "account 1" to "account 2". This is on Homebank 5.1.3 on Windows 10

Action 1: in the transaction window of "account 1", change the destination account of the internal transfer from "account 2" to "account 3".
Result 1: the transaction window of "account 1" will update correctly to show the change (good), but the main window still shows a balance as it did before the change (bad). Also, the transaction window of "account 2" will still contain the transaction (bad), and the transaction details from "account 2" will show that the transaction's account is still "account 2" (also bad). This means that internally the two sides are now disconnected (annoyingly bad).

Action 2: run the internal-xfer consistency check from "account 2" or "account 3"
Result 2: no inconsistency found, even though there is an inconsistency (bad).

Action 3: run the internal-xfer consistency check from "account 1"
Result 3: problem detected, asks to fix (good!)

Action 4: say "yes" to fixing the inconsistency from "account 1"
Result 4: a matching entry for the transfer is created in "account 3", without any review (mostly good), but leaves the leftover half in "account 2" (bad!).

Action 5: run the consistency check from "account 2"
Result 5: problem detected, asks to fix (good!)

Action 6: say "yes" to fixing the inconsistency from "account 2"
Result 6: the other half of the transaction is created in "account 1", meaning there are now two internal transfers where there used to just be one (bad)

P.S. A similar situation occurs if you change the transaction's source account.

Revision history for this message
Kinnin Vo-Shay (vo-shay) wrote :
Revision history for this message
Maxime DOYEN (mdoyen) wrote :

You opened the 2 account window at the same time ?
I never tested this to be honest, usually people work on 1 account at a time.

Revision history for this message
Kinnin Vo-Shay (vo-shay) wrote :

The result is the same whether I have both account windows open together, or if I only have one them open at a time during this process. Also, saving the file at any point doesn't change anything either; the corrupted data is just saved to disk.

Revision history for this message
Paul White (paulw2u) wrote :

I've come across this problem too using the Linux version of 5.1.3.

This is with only one account window open. If I need to change the source or destination of a transfer I find that the only reliable way of dealing with it is to delete the transaction and create a new one.

Revision history for this message
Kinnin Vo-Shay (vo-shay) wrote :

Deleting and recreating is what I've had to do a couple times as well, but I've not liked it because sometimes I forgot a field, and then I had data loss I needed to recover from. It would be best if the bugs with internal transfers are worked out :)

On that note, I found another bug when changing an internal transfer to another payment type (i.e. non-internal transfer, so that the linked transaction was deleted), and then changing it back to an internal transfer. Changing it back to an internal transfer doesn't work however :(

Looking into it, this is because the transaction retains the kxfer key despite it not being an internal transfer, so when I go to change it back to an internal transfer type that tag becomes an issue. The internal xfer consistency check tool doesn't detect this problem either.

I've attached the xhb file that shows what I got after doing this to the example file I attached earlier.

Revision history for this message
Maxime DOYEN (mdoyen) wrote :

Investigated about this. This is broken since 5.1.x. Needs to rewrite some part so will fix all of this.

Just for curiosity: what motivate to change a int xfer account, mistake or usage ?

Changed in homebank:
assignee: nobody → Maxime Doyen (mdoyen)
importance: Undecided → Low
milestone: none → 5.1.4
status: New → Confirmed
importance: Low → Medium
Revision history for this message
Kinnin Vo-Shay (vo-shay) wrote :

In my case, it was usage.

I had a number of individual accounts to track locked-in investments, but the number of accounts was becoming unwieldy. So I was started looking combining them into an umbrella account; I noticed the problems when I tried to change the the internal transfers to the new account. After that I worked on reproducing the issue in a small example file(s).

Maxime DOYEN (mdoyen)
Changed in homebank:
status: Confirmed → In Progress
Maxime DOYEN (mdoyen)
Changed in homebank:
status: In Progress → Fix Committed
Revision history for this message
Maxime DOYEN (mdoyen) wrote :

5.1.4 is privately available here for last testing before release:
http://homebank.free.fr/public/

Revision history for this message
Paul White (paulw2u) wrote :

Tested 5.1.4 on Xubuntu 17.04. Works for me, thanks.

Revision history for this message
Kinnin Vo-Shay (vo-shay) wrote :

5.1.4 fixed this issue on Windows 10 as well :D

Maxime DOYEN (mdoyen)
Changed in homebank:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.