| Summary: | KF5 ofximporter "Map account" fails on MS Windows | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | Jeff <jeffjl.kde> |
| Component: | importer | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kmymoney, me, ralf.habacker |
| Priority: | NOR | ||
| Version: | git (master) | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://commits.kde.org/kmymoney/d8052a698b736ddc0b9af6287ae698194cf0f10d | Version Fixed In: | 5.1.0 |
| Sentry Crash Report: | |||
I did some digging into this issue and found that when I got to "http://www.ofxhome.com/api.php" or "http://www.ofxhome.com/api.php?all=yes" I get a blank screen instead of results. However if I go to "http://www.ofxhome.com/api.php?dump=yes" I do get an XML result back. Therefore the answer might be as easy as changing the URL from "http://www.ofxhome.com/api.php?all=yes" to "http://www.ofxhome.com/api.php?dump=yes". citapinc: take your browser and load the 'empty' page from "http://www.ofxhome.com/api.php?all=yes". Then direct your browser to show you the source code of the page and you will notice, that it not empty at all. Git commit 1989a4296d070c9ad962578815ab4fa169f61706 by Thomas Baumgart. Committed on 26/03/2020 at 15:36. Pushed by tbaumgart into branch '5.0'. Fix local filename on windows for ofx banking FIXED-IN: 5.0.9 M +43 -24 kmymoney/plugins/ofx/import/ofxpartner.cpp M +17 -17 kmymoney/plugins/ofx/import/ofxpartner.h https://commits.kde.org/kmymoney/1989a4296d070c9ad962578815ab4fa169f61706 Thank you Thomas for addressing this issue. I went to the nightly build, downloaded the Windows .EXE for 5.0.9 and installed it. However the nightly build doesn't include kbanking or ofximporter. Where can I go to download the latest Windows compiled version that includes the new ofximporter so I can beta test it for you? Git commit d8052a698b736ddc0b9af6287ae698194cf0f10d by Thomas Baumgart. Committed on 30/03/2020 at 17:16. Pushed by tbaumgart into branch '5.0'. Reconstruct url based on modified filename This should resolve the issue that the URL is invalid on windows systems. This amends commit 1989a4296d070c9ad962578815ab4fa169f61706 M +1 -1 kmymoney/plugins/ofx/import/ofxpartner.cpp https://commits.kde.org/kmymoney/d8052a698b736ddc0b9af6287ae698194cf0f10d Git commit 59a56c94761ecd17b9fd42e7270fbd8b9eee8245 by Thomas Baumgart. Committed on 03/04/2020 at 16:53. Pushed by tbaumgart into branch '5.0'. Add a leading slash in front of the drive letter This amends commit d8052a698b736ddc0b9af6287ae698194cf0f10d and finally fixes the problem. M +1 -1 kmymoney/plugins/ofx/import/ofxpartner.cpp https://commits.kde.org/kmymoney/59a56c94761ecd17b9fd42e7270fbd8b9eee8245 *** Bug 413386 has been marked as a duplicate of this bug. *** |
I have a couple of problems with ofxpartner.cpp on a craft-mingw-Qt5.11-windows build. First, the "get" function of the OfxHttpRequest constructor does not work. Maybe because KIO::copy does not work on Windows. Maybe KIO::copy doesn't work because of QUrl problems on Windows (see problem #2, below). Or maybe this has been overlooked because if you have an old ofx-bank-index.xml file laying around, KMM will use that file even if it fails to fetch a new one. I hacked around that issue by just commenting out the "if(type.toLower() == QStringLiteral("get"))" section around ofxpartner.cpp line 297 and always using the "post" code. A full fix would just remove the "type" parameter from that function (it was unused in KMM4). I have not been able to figure out a "clean" solution to the second problem. It has to do with QUrl paths. I can not find a combination of QUrl, QFile, QDir, QFileInfo calls that will construct a file name that succeeds with QFile::open in the slotOfxConnected() method. Even though QUrl.isLocalFile() returns "true", the file path either does not include the drive letter, e.g. "/users/jeff/ofx-bank-index.xml", or includes the drive letter looking like a network name, e.g. "//c/users/jeff/ofx-bank-index.xml". QFile fails to open either of those. This may only be a problem because my KMM program is on D: and my app folder is on C:. If they were on the same drive, maybe the "/users/jeff" path would work. If I just hack in a string replacement to change the "//c/" to "c:/" to pass to QFile::open(), then KMM will fetch a new ofx-bank-index.xml and everything's good from there (assuming the "get" fix is in). The "static QString directory" member variable is correctly "C:/users/jeff" at the troublesome spot. It just gets lost in the QUrl.