Bug 270752 - Cannot edit or delete a transaction
Summary: Cannot edit or delete a transaction
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: SVN
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-12 11:54 UTC by allan
Modified: 2011-07-10 21:46 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description allan 2011-04-12 11:54:38 UTC
I've just noticed that in two accounts that are not used regularly the first transaction cannot be edited or deleted.  That is, those context menu items are disabled.  Neither does double clicking open them.  Also, only the 'new' button is active.  The 'cleared' field may be changed.  This is the same both with and without the transaction form.  In both cases the transaction is the first.

Also, if I select that transaction and, because I can't edit,  I select 'new', the transaction now opens.  However, if I enter a character into the empty memo field, the enter button does not become active.  Neither does the cancel button.  If I change the date, the enter button now is enabled, but not the cancel.  If I click enter, the transaction closes but the edit has not been registered.

Both accounts are in the same institution, but removing one of them from the institution doesn't help.

Consistency check highlights no problems.
Comment 1 Jack 2011-04-12 16:59:21 UTC
How does the date of that transaction relate to the opening date of the account?  If that's the problem, you may not be able to edit the transaction to change the date, but you could edit the account to change the opening date to earlier than the transaction.
Comment 2 allan 2011-04-12 17:14:11 UTC
(In reply to comment #1)
> How does the date of that transaction relate to the opening date of the
> account?  If that's the problem, you may not be able to edit the transaction to
> change the date, but you could edit the account to change the opening date to
> earlier than the transaction.

Sorry, Jack, I realised after I should have said.  The account opening date was OK, but I've made it one year earlier - just to be sure! -  and no difference.

I've tried on an older file and it's the same there. I've now gone back to Jan 2010 and both still the same, so it's long-standing.
Comment 3 allan 2011-04-13 00:08:27 UTC
Eventually, I went back to July 2009, and had two files for the same day, one which worked and the later one didn't.  Compared both files and found some accounts had been closed.  Found that both transactions had been transferred from other accounts, which had been closed, which was preventing editing.

So that issue is resolved.

I haven't closed the bug, yet.  I don't know if anyone is bothered about being able, apparently, to open a new item with an existing item already selected?
Comment 4 Cristian Oneț 2011-05-21 23:35:23 UTC
I can confirm the buggy behavior of the 'New' action when a transfer with a closed account is involved (selected when triggering the 'New' action).
Comment 5 Cristian Oneț 2011-05-21 23:39:26 UTC
(In reply to comment #4)
> I can confirm the buggy behavior of the 'New' action when a transfer with a
> closed account is involved (selected when triggering the 'New' action).

Only when the triggering is done via the menu (right click).
Comment 6 Cristian Oneț 2011-05-21 23:42:58 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I can confirm the buggy behavior of the 'New' action when a transfer with a
> > closed account is involved (selected when triggering the 'New' action).
> 
> Only when the triggering is done via the menu (right click).

Actually triggering the 'New' action from the menu or by right clicking works incorrectly in all cases (not just when a closed account is involved).
Comment 7 Cristian Oneț 2011-05-22 16:52:12 UTC
SVN commit 1233105 by conet:

BUG: 270752

This bug was introduced by revision 1207610. Since that code sets the mouse button to Qt::RightButton the selectItem call from KGlobalLedgerView::selectEmptyTransaction would not go trough the normal codepath (marked by the '// we get here when called by application logic' comment) but trough the codepath handling the selection when the right button is pressed. But since that code was not working since the port to KDE4 (already fixed in Register::contextMenuEvent) the last item of the register would not get selected and thus provoking this bug.
Remove the invalid/unused right button handling in selectItem and reset the mouse button and the modifier on right click (Register::contextMenuEvent).

 M  +4 -25     register.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1233105
Comment 8 allan 2011-07-10 21:46:33 UTC
I'm wondering if what I've seen a few times lately might hark back to this bug.

I've been spending a lot of time lately in the investment area, and a few times, when a transaction has been edited, on clicking enter, all the investment widgets disappear, showing just their blank container.

At first, I found that clicking another transaction corrected the display, but I've just noticed that the transaction being edited is the last in the ledger, having been newly created.  It shows as selected, bit the Edit option is not enabled, only New and Delete.  As it is already apparently selected, clicking on that transaction does not help.  However, double clicking corrects the widget display, but does not open the transaction.  Also, Edit still is not available.  Strangely, double clicking it again does now open Edit mode.

Some similarities to the above, so just wondering if there might still be a connection?