[Kmymoney-devel] [kmymoney4] [Bug 317063] New: crashed entering data
https://bugs.kde.org/show_bug.cgi?id=317063 Bug ID: 317063 Summary: crashed entering data Classification: Unclassified Product: kmymoney4 Version: 4.6.3 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: douglas_pe...@yahoo.com Application: kmymoney (4.6.3) KDE Platform Version: 4.9.4 Qt Version: 4.8.3 Operating System: Linux 3.5.0-25-generic x86_64 Distribution: Ubuntu 12.10 -- Information about the crash: I was entering data into my account. The screen went blank and an error message appeared. -- Backtrace: Application: KMyMoney (kmymoney), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fc94341d780 (LWP 3271))] Thread 2 (Thread 0x7fc9292f4700 (LWP 3275)): #0 0x7fc93d940303 in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fc93901bd84 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fc93901c1e2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fc930ca34a6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x7fc93903f645 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fc940605e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x7fc93d94bcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x in ?? () Thread 1 (Thread 0x7fc94341d780 (LWP 3271)): [KCrash Handler] #5 0x7fc93e6368ce in QWidget::testAttribute_helper (this=this@entry=0x34b3950, attribute=attribute@entry=Qt::WA_WState_Created) at kernel/qwidget.cpp:11043 #6 0x7fc93e63770a in testAttribute (attribute=Qt::WA_WState_Created, this=0x34b3950) at ../../include/QtGui/../../src/gui/kernel/qwidget.h:1042 #7 QWidget::effectiveWinId (this=0x34b3950) at kernel/qwidget.cpp:2619 #8 0x7fc93eba5e3d in QXIMInputContext::reset (this=0x410ef90) at inputmethod/qximinputcontext_x11.cpp:579 #9 0x7fc93eba7924 in QXIMInputContext::setFocusWidget (this=0x410ef90, w=0x0) at inputmethod/qximinputcontext_x11.cpp:649 #10 0x7fc93eba702f in QXIMInputContext::close_xim (this=this@entry=0x410ef90) at inputmethod/qximinputcontext_x11.cpp:533 #11 0x7fc93eba7120 in QXIMInputContext::~QXIMInputContext (this=0x410ef90, __in_chrg=) at inputmethod/qximinputcontext_x11.cpp:542 #12 0x7fc93eba71c9 in QXIMInputContext::~QXIMInputContext (this=0x410ef90, __in_chrg=) at inputmethod/qximinputcontext_x11.cpp:545 #13 0x7fc93f4de182 in QObjectPrivate::deleteChildren (this=0x34b40d0) at kernel/qobject.cpp:1908 #14 0x7fc93e641c24 in QWidget::~QWidget (this=0x50a0150, __in_chrg=) at kernel/qwidget.cpp:1677 #15 0x006dce79 in KMyMoneyCategory::~KMyMoneyCategory (this=0x50a0150, __in_chrg=) at /build/buildd/kmymoney-4.6.3/kmymoney/widgets/kmymoneycategory.cpp:106 #16 0x7fc93f4de182 in QObjectPrivate::deleteChildren (this=0x508cd70) at kernel/qobject.cpp:1908 #17 0x7fc93e641c24 in QWidget::~QWidget (this=0x3441030, __in_chrg=) at kernel/qwidget.cpp:1677 #18 0x7fc93e9f64e9 in QFrame::~QFrame (this=0x3441030, __in_chrg=) at widgets/qframe.cpp:242 #19 0x7fc93f4e0468 in QObject::event (this=0x3441030, e=) at kernel/qobject.cpp:1176 #20 0x7fc93e6470da in QWidget::event (this=0x3441030, event=0x43620a0) at kernel/qwidget.cpp:8830 #21 0x7fc93e9f6b66 in QFrame::event (this=0x3441030, e=0x43620a0) at widgets/qframe.cpp:557 #22 0x7fc93e5f7e9c in QApplicationPrivate::notify_helper (this=this@entry=0xc41f90, receiver=receiver@entry=0x3441030, e=e@entry=0x43620a0) at kernel/qapplication.cpp:4562 #23 0x7fc93e5fc30a in QApplication::notify (this=0xc329a0, receiver=0x3441030, e=0x43620a0) at kernel/qapplication.cpp:4423 #24 0x7fc941a761d6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #25 0x7fc93f4cb56e in QCoreApplication::notifyInternal (this=0xc329a0, receiver=receiver@entry=0x3441030, event=event@entry=0x43620a0) at kernel/qcoreapplication.cpp:915 #26 0x7fc93f4cf3f1 in sendEvent (event=0x43620a0, receiver=0x3441030) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #27 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0xc0a1f0) at kernel/qcoreapplication.cpp:1539 #28 0x7fc93f4f9a63 in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236 #29 postEventSourceDispatch (s=0xc3cad0) at kernel/qeventdispatcher_glib.cpp:279 #30 0x7fc93901bab5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #31 0x7fc93901bde8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #32 0x7fc93901bea4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #33 0x7fc93f4f9bf6 in QEventDispatcherGlib::processEvents (this=0xc0bad0, fla
Re: [Kmymoney-devel] Review Request 107714: BUG:311481 - Fix problem in Schedules where the name field may be empty but OK button is enabled. Also, the amount field affects the OK button status.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107714/ --- (Updated March 20, 2013, 12:13 a.m.) Status -- This change has been marked as submitted. Review request for KMymoney. Description --- The problem as originally reported was that in Schedules view, the OK button became enabled even though no schedule name had been entered. It was found that the button became enabled as soon as a payee was entered. It was also found that this happened when an amount was entered. For "payee", line 753 of transactioneditor.cpp has - "connect(payee,SIGNAL(textChanged(QString)),this,SLOT(slotUpdateButtonState()))", and slotUpdateButtonState() has - "emit transactionDataSufficient(isComplete(reason)", and 'This signal is sent out whenever enough data is present to enter the transaction into the ledger.' Similarly, for "amount", at line 826, the same line appears. As neither of these fields is a mandatory one, I believe they should not affect the OK button status. So, as shown in the patch, I have temporarily disabled these lines. I have done numerous tests of schedule creation and editing, and manual entry and editing of transactions without any problem. The same area of code in transactioneditor.cpp has several more of these possibly unneeded lines, although not affecting schedules. For instance, even with these two lines out and with no mandatory fields completed, if a payee is selected and the memo, tag field, next due date or status is edited, the OK button again is enabled wrongly. I don't really see any valid reason for 'slotUpdateButtonState()' to be in this section. What do the wise men think? This addresses bug 311481. http://bugs.kde.org/show_bug.cgi?id=311481 Diffs - kmymoney/dialogs/transactioneditor.cpp 8f6f06b Diff: http://git.reviewboard.kde.org/r/107714/diff/ Testing --- Numerous tests of schedule creation and editing, and manual entry and editing of transactions without any problem. Thanks, Allan Anderson ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Review Request 107714: BUG:311481 - Fix problem in Schedules where the name field may be empty but OK button is enabled. Also, the amount field affects the OK button status.
> On March 20, 2013, 12:05 a.m., Allan Anderson wrote: > > Git commit acb4a9b9b039317ee705600381e5849124322a66 by Allan Anderson. Committed on 06/03/2013 at 23:41. Pushed by allananderson into branch 'master'. Related: bug 107714 On entering a new tag, allow dialog to appear asking if I want to accept the new tag. M +1-0kmymoney/dialogs/keditscheduledlg.cpp M +1-0kmymoney/dialogs/kenterscheduledlg.cpp http://commits.kde.org/kmymoney/acb4a9b9b039317ee705600381e5849124322a66 - Allan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107714/#review29519 --- On Jan. 12, 2013, 12:07 p.m., Allan Anderson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107714/ > --- > > (Updated Jan. 12, 2013, 12:07 p.m.) > > > Review request for KMymoney. > > > Description > --- > > The problem as originally reported was that in Schedules view, the OK button > became enabled even though no schedule name had been entered. > > It was found that the button became enabled as soon as a payee was entered. > It was also found that this happened when an amount was entered. > > For "payee", line 753 of transactioneditor.cpp has - > "connect(payee,SIGNAL(textChanged(QString)),this,SLOT(slotUpdateButtonState()))", > and slotUpdateButtonState() has - > "emit transactionDataSufficient(isComplete(reason)", > and 'This signal is sent out whenever enough data is present to enter the > transaction into the ledger.' > > Similarly, for "amount", at line 826, the same line appears. > > As neither of these fields is a mandatory one, I believe they should not > affect the OK button status. So, as shown in the patch, I have temporarily > disabled these lines. I have done numerous tests of schedule creation and > editing, and manual entry and editing of transactions without any problem. > > The same area of code in transactioneditor.cpp has several more of these > possibly unneeded lines, although not affecting schedules. For instance, > even with these two lines out and with no mandatory fields completed, if a > payee is selected and the memo, tag field, next due date or status is edited, > the OK button again is enabled wrongly. > > I don't really see any valid reason for 'slotUpdateButtonState()' to be in > this section. What do the wise men think? > > > This addresses bug 311481. > http://bugs.kde.org/show_bug.cgi?id=311481 > > > Diffs > - > > kmymoney/dialogs/transactioneditor.cpp 8f6f06b > > Diff: http://git.reviewboard.kde.org/r/107714/diff/ > > > Testing > --- > > Numerous tests of schedule creation and editing, and manual entry and editing > of transactions without any problem. > > > Thanks, > > Allan Anderson > > ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Review Request 107714: BUG:311481 - Fix problem in Schedules where the name field may be empty but OK button is enabled. Also, the amount field affects the OK button status.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107714/#review29519 --- - Allan Anderson On Jan. 12, 2013, 12:07 p.m., Allan Anderson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107714/ > --- > > (Updated Jan. 12, 2013, 12:07 p.m.) > > > Review request for KMymoney. > > > Description > --- > > The problem as originally reported was that in Schedules view, the OK button > became enabled even though no schedule name had been entered. > > It was found that the button became enabled as soon as a payee was entered. > It was also found that this happened when an amount was entered. > > For "payee", line 753 of transactioneditor.cpp has - > "connect(payee,SIGNAL(textChanged(QString)),this,SLOT(slotUpdateButtonState()))", > and slotUpdateButtonState() has - > "emit transactionDataSufficient(isComplete(reason)", > and 'This signal is sent out whenever enough data is present to enter the > transaction into the ledger.' > > Similarly, for "amount", at line 826, the same line appears. > > As neither of these fields is a mandatory one, I believe they should not > affect the OK button status. So, as shown in the patch, I have temporarily > disabled these lines. I have done numerous tests of schedule creation and > editing, and manual entry and editing of transactions without any problem. > > The same area of code in transactioneditor.cpp has several more of these > possibly unneeded lines, although not affecting schedules. For instance, > even with these two lines out and with no mandatory fields completed, if a > payee is selected and the memo, tag field, next due date or status is edited, > the OK button again is enabled wrongly. > > I don't really see any valid reason for 'slotUpdateButtonState()' to be in > this section. What do the wise men think? > > > This addresses bug 311481. > http://bugs.kde.org/show_bug.cgi?id=311481 > > > Diffs > - > > kmymoney/dialogs/transactioneditor.cpp 8f6f06b > > Diff: http://git.reviewboard.kde.org/r/107714/diff/ > > > Testing > --- > > Numerous tests of schedule creation and editing, and manual entry and editing > of transactions without any problem. > > > Thanks, > > Allan Anderson > > ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Reviewboard
On Tue, 19 Mar 2013 21:33:12 +0100 Alvaro Soliverez wrote: > On Tue, Mar 19, 2013 at 9:04 PM, aga wrote: > > > I have a couple of Reviewboard requests that are outstanding - that > > is, in limbo rather than excellent: > > > > https://git.reviewboard.kde.org/r/107714/ from December 14th, > > > This one has a Ship it! on it. Was there a last-minute problem? > > > > > > https://git.reviewboard.kde.org/r/109043/ from Feb 19th. > > > > This one looks ok, but the diff looks a little odd. Can you update to > latest master? Sorry. > > > > > > > In addition, I am getting close to submitting another request, for a > > CSV Exporter plugin. > > > > I know you guys have other lives to lead, but please, is there a > > chance of someone finding time to have a look. I'm getting a bit > > bogged down, keeping track of which version I actually am using. > > Or, is there an alternative? > > > > Many thanks > > > > Allan > > I did say "I'm getting a bit bogged down, keeping track of which version I actually am using." Well, in fact I had committed this last fix - BUG:311481 REVIEW:107714 - Fix problem in Schedules continued. On entering a new tag, allow dialog to appear asking if I want to accept the new tag. (acb4a9b9b039317ee705600381e5849124322a66). However, this failed to update the review. I'll now close it myself. One down, one to go. Good. Allan ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Reviewboard
On Tue, 19 Mar 2013 21:33:12 +0100 Alvaro Soliverez wrote: > On Tue, Mar 19, 2013 at 9:04 PM, aga wrote: > > > I have a couple of Reviewboard requests that are outstanding - that > > is, in limbo rather than excellent: > > > > https://git.reviewboard.kde.org/r/107714/ from December 14th, > > > This one has a Ship it! on it. Was there a last-minute problem? > Hi Alvaro No, it wasn't exactly a last minute problem. I'd produced the patches related to the original problem, but I'd noticed an issue with tags in schedules. There was then some to-ing and fro-ing with Alessandro Russo, he produced another patch and we agreed that I would add that, rather than him raising another Reviewboard request. This is partly fragmented between the Reviewboard and the bug. I put this forward in https://bugs.kde.org/show_bug.cgi?id=311481 comment 14, just two lines. I think the rest has already been OK'd. Allan > > > https://git.reviewboard.kde.org/r/109043/ from Feb 19th. > > > > This one looks ok, but the diff looks a little odd. Can you update to > latest master? Sorry. > > > > > > > In addition, I am getting close to submitting another request, for a > > CSV Exporter plugin. > > > > I know you guys have other lives to lead, but please, is there a > > chance of someone finding time to have a look. I'm getting a bit > > bogged down, keeping track of which version I actually am using. > > Or, is there an alternative? > > > > Many thanks > > > > Allan > > > > > > ___ > > KMyMoney-devel mailing list > > KMyMoney-devel@kde.org > > https://mail.kde.org/mailman/listinfo/kmymoney-devel > > ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Reviewboard
On Tue, Mar 19, 2013 at 9:04 PM, aga wrote: > I have a couple of Reviewboard requests that are outstanding - that is, > in limbo rather than excellent: > > https://git.reviewboard.kde.org/r/107714/ from December 14th, > This one has a Ship it! on it. Was there a last-minute problem? > https://git.reviewboard.kde.org/r/109043/ from Feb 19th. > This one looks ok, but the diff looks a little odd. Can you update to latest master? Sorry. > > In addition, I am getting close to submitting another request, for a > CSV Exporter plugin. > > I know you guys have other lives to lead, but please, is there a chance > of someone finding time to have a look. I'm getting a bit bogged down, > keeping track of which version I actually am using. Or, is there an > alternative? > > Many thanks > > Allan > > > ___ > KMyMoney-devel mailing list > KMyMoney-devel@kde.org > https://mail.kde.org/mailman/listinfo/kmymoney-devel > ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
[Kmymoney-devel] Reviewboard
I have a couple of Reviewboard requests that are outstanding - that is, in limbo rather than excellent: https://git.reviewboard.kde.org/r/107714/ from December 14th, https://git.reviewboard.kde.org/r/109043/ from Feb 19th. In addition, I am getting close to submitting another request, for a CSV Exporter plugin. I know you guys have other lives to lead, but please, is there a chance of someone finding time to have a look. I'm getting a bit bogged down, keeping track of which version I actually am using. Or, is there an alternative? Many thanks Allan ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
[Kmymoney-devel] [kmymoney4] [Bug 315760] Unable to map to and online accounts at Capital One Bank
https://bugs.kde.org/show_bug.cgi?id=315760 --- Comment #35 from utwes --- (In reply to comment #34) Thomas - thank you so much for your help in tracking down additional resources. I agree that the GNUCash posts seem to most closely resemble our challenge, and it makes sence that the bank would accept a GUID to determine "unique devices". In regards to your comments below and based on the comments on the discussion boards, it seems that if we were able to add the CLIENTID tag to the OFX request, that might solve our issue. However, I'm assuming that isn't something that I can do on my side (modifying .kmy file or otherwise). In fact, it might be something that KMM developers will depend on AQBanking to do, but please let me know if there are next steps here. Thanks. [snip] > So it seems, we need a ClientUID field to transfer to the bank. Don't know > if this is per KMyMoney instance, per account or what. Martin of aqBanking > fame seems to have the same problem in understanding: > http://lists.gnucash.org/pipermail/gnucash-devel/2012-December/034630.html . > > Here's what the OFX spec says: > > > OFX servers can require OFX clients to include a client ID in each signon > request. This client ID should > be unique to the installation of the client software, but the method that > the ID is generated is left up to the client. The server can specify that > this field is required using the tag in the applicable > section of the profile. Servers should expect that users may > connect via OFX from multiple locations and may need to associate more than > one value with their . > The client may make this value user discoverable, so that the user can > register the client ID with financial institutions. > > > The spec even has an example for it in chapter 2.5.6 entitled "Signon in OFX > 2.1.1 which includes CLIENTUID and both additional credential tags" which > contains the following section: > > MyApp > 1600 > 22576921-8E39-4A82-9E3E-EDDB121ADDEE > MyPin > MyID > > This somehow goes along with the error, that the device is not authorized. -- You are receiving this mail because: You are the assignee for the bug. ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
[Kmymoney-devel] Feature request
Hi, I've been using your application for years and absolutely love - excellent work. there is a feature that I feel is lacking and this is around the scheduling. Would it be possible to add a schedule of 'every second(variable) thursday(variable) of the month' and 'last working day'? thanks Richard ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Split transaction
On Tue, 19 Mar 2013 11:42:49 +0100 Paolo wrote: > I have loaded a certain number of transactions from an Access > database. There are some transactions that I would join toghether in > a split transaction. > I have tried to do so manually, but is so complicated. > > I'd like a functionality to join automatically a range of (manually) > selected transactions of an unique payee into a split transaction. > > Thanks. > > Paolo Sulas > Genoa Italy > > P.S.: sorry for my poor english No need to apologise, It's perfectly understandable. There may be some delay before such a feature can be implemented, so, to ensure this doesn't get overlooked, would you raise it as a wishlist item on https://bugs.kde.org. It appears under 'Importance'. Allan ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
[Kmymoney-devel] Split transaction
I have loaded a certain number of transactions from an Access database. There are some transactions that I would join toghether in a split transaction. I have tried to do so manually, but is so complicated. I'd like a functionality to join automatically a range of (manually) selected transactions of an unique payee into a split transaction. Thanks. Paolo Sulas Genoa Italy P.S.: sorry for my poor english ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
