Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
Thomas Unless you take the time to try to replicate the problem and create a bug report, the rest of us will quickly forget about it. If we don't see it happening with our data sets we will conclude that yours was a case of operator error. On Fri, Dec 30, 2022, 3:17 PM Thomas Forrester wrote: > I won't actually be experimenting on copies of databases, not because I > don't want to be helpful or contribute to the community, but because I > simply don't have that kind of free time. I've noted a problem, and can > agree that I was doing something rather mindless - i.e., right-clicking and > choosing to delete a transaction multiple times because there were three > identical transactions. That I didn't realize something was going wrong is > somewhat explainable by the fact that, once one (should have been) deleted, > another would have moved up to take its place since they appeared one after > the other, so the row currently being deleted would look just like the > last. When I deleted three, then I came to realize I still had three > left. That realization was followed by the realization that the left side > of the screen was looking a little shorter on transactions than before. > And sure enough, stuff had been deleted from the wrong side. I don't know > why, My purpose here is to get it on the radar of the developers so they > can review the code to see if there's a problem with the selection logic. > And I'm sorry I won't be able to contribute more than that. > > Thanks. > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
I won't actually be experimenting on copies of databases, not because I don't want to be helpful or contribute to the community, but because I simply don't have that kind of free time. I've noted a problem, and can agree that I was doing something rather mindless - i.e., right-clicking and choosing to delete a transaction multiple times because there were three identical transactions. That I didn't realize something was going wrong is somewhat explainable by the fact that, once one (should have been) deleted, another would have moved up to take its place since they appeared one after the other, so the row currently being deleted would look just like the last. When I deleted three, then I came to realize I still had three left. That realization was followed by the realization that the left side of the screen was looking a little shorter on transactions than before. And sure enough, stuff had been deleted from the wrong side. I don't know why, My purpose here is to get it on the radar of the developers so they can review the code to see if there's a problem with the selection logic. And I'm sorry I won't be able to contribute more than that. Thanks. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
Thanks for your opinions and experiences on the method of storage employed. My perceptions on the pros/coms of either storage method notwithstanding, it is not the topic of this discussion. Rather it was just a side note on the complexities or applicability of restoring to get around the fact that the program, for some unknown reason, deleted records that were NOT being explicitly targeted for deletion. Thanks. On Fri, Dec 30, 2022 at 2:24 PM John Layman wrote: > My experience is the same as Geert's. I've seen no performance advantage > when testing XML vs MySQL with my 12 years of data. The initial load from > db is slower than with XML, and flushing and zipping the data at > termination > is reasonably fast. As for immediate commit to the db, I find that > actually to be a negative, since I do find myself resorting to the 'revert' > feature from time to time. Except for the case where someone is actually > querying the database for custom reporting, etc. I can't think of any > advantage to using a database with GnuCash. > > -Original Message- > From: gnucash-user > On Behalf Of Geert Janssens > Sent: Friday, December 30, 2022 10:31 AM > To: David Carlson ; gnucash-user@gnucash.org > Cc: GnuCash List ; Adrien Monteleone > > Subject: Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong > Transaction > > Op vrijdag 30 december 2022 15:47:35 CET schreef Thomas Forrester: > (snip) > > I use database storage over the XML storage method because it does > > afford me opportunities that the XML plain text file does not. I now > > have data going back seven years in GnuCash and I think that's too > > much to push on a text file. At some point the scales tip in favor of > > a full-fledged database over text file read/write operations. > > I haven't followed the rest of this thread, but this paragraph caught my > eye... > > The way gnucash works the storage method hardly has any impact on > performance. In all cases the whole data set is loaded completely into > memory when the data set is opened (be it an xml file or a database > backend). And all work is performed purely in memory. > > The major difference is that with a database backend, any change you make > is > immediately written to the db right after the model in memory has been > altered. With the xml backend, changes are written to the xml file only on > explicit save, or at the autosave interval (if set). > > So the load and save experiences may be slightly different (last time I was > involved in this the initial db load was slower than the xml load, but > saving to xml takes more time as it has to write everything at once, yet > that is not done as frequently as saving each atomic change to db > directly...) > > But for both the db or xml storage, after the initial read, the data is > never read again from the storage and gnucash will only work with what's in > memory. > > Regards, > > Geert > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
My experience is the same as Geert's. I've seen no performance advantage when testing XML vs MySQL with my 12 years of data. The initial load from db is slower than with XML, and flushing and zipping the data at termination is reasonably fast. As for immediate commit to the db, I find that actually to be a negative, since I do find myself resorting to the 'revert' feature from time to time. Except for the case where someone is actually querying the database for custom reporting, etc. I can't think of any advantage to using a database with GnuCash. -Original Message- From: gnucash-user On Behalf Of Geert Janssens Sent: Friday, December 30, 2022 10:31 AM To: David Carlson ; gnucash-user@gnucash.org Cc: GnuCash List ; Adrien Monteleone Subject: Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction Op vrijdag 30 december 2022 15:47:35 CET schreef Thomas Forrester: (snip) > I use database storage over the XML storage method because it does > afford me opportunities that the XML plain text file does not. I now > have data going back seven years in GnuCash and I think that's too > much to push on a text file. At some point the scales tip in favor of > a full-fledged database over text file read/write operations. I haven't followed the rest of this thread, but this paragraph caught my eye... The way gnucash works the storage method hardly has any impact on performance. In all cases the whole data set is loaded completely into memory when the data set is opened (be it an xml file or a database backend). And all work is performed purely in memory. The major difference is that with a database backend, any change you make is immediately written to the db right after the model in memory has been altered. With the xml backend, changes are written to the xml file only on explicit save, or at the autosave interval (if set). So the load and save experiences may be slightly different (last time I was involved in this the initial db load was slower than the xml load, but saving to xml takes more time as it has to write everything at once, yet that is not done as frequently as saving each atomic change to db directly...) But for both the db or xml storage, after the initial read, the data is never read again from the storage and gnucash will only work with what's in memory. Regards, Geert ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
The "wonkiness on the Mac" was indeed limited to Macs. That doesn't mean that Windows can't also develop wonkiness, but I don't maintain Gtk's Windows backend nor do I know much about how it works so unlike the Mac backend I can't fix it. Your description of the problem doesn't match the macOS wonkiness anyway. That was about focus going to the wrong window, not window actions getting applied to the wrong tree view in a window. For testing you can use File>Save As to create a SQLite3 version of your book, saved as a file on your local disk, then make a copy of that and work on the copy. That makes it easy to reset for another test attempt. With that in place can you reproduce the bug at will? If so is the transaction that actually gets deleted the same every time? Is there a positional relationship, either in the reconcile window or the register, between the transaction you want to delete and the one that gets deleted? Regards, John Ralls > On Dec 30, 2022, at 6:55 AM, Thomas Forrester wrote: > > Ah. I reported the version [GnuCash 4.11 Build ID: 4.11+(2022-06-25) using > a MariaDB backend], but totally forgot to mention I'm running on Windows 11. > > Hopefully the "wonkiness" seen on the Mac isn't present in Windows? > > Or hopefully it's gone on all platforms in 4.13, as you've suggested, which > I installed yesterday to get current. > > On Fri, Dec 30, 2022 at 1:38 AM David H wrote: > >> I'm sure he read what you wrote and assumed you were running Gnucash 4.12 >> on MacOS Ventura :-) If not please advise OS and Gnucash version. >> >> If that is indeed the case check out >> https://lists.gnucash.org/pipermail/gnucash-user/2022-November/103465.html >> and https://gitlab.gnome.org/GNOME/gtk/-/issues/5305#note_1592320 for all >> the gory details. Basically popups passed the mouse clicks etc through to >> the underlying register. Fixed in 4.13 thanks goodness. >> >> Regards David H. >> >> >> >> On Fri, 30 Dec 2022 at 13:47, Thomas Forrester >> wrote: >> >>> I guess you didn't read what I wrote. So, let me say it again (via the >>> magic of copy/paste): >>> >>> "I was right-clicking on a transaction in the right (credit) column. It >>> was already highlighted, and there was no other transaction highlighted. >>> The right-click context menu appeared alongside the mouse pointer which >>> was >>> positioned on the highlighted credit transaction. From that menu I >>> selected and confirmed the delete of the highlighted credit transaction. >>> A >>> debit transaction was deleted instead." >>> >>> Reverting to a backup after doing as much work as I had leading up to that >>> reconciliation in that session would have been a multitude of times more >>> painful. Bad stuff always happens after lots of other stuff has happened >>> - >>> Murphy's Law. The backup is for truly catastrophic stuff, or maybe if >>> you're just lucky and haven't done anything else yet. >>> >>> This is hardly and interface error. And checking the 4.13 change log >>> reveals nothing addressing this or any related reconciliation bug. The >>> known issues list doesn't even identify it. I don't think it's on >>> anyone's >>> radar. >>> >>> On Thu, Dec 29, 2022 at 4:28 PM Adrien Monteleone < >>> adrien.montele...@lusfiber.net> wrote: >>> That sounds like a GTK bug. You were raising a context menu on what was selected, not where the mouse pointer was located. If you had a line in the left pane selected, that is what got deleted. Maybe reverting to a backup file and making it your main file would be in order for restoring your books to a sane state then starting the reconciliation over. As for the bug, I suppose you can file it, but I wouldn't be surprised if it is a GTK rather than GnuCash problem. But before you do, try GnuCash 4.13 first. I think the GTK version was just bumped on that release. Regards, Adrien On 12/29/22 3:36 PM, Thomas Forrester wrote: > I was reconciling several credit card statements for the same card and had > noticed that a subscription payment I had set up as an automatic entry was > showing up even though I had canceled the subscription. Clearly, I hadn't > discontinued the automatic transaction entry in GnuCash. I ignored several > of the subscription transactions while reconciling, but then I >>> thought I > might as well just delete them in the Reconcile screen since you can > right-click and delete transactions right there. With the first ot 3 >>> of > the transactions highlighted, I right-clicked on it and selected delete. I > clicked OK to the confirmation message affirming I was sure I wanted >>> to > delete the transaction. I rather mindlessly repeated that action a >>> couple > of times, then realized the transactions weren't deleting. Much to my > horror, I realized transactions on the left (debit)
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
Op vrijdag 30 december 2022 15:47:35 CET schreef Thomas Forrester: (snip) > I use database storage over the XML storage method because it does afford > me opportunities that the XML plain text file does not. I now have data > going back seven years in GnuCash and I think that's too much to push on a > text file. At some point the scales tip in favor of a > full-fledged database over text file read/write operations. I haven't followed the rest of this thread, but this paragraph caught my eye... The way gnucash works the storage method hardly has any impact on performance. In all cases the whole data set is loaded completely into memory when the data set is opened (be it an xml file or a database backend). And all work is performed purely in memory. The major difference is that with a database backend, any change you make is immediately written to the db right after the model in memory has been altered. With the xml backend, changes are written to the xml file only on explicit save, or at the autosave interval (if set). So the load and save experiences may be slightly different (last time I was involved in this the initial db load was slower than the xml load, but saving to xml takes more time as it has to write everything at once, yet that is not done as frequently as saving each atomic change to db directly...) But for both the db or xml storage, after the initial read, the data is never read again from the storage and gnucash will only work with what's in memory. Regards, Geert ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
Ah. I reported the version [GnuCash 4.11 Build ID: 4.11+(2022-06-25) using a MariaDB backend], but totally forgot to mention I'm running on Windows 11. Hopefully the "wonkiness" seen on the Mac isn't present in Windows? Or hopefully it's gone on all platforms in 4.13, as you've suggested, which I installed yesterday to get current. On Fri, Dec 30, 2022 at 1:38 AM David H wrote: > I'm sure he read what you wrote and assumed you were running Gnucash 4.12 > on MacOS Ventura :-) If not please advise OS and Gnucash version. > > If that is indeed the case check out > https://lists.gnucash.org/pipermail/gnucash-user/2022-November/103465.html > and https://gitlab.gnome.org/GNOME/gtk/-/issues/5305#note_1592320 for all > the gory details. Basically popups passed the mouse clicks etc through to > the underlying register. Fixed in 4.13 thanks goodness. > > Regards David H. > > > > On Fri, 30 Dec 2022 at 13:47, Thomas Forrester > wrote: > >> I guess you didn't read what I wrote. So, let me say it again (via the >> magic of copy/paste): >> >> "I was right-clicking on a transaction in the right (credit) column. It >> was already highlighted, and there was no other transaction highlighted. >> The right-click context menu appeared alongside the mouse pointer which >> was >> positioned on the highlighted credit transaction. From that menu I >> selected and confirmed the delete of the highlighted credit transaction. >> A >> debit transaction was deleted instead." >> >> Reverting to a backup after doing as much work as I had leading up to that >> reconciliation in that session would have been a multitude of times more >> painful. Bad stuff always happens after lots of other stuff has happened >> - >> Murphy's Law. The backup is for truly catastrophic stuff, or maybe if >> you're just lucky and haven't done anything else yet. >> >> This is hardly and interface error. And checking the 4.13 change log >> reveals nothing addressing this or any related reconciliation bug. The >> known issues list doesn't even identify it. I don't think it's on >> anyone's >> radar. >> >> On Thu, Dec 29, 2022 at 4:28 PM Adrien Monteleone < >> adrien.montele...@lusfiber.net> wrote: >> >> > That sounds like a GTK bug. You were raising a context menu on what was >> > selected, not where the mouse pointer was located. If you had a line in >> > the left pane selected, that is what got deleted. >> > >> > Maybe reverting to a backup file and making it your main file would be >> > in order for restoring your books to a sane state then starting the >> > reconciliation over. >> > >> > As for the bug, I suppose you can file it, but I wouldn't be surprised >> > if it is a GTK rather than GnuCash problem. >> > >> > But before you do, try GnuCash 4.13 first. I think the GTK version was >> > just bumped on that release. >> > >> > Regards, >> > Adrien >> > >> > On 12/29/22 3:36 PM, Thomas Forrester wrote: >> > > I was reconciling several credit card statements for the same card and >> > had >> > > noticed that a subscription payment I had set up as an automatic entry >> > was >> > > showing up even though I had canceled the subscription. Clearly, I >> > hadn't >> > > discontinued the automatic transaction entry in GnuCash. I ignored >> > several >> > > of the subscription transactions while reconciling, but then I >> thought I >> > > might as well just delete them in the Reconcile screen since you can >> > > right-click and delete transactions right there. With the first ot 3 >> of >> > > the transactions highlighted, I right-clicked on it and selected >> > delete. I >> > > clicked OK to the confirmation message affirming I was sure I wanted >> to >> > > delete the transaction. I rather mindlessly repeated that action a >> couple >> > > of times, then realized the transactions weren't deleting. Much to my >> > > horror, I realized transactions on the left (debit) column for the >> > > reconciliation was getting shorter, not the right (credit) column >> where >> > the >> > > highlighted item I was trying to delete was. >> > > >> > > Again, I'm going to stress this: I was right-clicking on a >> transaction in >> > > the right (credit) column. It was already highlighted, and there was >> no >> > > other transaction highlighted. The right-click context menu appeared >> > > alongside the mouse pointer which was positioned on the highlighted >> > credit >> > > transaction. From that menu I selected and confirmed the delete of >> the >> > > highlighted credit transaction. A debit transaction was deleted >> instead. >> > > >> > > Obviously, this is not correct behavior. >> > > >> > > This is GnuCash 4.11 Build ID: 4.11+(2022-06-25) using a MariaDB >> backend. >> > >> > ___ >> > gnucash-user mailing list >> > gnucash-user@gnucash.org >> > To update your subscription preferences or to unsubscribe: >> > https://lists.gnucash.org/mailman/listinfo/gnucash-user >> > - >> > Please remember to CC this list
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
It is possible that a specific set of prerequisite conditions need to exist for the bug to manifest, but I don't know exactly what I might have been doing immediately before getting the notion that I should just delete the transactions right from the Reconciliation dialog. Normally, I would delete unwanted transactions directly in the register, too. But the Reconciliation dialog permits two methods of deleting a transaction - right-click-delete, or top toolbar delete button. They gave it some thought and provided a way to do it, and frankly, it's an appropriate and convenient place to provide that capability. Sometimes it's easier to see a rogue transaction in the Reconciliation dialog over the more information dense register. I use database storage over the XML storage method because it does afford me opportunities that the XML plain text file does not. I now have data going back seven years in GnuCash and I think that's too much to push on a text file. At some point the scales tip in favor of a full-fledged database over text file read/write operations. But you're right, backing up is not integrated into GnuCash at the push of a button. I have to perform backups using the HeidiSQL application, and even then it's not very intuitive. My bad for not backing up before transitioning from working with transactions to reconciling statements. Yup. That's on me. But GnuCash rarely lets me down, so I get complacent sometimes, I guess. On Fri, Dec 30, 2022 at 12:36 AM David Carlson wrote: > I just performed a trivial test in release 4.8 (Build ID: > 4.8a+(2021-09-28) in Lubuntu 22.04 by adding a bogus transaction to a > register then saving the file, opening the reconciliation window, right > clicking the desired split in the right panel of the reconciliation window, > and clicking delete. The correct entire transaction was deleted. So, from > my perspective, if the current release does not work the same way, there > has been a regression since 4.8. > > On Thu, Dec 29, 2022 at 11:08 PM David Carlson < > david.carlson@gmail.com> wrote: > >> I haven't needed to do a reconciliation yet since this thread started, >> but perhaps in the next few days. >> >> In the meantime, I didn't even realize that you could right click split >> lines in that screen and do things. If that works successfully, wonderful. >> >> I have always used the menu to navigate to the transaction in the >> register view and perform my edits there. >> >> Finally, I subscribe to the theory to save a backup just before >> starting any significant activity such as a reconciliation or import. That >> is one reason I am not using a database file format and I won't until the >> application has a way to undo several recent actions. My cat does >> occasionally walk across the keyboard. >> >> On Thu, Dec 29, 2022, 9:47 PM Thomas Forrester >> wrote: >> >>> I guess you didn't read what I wrote. So, let me say it again (via the >>> magic of copy/paste): >>> >>> "I was right-clicking on a transaction in the right (credit) column. It >>> was already highlighted, and there was no other transaction highlighted. >>> The right-click context menu appeared alongside the mouse pointer which >>> was >>> positioned on the highlighted credit transaction. From that menu I >>> selected and confirmed the delete of the highlighted credit >>> transaction. A >>> debit transaction was deleted instead." >>> >>> Reverting to a backup after doing as much work as I had leading up to >>> that >>> reconciliation in that session would have been a multitude of times more >>> painful. Bad stuff always happens after lots of other stuff has >>> happened - >>> Murphy's Law. The backup is for truly catastrophic stuff, or maybe if >>> you're just lucky and haven't done anything else yet. >>> >>> This is hardly and interface error. And checking the 4.13 change log >>> reveals nothing addressing this or any related reconciliation bug. The >>> known issues list doesn't even identify it. I don't think it's on >>> anyone's >>> radar. >>> >>> On Thu, Dec 29, 2022 at 4:28 PM Adrien Monteleone < >>> adrien.montele...@lusfiber.net> wrote: >>> >>> > That sounds like a GTK bug. You were raising a context menu on what was >>> > selected, not where the mouse pointer was located. If you had a line in >>> > the left pane selected, that is what got deleted. >>> > >>> > Maybe reverting to a backup file and making it your main file would be >>> > in order for restoring your books to a sane state then starting the >>> > reconciliation over. >>> > >>> > As for the bug, I suppose you can file it, but I wouldn't be surprised >>> > if it is a GTK rather than GnuCash problem. >>> > >>> > But before you do, try GnuCash 4.13 first. I think the GTK version was >>> > just bumped on that release. >>> > >>> > Regards, >>> > Adrien >>> > >>> > On 12/29/22 3:36 PM, Thomas Forrester wrote: >>> > > I was reconciling several credit card statements for the same card >>> and >>> > had >>> > > no
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
I'm sure he read what you wrote and assumed you were running Gnucash 4.12 on MacOS Ventura :-) If not please advise OS and Gnucash version. If that is indeed the case check out https://lists.gnucash.org/pipermail/gnucash-user/2022-November/103465.html and https://gitlab.gnome.org/GNOME/gtk/-/issues/5305#note_1592320 for all the gory details. Basically popups passed the mouse clicks etc through to the underlying register. Fixed in 4.13 thanks goodness. Regards David H. On Fri, 30 Dec 2022 at 13:47, Thomas Forrester wrote: > I guess you didn't read what I wrote. So, let me say it again (via the > magic of copy/paste): > > "I was right-clicking on a transaction in the right (credit) column. It > was already highlighted, and there was no other transaction highlighted. > The right-click context menu appeared alongside the mouse pointer which was > positioned on the highlighted credit transaction. From that menu I > selected and confirmed the delete of the highlighted credit transaction. A > debit transaction was deleted instead." > > Reverting to a backup after doing as much work as I had leading up to that > reconciliation in that session would have been a multitude of times more > painful. Bad stuff always happens after lots of other stuff has happened - > Murphy's Law. The backup is for truly catastrophic stuff, or maybe if > you're just lucky and haven't done anything else yet. > > This is hardly and interface error. And checking the 4.13 change log > reveals nothing addressing this or any related reconciliation bug. The > known issues list doesn't even identify it. I don't think it's on anyone's > radar. > > On Thu, Dec 29, 2022 at 4:28 PM Adrien Monteleone < > adrien.montele...@lusfiber.net> wrote: > > > That sounds like a GTK bug. You were raising a context menu on what was > > selected, not where the mouse pointer was located. If you had a line in > > the left pane selected, that is what got deleted. > > > > Maybe reverting to a backup file and making it your main file would be > > in order for restoring your books to a sane state then starting the > > reconciliation over. > > > > As for the bug, I suppose you can file it, but I wouldn't be surprised > > if it is a GTK rather than GnuCash problem. > > > > But before you do, try GnuCash 4.13 first. I think the GTK version was > > just bumped on that release. > > > > Regards, > > Adrien > > > > On 12/29/22 3:36 PM, Thomas Forrester wrote: > > > I was reconciling several credit card statements for the same card and > > had > > > noticed that a subscription payment I had set up as an automatic entry > > was > > > showing up even though I had canceled the subscription. Clearly, I > > hadn't > > > discontinued the automatic transaction entry in GnuCash. I ignored > > several > > > of the subscription transactions while reconciling, but then I thought > I > > > might as well just delete them in the Reconcile screen since you can > > > right-click and delete transactions right there. With the first ot 3 > of > > > the transactions highlighted, I right-clicked on it and selected > > delete. I > > > clicked OK to the confirmation message affirming I was sure I wanted to > > > delete the transaction. I rather mindlessly repeated that action a > couple > > > of times, then realized the transactions weren't deleting. Much to my > > > horror, I realized transactions on the left (debit) column for the > > > reconciliation was getting shorter, not the right (credit) column where > > the > > > highlighted item I was trying to delete was. > > > > > > Again, I'm going to stress this: I was right-clicking on a transaction > in > > > the right (credit) column. It was already highlighted, and there was > no > > > other transaction highlighted. The right-click context menu appeared > > > alongside the mouse pointer which was positioned on the highlighted > > credit > > > transaction. From that menu I selected and confirmed the delete of the > > > highlighted credit transaction. A debit transaction was deleted > instead. > > > > > > Obviously, this is not correct behavior. > > > > > > This is GnuCash 4.11 Build ID: 4.11+(2022-06-25) using a MariaDB > backend. > > > > ___ > > gnucash-user mailing list > > gnucash-user@gnucash.org > > To update your subscription preferences or to unsubscribe: > > https://lists.gnucash.org/mailman/listinfo/gnucash-user > > - > > Please remember to CC this list on all your replies. > > You can do this by using Reply-To-List or Reply-All. > > > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > ___ gnucash-user mailing list gnucash-user@gnucash.
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
I just performed a trivial test in release 4.8 (Build ID: 4.8a+(2021-09-28) in Lubuntu 22.04 by adding a bogus transaction to a register then saving the file, opening the reconciliation window, right clicking the desired split in the right panel of the reconciliation window, and clicking delete. The correct entire transaction was deleted. So, from my perspective, if the current release does not work the same way, there has been a regression since 4.8. On Thu, Dec 29, 2022 at 11:08 PM David Carlson wrote: > I haven't needed to do a reconciliation yet since this thread started, but > perhaps in the next few days. > > In the meantime, I didn't even realize that you could right click split > lines in that screen and do things. If that works successfully, wonderful. > > I have always used the menu to navigate to the transaction in the register > view and perform my edits there. > > Finally, I subscribe to the theory to save a backup just before starting > any significant activity such as a reconciliation or import. That is one > reason I am not using a database file format and I won't until the > application has a way to undo several recent actions. My cat does > occasionally walk across the keyboard. > > On Thu, Dec 29, 2022, 9:47 PM Thomas Forrester > wrote: > >> I guess you didn't read what I wrote. So, let me say it again (via the >> magic of copy/paste): >> >> "I was right-clicking on a transaction in the right (credit) column. It >> was already highlighted, and there was no other transaction highlighted. >> The right-click context menu appeared alongside the mouse pointer which >> was >> positioned on the highlighted credit transaction. From that menu I >> selected and confirmed the delete of the highlighted credit transaction. >> A >> debit transaction was deleted instead." >> >> Reverting to a backup after doing as much work as I had leading up to that >> reconciliation in that session would have been a multitude of times more >> painful. Bad stuff always happens after lots of other stuff has happened >> - >> Murphy's Law. The backup is for truly catastrophic stuff, or maybe if >> you're just lucky and haven't done anything else yet. >> >> This is hardly and interface error. And checking the 4.13 change log >> reveals nothing addressing this or any related reconciliation bug. The >> known issues list doesn't even identify it. I don't think it's on >> anyone's >> radar. >> >> On Thu, Dec 29, 2022 at 4:28 PM Adrien Monteleone < >> adrien.montele...@lusfiber.net> wrote: >> >> > That sounds like a GTK bug. You were raising a context menu on what was >> > selected, not where the mouse pointer was located. If you had a line in >> > the left pane selected, that is what got deleted. >> > >> > Maybe reverting to a backup file and making it your main file would be >> > in order for restoring your books to a sane state then starting the >> > reconciliation over. >> > >> > As for the bug, I suppose you can file it, but I wouldn't be surprised >> > if it is a GTK rather than GnuCash problem. >> > >> > But before you do, try GnuCash 4.13 first. I think the GTK version was >> > just bumped on that release. >> > >> > Regards, >> > Adrien >> > >> > On 12/29/22 3:36 PM, Thomas Forrester wrote: >> > > I was reconciling several credit card statements for the same card and >> > had >> > > noticed that a subscription payment I had set up as an automatic entry >> > was >> > > showing up even though I had canceled the subscription. Clearly, I >> > hadn't >> > > discontinued the automatic transaction entry in GnuCash. I ignored >> > several >> > > of the subscription transactions while reconciling, but then I >> thought I >> > > might as well just delete them in the Reconcile screen since you can >> > > right-click and delete transactions right there. With the first ot 3 >> of >> > > the transactions highlighted, I right-clicked on it and selected >> > delete. I >> > > clicked OK to the confirmation message affirming I was sure I wanted >> to >> > > delete the transaction. I rather mindlessly repeated that action a >> couple >> > > of times, then realized the transactions weren't deleting. Much to my >> > > horror, I realized transactions on the left (debit) column for the >> > > reconciliation was getting shorter, not the right (credit) column >> where >> > the >> > > highlighted item I was trying to delete was. >> > > >> > > Again, I'm going to stress this: I was right-clicking on a >> transaction in >> > > the right (credit) column. It was already highlighted, and there was >> no >> > > other transaction highlighted. The right-click context menu appeared >> > > alongside the mouse pointer which was positioned on the highlighted >> > credit >> > > transaction. From that menu I selected and confirmed the delete of >> the >> > > highlighted credit transaction. A debit transaction was deleted >> instead. >> > > >> > > Obviously, this is not correct behavior. >> > > >> > > This is GnuCash 4.11 Build ID
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
I haven't needed to do a reconciliation yet since this thread started, but perhaps in the next few days. In the meantime, I didn't even realize that you could right click split lines in that screen and do things. If that works successfully, wonderful. I have always used the menu to navigate to the transaction in the register view and perform my edits there. Finally, I subscribe to the theory to save a backup just before starting any significant activity such as a reconciliation or import. That is one reason I am not using a database file format and I won't until the application has a way to undo several recent actions. My cat does occasionally walk across the keyboard. On Thu, Dec 29, 2022, 9:47 PM Thomas Forrester wrote: > I guess you didn't read what I wrote. So, let me say it again (via the > magic of copy/paste): > > "I was right-clicking on a transaction in the right (credit) column. It > was already highlighted, and there was no other transaction highlighted. > The right-click context menu appeared alongside the mouse pointer which was > positioned on the highlighted credit transaction. From that menu I > selected and confirmed the delete of the highlighted credit transaction. A > debit transaction was deleted instead." > > Reverting to a backup after doing as much work as I had leading up to that > reconciliation in that session would have been a multitude of times more > painful. Bad stuff always happens after lots of other stuff has happened - > Murphy's Law. The backup is for truly catastrophic stuff, or maybe if > you're just lucky and haven't done anything else yet. > > This is hardly and interface error. And checking the 4.13 change log > reveals nothing addressing this or any related reconciliation bug. The > known issues list doesn't even identify it. I don't think it's on anyone's > radar. > > On Thu, Dec 29, 2022 at 4:28 PM Adrien Monteleone < > adrien.montele...@lusfiber.net> wrote: > > > That sounds like a GTK bug. You were raising a context menu on what was > > selected, not where the mouse pointer was located. If you had a line in > > the left pane selected, that is what got deleted. > > > > Maybe reverting to a backup file and making it your main file would be > > in order for restoring your books to a sane state then starting the > > reconciliation over. > > > > As for the bug, I suppose you can file it, but I wouldn't be surprised > > if it is a GTK rather than GnuCash problem. > > > > But before you do, try GnuCash 4.13 first. I think the GTK version was > > just bumped on that release. > > > > Regards, > > Adrien > > > > On 12/29/22 3:36 PM, Thomas Forrester wrote: > > > I was reconciling several credit card statements for the same card and > > had > > > noticed that a subscription payment I had set up as an automatic entry > > was > > > showing up even though I had canceled the subscription. Clearly, I > > hadn't > > > discontinued the automatic transaction entry in GnuCash. I ignored > > several > > > of the subscription transactions while reconciling, but then I thought > I > > > might as well just delete them in the Reconcile screen since you can > > > right-click and delete transactions right there. With the first ot 3 > of > > > the transactions highlighted, I right-clicked on it and selected > > delete. I > > > clicked OK to the confirmation message affirming I was sure I wanted to > > > delete the transaction. I rather mindlessly repeated that action a > couple > > > of times, then realized the transactions weren't deleting. Much to my > > > horror, I realized transactions on the left (debit) column for the > > > reconciliation was getting shorter, not the right (credit) column where > > the > > > highlighted item I was trying to delete was. > > > > > > Again, I'm going to stress this: I was right-clicking on a transaction > in > > > the right (credit) column. It was already highlighted, and there was > no > > > other transaction highlighted. The right-click context menu appeared > > > alongside the mouse pointer which was positioned on the highlighted > > credit > > > transaction. From that menu I selected and confirmed the delete of the > > > highlighted credit transaction. A debit transaction was deleted > instead. > > > > > > Obviously, this is not correct behavior. > > > > > > This is GnuCash 4.11 Build ID: 4.11+(2022-06-25) using a MariaDB > backend. > > > > ___ > > gnucash-user mailing list > > gnucash-user@gnucash.org > > To update your subscription preferences or to unsubscribe: > > https://lists.gnucash.org/mailman/listinfo/gnucash-user > > - > > Please remember to CC this list on all your replies. > > You can do this by using Reply-To-List or Reply-All. > > > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - >
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
I guess you didn't read what I wrote. So, let me say it again (via the magic of copy/paste): "I was right-clicking on a transaction in the right (credit) column. It was already highlighted, and there was no other transaction highlighted. The right-click context menu appeared alongside the mouse pointer which was positioned on the highlighted credit transaction. From that menu I selected and confirmed the delete of the highlighted credit transaction. A debit transaction was deleted instead." Reverting to a backup after doing as much work as I had leading up to that reconciliation in that session would have been a multitude of times more painful. Bad stuff always happens after lots of other stuff has happened - Murphy's Law. The backup is for truly catastrophic stuff, or maybe if you're just lucky and haven't done anything else yet. This is hardly and interface error. And checking the 4.13 change log reveals nothing addressing this or any related reconciliation bug. The known issues list doesn't even identify it. I don't think it's on anyone's radar. On Thu, Dec 29, 2022 at 4:28 PM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > That sounds like a GTK bug. You were raising a context menu on what was > selected, not where the mouse pointer was located. If you had a line in > the left pane selected, that is what got deleted. > > Maybe reverting to a backup file and making it your main file would be > in order for restoring your books to a sane state then starting the > reconciliation over. > > As for the bug, I suppose you can file it, but I wouldn't be surprised > if it is a GTK rather than GnuCash problem. > > But before you do, try GnuCash 4.13 first. I think the GTK version was > just bumped on that release. > > Regards, > Adrien > > On 12/29/22 3:36 PM, Thomas Forrester wrote: > > I was reconciling several credit card statements for the same card and > had > > noticed that a subscription payment I had set up as an automatic entry > was > > showing up even though I had canceled the subscription. Clearly, I > hadn't > > discontinued the automatic transaction entry in GnuCash. I ignored > several > > of the subscription transactions while reconciling, but then I thought I > > might as well just delete them in the Reconcile screen since you can > > right-click and delete transactions right there. With the first ot 3 of > > the transactions highlighted, I right-clicked on it and selected > delete. I > > clicked OK to the confirmation message affirming I was sure I wanted to > > delete the transaction. I rather mindlessly repeated that action a couple > > of times, then realized the transactions weren't deleting. Much to my > > horror, I realized transactions on the left (debit) column for the > > reconciliation was getting shorter, not the right (credit) column where > the > > highlighted item I was trying to delete was. > > > > Again, I'm going to stress this: I was right-clicking on a transaction in > > the right (credit) column. It was already highlighted, and there was no > > other transaction highlighted. The right-click context menu appeared > > alongside the mouse pointer which was positioned on the highlighted > credit > > transaction. From that menu I selected and confirmed the delete of the > > highlighted credit transaction. A debit transaction was deleted instead. > > > > Obviously, this is not correct behavior. > > > > This is GnuCash 4.11 Build ID: 4.11+(2022-06-25) using a MariaDB backend. > > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Deleting Transaction from Reconcile Deletes Wrong Transaction
That sounds like a GTK bug. You were raising a context menu on what was selected, not where the mouse pointer was located. If you had a line in the left pane selected, that is what got deleted. Maybe reverting to a backup file and making it your main file would be in order for restoring your books to a sane state then starting the reconciliation over. As for the bug, I suppose you can file it, but I wouldn't be surprised if it is a GTK rather than GnuCash problem. But before you do, try GnuCash 4.13 first. I think the GTK version was just bumped on that release. Regards, Adrien On 12/29/22 3:36 PM, Thomas Forrester wrote: I was reconciling several credit card statements for the same card and had noticed that a subscription payment I had set up as an automatic entry was showing up even though I had canceled the subscription. Clearly, I hadn't discontinued the automatic transaction entry in GnuCash. I ignored several of the subscription transactions while reconciling, but then I thought I might as well just delete them in the Reconcile screen since you can right-click and delete transactions right there. With the first ot 3 of the transactions highlighted, I right-clicked on it and selected delete. I clicked OK to the confirmation message affirming I was sure I wanted to delete the transaction. I rather mindlessly repeated that action a couple of times, then realized the transactions weren't deleting. Much to my horror, I realized transactions on the left (debit) column for the reconciliation was getting shorter, not the right (credit) column where the highlighted item I was trying to delete was. Again, I'm going to stress this: I was right-clicking on a transaction in the right (credit) column. It was already highlighted, and there was no other transaction highlighted. The right-click context menu appeared alongside the mouse pointer which was positioned on the highlighted credit transaction. From that menu I selected and confirmed the delete of the highlighted credit transaction. A debit transaction was deleted instead. Obviously, this is not correct behavior. This is GnuCash 4.11 Build ID: 4.11+(2022-06-25) using a MariaDB backend. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
