Bug 458573 - When editing transaction, clear button next to Category does nothing if more than 1 category (split) is assigned
Summary: When editing transaction, clear button next to Category does nothing if more ...
Status: REPORTED
Alias: None
Product: kmymoney
Classification: Applications
Component: ux-ui (show other bugs)
Version: git (master)
Platform: Other Other
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-31 21:11 UTC by Dawid Wróbel
Modified: 2022-09-22 15:35 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dawid Wróbel 2022-08-31 21:11:45 UTC
SUMMARY
When editing transaction, clear button next to Category does nothign if more than 1 category (split) is assigned. It should, however, clear the categories and all the assigned splits together with it. 


STEPS TO REPRODUCE
1. Edit transaction, add splits
2. Edit that transaction again
3. Click on the "clear"/"backspace" icon next to Category field

OBSERVED RESULT
Nothing happens

EXPECTED RESULT
Categories/splits should clear
Comment 1 Thomas Baumgart 2022-09-04 09:42:37 UTC
Do we really want it to do that? Because the action would be different when in a 'normal' transaction, only the category name/assignment is removed whereas when having splits all the splits will be deleted. I would very much prefer to disable the button also visually (if that is possible). Suggestions.
Comment 2 Dawid Wróbel 2022-09-04 20:00:24 UTC
I actually realized after posting this that disabling that action in this case was on purpose.

I think that it goes against the user intuition, though, that they can't clean-up that field in that case. But before I get to the point, let me digress as I think this fundamentally touches a bigger issue, i.e. the way we differentiate between categories and splits. The way I see it, the category field should work like this:
1) I can assign a category, once pressing enter, it is represented like a tag in a bubble. This experience is basically akin to any website where you can add tags to your post, e.g. on stackexchange. 
2) In the same field, if I want to add another category, I simply can, without having to open a split edit window. The splits are automatically added in the background *and* the amount divided evenly between them (while arbitrary rounding if total amount is not an even number). 
3) Furthermore, I can continue to add *more* categories, again in the same category, without having to pull up split editor. The split get added in the background and adjusted accordingly.
4) If needed, user can open the split editor windo and re-adjust the split amounts arbitrarily
5) After any arbitrary adjustment of splits, any further category addition/deletion from the main view would *not* recalculate anything and simply mark the transaction as invalid. 

Now, with that UI/UX in place, that single delete button would be redundant, as each tag would have its own 'x' to remove it.

It does sound like a bit of work, but in general I think it would make the whole process potentially faster and more up-to-date with what users are accustomed to. 

In the meanwhile, however, I would suggest that it still makes sense to allow the existing "clear" button remove +1 categories, in which case a modal confirmation would pop-up to confirm that corresponding splits would be removed, too. Although personally I think it's a bit extra, given that we do have Undo/Redo functionality in place, so it's not like that action is unrecoverable.
Comment 3 Bug Janitor Service 2022-09-20 04:46:55 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!