Bug 506939

Summary: UX regression by moving the Payee textbox away from the date textbox
Product: [Applications] kmymoney Reporter: Jack Hill <jackhill3103>
Component: generalAssignee: KMyMoney Devel Mailing List <kmymoney-devel>
Status: RESOLVED DUPLICATE    
Severity: normal    
Priority: NOR    
Version First Reported In: 5.2.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Jack Hill 2025-07-12 09:24:49 UTC
SUMMARY
IIRC in KMyMoney 5.1 the payee textbox was directly after the date. This was ideal because it meant I could enter the date, tab to the payee textbox, then enter an existing payee and automatically copy over the category and tags. With KMyMoney 5.2 there is now the Payment/Deposit textboxes before the payee. This means I naturally want to enter the amount first, and then enter the payee. But unfortunately if the amount is already entered then I don't get the dialog box to copy over the category and tag from previous payments. IMO this is a UX regression, as it means I have to remember to skip the payment textbox, or remember what category and tags I have set.

STEPS TO REPRODUCE
1. Start adding a new transaction
2. Add the date
3. Press tab, then add the amount
4. Press tab until Payee is focused
5. Start typing Payee, then select one of the existing payees

OBSERVED RESULT
Payee is automatically inserted, but there is no dialog to choose to auto-insert the category and tags.

EXPECTED RESULT
A dialog box appears asking whether to automatically insert the category and tags

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20250710
KDE Plasma Version: 6.4.2
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.5-1-default (64-bit)
Graphics Platform: Wayland

ADDITIONAL INFORMATION
Comment 1 Thomas Baumgart 2025-07-12 11:51:02 UTC
This has been changed to support autofill even if the amount is already filled. KMyMoney 5.2 also supports to modify the tab order by pressing Ctrl+Alt+T when editing a transaction.

*** This bug has been marked as a duplicate of bug 506625 ***