Re: [libalkimia] [Bug 440783] New: Missing icons for buttons in the KF5 variant of the online quotes editor
I'll get it fixed.
Re: [kmymoney] [Bug 441857] Online Banking Setup
I have the following working fine: - Chase Bank (Credit Cards & Banking) - AMEX (Credit Cards) IIRC, for Chase I had to enable "authorization mode" in my online profile, which gives you a few minutes to initiate the connection. For AMEX I think it was straightforward. In any case, I doubt I used any information outside of what www.ofxhome.com users provided on its forum. For Discover cards, they stopped supporting OFX a while ago and now use Quicken's custom thing (Web Connect Express). Other commercial software has the same issue: https://www.iggsoftware.com/support/articles/ibank-5/discover-accounts-not-connecting-using-direct-download-ofx/ https://infinitekind.tenderapp.com/discussions/online-banking/14201-unable-to-download-discovercard-transactions#comment_47656311 Relevant ofxhome thread: http://www.ofxhome.com/ofxforum//viewtopic.php?id=49815 On Thu, Sep 2, 2021 at 12:49 PM Hamdsa via KMyMoney-devel wrote: > > https://bugs.kde.org/show_bug.cgi?id=441857 > > --- Comment #2 from Hamdsa --- > (In reply to Brendan from comment #1) > > Created attachment 141215 [details] > > attachment-23447-0.html > > > > It would help to mention which banks you are having trouble with. I use > > direct connect with Chase (Amazon) and Citi (Costco) credit cards. USAA > > accounts worked until late last year when they made a significant change to > > their system. GNUCash was able to get direct connect to work with USAA > > again and I have been working with one of the KMM developers (Thomas > > Baumgart) to get it to work with KMM. We've been able to get it to work in > > the Master Branch but that branch is not ready for prime time yet. During > > our testing, I could not get AqBanking to work even though that is what > > works in GNUCash. Thomas was able to get ofximorter to work and I'm hopeful > > his changes will make it to the 5.1 branch soon. > > > > There are some necessary steps required for some banks that are not > > obvious, so it helps to know which banks are not working. For example, Citi > > requires a Client ID that I generated randomly. USAA also requires a client > > ID, but they generate it if you follow the correct steps. > > > > ** > > *Brendan Coupe* > > *Delta, it's not just a crappy airline.* > > > > *If Bill Gates put microchips in the vaccine, you would * > > *have to go in for an update the second Tuesday of every month.* > > > > > > On Wed, Sep 1, 2021 at 4:13 AM Hamdsa via KMyMoney-devel < > > kmymoney-devel@kde.org> wrote: > > > > > https://bugs.kde.org/show_bug.cgi?id=441857 > > > > > > Bug ID: 441857 > > >Summary: Online Banking Setup > > >Product: kmymoney > > >Version: 5.1.2 > > > Platform: Microsoft Windows > > > OS: Microsoft Windows > > > Status: REPORTED > > > Severity: major > > > Priority: NOR > > > Component: onlinebanking > > > Assignee: kmymoney-devel@kde.org > > > Reporter: ham...@yahoo.com > > > Target Milestone: --- > > > > > > SUMMARY > > > While Quicken, being a commercial product supported most of the > > > institutions, I > > > was still able to set up some accounts using GNUcash as well (Chase, AMEX > > > etc.), but none of the accounts (banks, credit cards) seem to work in > > > KMyMoney, > > > even though I tried to replicate the same settings for online connections > > > as > > > GNUcash. > > > Does this online automatic downlaod feature work with US banks or the only > > > option is to manually import the QIF/OFX files? > > > Thanks. > > > > > > STEPS TO REPRODUCE > > > 1. > > > 2. > > > 3. > > > > > > OBSERVED RESULT > > > Get the message no suitable accounts to add, for both credit card and bank > > > accounts > > > > > > EXPECTED RESULT > > > Online downloads > > > > > > I'm running 5.1.2 version on Windows 10 Pro > > > > > > SOFTWARE/OS VERSIONS > > > Windows: > > > macOS: > > > Linux/KDE Plasma: > > > (available in About System) > > > KDE Plasma Version: > > > KDE Frameworks Version: > > > Qt Version: > > > > > > ADDITIONAL INFORMATION > > > > > > -- > > > You are receiving this mail because: > > > You are the assignee for the bug. > > So far I have tried the following institutions, none of them worked in > KMyMoney. > Chase Bank (Credit Cards & Banking) > AMEX (Credit Cards) > Discover (Credit Cards) > All of them worked in Quicken 2020 (and prior versions too). Chase also worked > in GNUCash. > I have tried using the default settings, as well as changing the Header > settings to v. 103 as suggested in some online posts, and changing the quicken > simulation version to different values. I also tried to replicate the Chase > settings, using manual option in online setup, that didn't work either. > I'm using UUID v4 using generator here: https://www.uuidtools.com/generate/v4 > Would be happy to do more testing if there are other suggestions to try other > config. > > All connections attempts have similar outcome > Dur
Re: [kmymoney] [Bug 441857] Online Banking Setup
> Does the American Express Savings site integrate with Mint or Quicken? This is for their banking services, if I am not wrong. The Cards work just fine for me: - Quicken 2019 - Header Version 103 Note I am using the ofxbanking plugin for that, not kbanking. On Thu, Sep 2, 2021 at 3:25 PM Brendan Coupe via KMyMoney-devel wrote: > > For Chase I'm using Quicken Windows 2008 and 103. I have a 32 > character Client UID that I think I generated myself (all HEX). > > In Linux try generating a random UID: hexdump -n 16 -e '4/4 "%08X" 1 > "\n"' /dev/urandom > > I have not used my AmEx card in many years. Online banking used to > work with it but I think it stopped working for me a while ago. I just > tried mapping my account and it seemed to work. No matter what I do I > get an error when I try to download my transactions. I could not find > anything about "authorization mode". > > Searching the AmEx site I found this: > == > Does the American Express Savings site integrate with Mint or Quicken? > > At this time, American Express Savings does not allow sites like > Quicken or Mint to login on behalf of our customers. This protocol is > in place to protect Savings customers’ personal information. Savings > does allow you to download transactions so that you can import them > into Quicken by following these easy steps: > > Log in to your American Express Savings account here > Click the account that you want to download > Click the "Download Transactions" link at the bottom of the > Transaction History section > Follow the prompts > > > > Brendan Coupe > Delta, it's not just a crappy airline. > If Bill Gates put microchips in the vaccine, you would > have to go in for an update the second Tuesday of every month. > > > > Brendan Coupe > Delta, it's not just a crappy airline. > If Bill Gates put microchips in the vaccine, you would > have to go in for an update the second Tuesday of every month. > > > On Thu, Sep 2, 2021 at 5:46 AM Dawid Wróbel via KMyMoney-devel > wrote: > > > > https://bugs.kde.org/show_bug.cgi?id=441857 > > > > --- Comment #3 from Dawid Wróbel --- > > I have the following working fine: > > - Chase Bank (Credit Cards & Banking) > > - AMEX (Credit Cards) > > > > IIRC, for Chase I had to enable "authorization mode" in my online > > profile, which gives you a few minutes to initiate the connection. For > > AMEX I think it was straightforward. In any case, I doubt I used any > > information outside of what www.ofxhome.com users provided on its > > forum. > > > > For Discover cards, they stopped supporting OFX a while ago and now > > use Quicken's custom thing (Web Connect Express). Other commercial > > software has the same issue: > > https://www.iggsoftware.com/support/articles/ibank-5/discover-accounts-not-connecting-using-direct-download-ofx/ > > https://infinitekind.tenderapp.com/discussions/online-banking/14201-unable-to-download-discovercard-transactions#comment_47656311 > > > > Relevant ofxhome thread: > > http://www.ofxhome.com/ofxforum//viewtopic.php?id=49815 > > > > On Thu, Sep 2, 2021 at 12:49 PM Hamdsa via KMyMoney-devel > > wrote: > > > > > > https://bugs.kde.org/show_bug.cgi?id=441857 > > > > > > --- Comment #2 from Hamdsa --- > > > (In reply to Brendan from comment #1) > > > > Created attachment 141215 [details] > > > > attachment-23447-0.html > > > > > > > > It would help to mention which banks you are having trouble with. I use > > > > direct connect with Chase (Amazon) and Citi (Costco) credit cards. USAA > > > > accounts worked until late last year when they made a significant > > > > change to > > > > their system. GNUCash was able to get direct connect to work with USAA > > > > again and I have been working with one of the KMM developers (Thomas > > > > Baumgart) to get it to work with KMM. We've been able to get it to work > > > > in > > > > the Master Branch but that branch is not ready for prime time yet. > > > > During > > > > our testing, I could not get AqBanking to work even though that is what > > > > works in GNUCash. Thomas was able to get ofximorter to work and I'm > > > > hopeful > > > > his changes will make it to the 5.1 branch soon. > > > > > > > > There are some necessary steps required for some banks that are not > > > > obvious, so it helps to know which banks are not working. For example, > > > > Citi > > > > requires a Client ID that I generated randomly. USAA also requires a > > > > client > > > > ID, but they generate it if you follow the correct steps. > > > > > > > > ** > > > > *Brendan Coupe* > > > > *Delta, it's not just a crappy airline.* > > > > > > > > *If Bill Gates put microchips in the vaccine, you would * > > > > *have to go in for an update the second Tuesday of every month.* > > > > > > > > > > > > On Wed, Sep 1, 2021 at 4:13 AM Hamdsa via KMyMoney-devel < > > > > kmymoney-devel@kde.org> wrote: > > > > > > > > > https://bugs.kde.org/show_bug.cgi?id=441857 > > > >
LibAlkimia in Debian
Hi Pino, I am one of KMyMoney’s developers and we recently bumped the minimum version of Alkimia (which we also develop) to 8.0. I saw an MR opened that would have the Debian package updated to 8.0.1, but it was never merged: https://salsa.debian.org/qt-kde-team/extras/alkimia/-/merge_requests/1 Would you mind looking into it, and possibly also bumping the version up to current stable 8.1.0? The version found in Debian/Ubuntu is like 3 years old by now. We would much appreciate your help. — With Regards, Dawid Wrobel
Re: LibAlkimia in Debian
On Sat, Mar 12, 2022 at 4:36 PM Dawid Wrobel wrote: Would you mind looking into it, and possibly also bumping the version up to > current stable 8.1.0? The version found in Debian/Ubuntu is like 3 years > old by now. > > We would much appreciate your help. > For what it's worth, KDE Neon maintains an up-to-date Debian packaging for it here: https://invent.kde.org/neon/extras/alkimia It builds on top of Debian's own, so it should be fairly easy to pull those updates upstream.
Re: question on finding account id from name
Jack, I believe that originally the 'kmm-brokerage-account' property was supposed to be used to look-up the linked-up brokerage account id. This, however, does not seem to work, see: https://bugs.kde.org/show_bug.cgi?id=329701 and https://bugs.kde.org/show_bug.cgi?id=350360 On Wed, Jun 22, 2022 at 4:13 PM Jack via KMyMoney-devel < kmymoney-devel@kde.org> wrote: > On 6/22/22 02:18, Thomas Baumgart via KMyMoney-devel wrote: > > On Dienstag, 21. Juni 2022 22:46:35 CEST Jack via KMyMoney-devel wrote: > >> I'm trying to find an way to easily switch between an investment > >> account and it's brokerage account. I have figured out how to test for > >> the two types of accounts (testing the .accountType() or looking for " > >> (Brokerage)" at the end of the name.) However, I don't see any way to > >> look up an account by name. Does this actually require looping through > >> all accounts and testing if the name matches? > > In master you can do this: > > > >QString accountName; > >auto account = > MyMoneyFile::instance()->accountsModel()->itemByName(accountName); > > > >or if you want to stick with the model type access to the data: > > > >auto idx = > MyMoneyFile::instance()->accountsModel()->indexByName(accountName); > >auto name = idx.data(eMyMoney::Model::AccountNameRole).toString(); > > > > which in fact does the looping for you in > AccountsModel::indexListByName(). > > > > Hope that helps. > > Thanks. Either of those is shorter than what I came up with, although > mine does seem to work (looking with gdb.) > > My current problem is that I'm trying to add a "go to brokerage" line > after the "go to account" and "go to payee" menu choices, but it is not > appearing in any of the menus (either main menu or context menu.) I > can't find anywhere in the code where either of the old ones appears > where I haven't added the new one, so I don't know what I am missing. > > Jack > > -- Best Regards, Dawid Wrobel
Re: Automated task plugin
Hi Jonatan, > woob doesn't really work as my bank isn't supported and having double factor authentication, I'm not sure it can work out. woob certainly does support 2FA/OTP authentication, you should be able to find plenty examples both real and in documentation. Also, you may find this interesting: https://invent.kde.org/office/kmymoney/-/issues/25 On Wed, Jul 27, 2022 at 4:52 AM Jonatan Cloutier via KMyMoney-devel < kmymoney-devel@kde.org> wrote: > Thank for the follow-up > > Le 2022-07-26 à 15 h 55, Thomas Baumgart a écrit : > > Jonatan, > > On Dienstag, 26. Juli 2022 04:57:31 CEST Jonatan Cloutier via KMyMoney-devel > wrote: > > > Hello, I'm looking at a way of automatically pulling data in my KMyMoney > files. I already have the source data, but I'm now trying to find a way > to get it automatically into the KMyMoney file. The main requirement is > that I would highly prefer not to take manual action from KMyMoney. > > Which source format does your data have? > > The original src is a bit of anything, mainly web scraping, but might be > REST API calls as well if I get this working, then I can produce whatever > format fit my need. As a quick workaround I'm doing csv, but that still > needs a lot of manual processing to avoid duplicate transaction. > > All in all the reason for this is that my bank is getting worse every year > at producing meaningful ofx files that just need way too many manual fix > after import (more info available in that feature request: > https://bugs.kde.org/show_bug.cgi?id=452392 ) and furthermore, there is > no export feature for loans and investments which are quite cumbersome to > manually update, in particular the later. And to put a cherry on top, > exports are limited to 30 days, which I frequently miss the dead line! > > woob doesn't really work as my bank isn't supported and having double > factor authentication, I'm not sure it can work out. > > After all that being said, two main questions: 1. Is it possible to run > a background listener/task in a plugin as described above? 2. Any other > suggestion on how to script custom data modification automatically? > > I don't know how much knowledge of programming in C++/Qt you bring along. > The background listener is probably not so easy to implement. A way to solve > your problem might be to construct a KMyMoney statement file in an external > tool. It's XML formatted and used internally by KMyMoney by all the importers. > AFAIR, there is a mechanism to start KMyMoney with an importer file as > argument > and it will import it into the last opened KMyMoney file. If KMyMoney is > already > running it will use the so called WebConnect feature to import it into the > already running process. In any case, you would need to have KMyMoney running > and this is only supported with a graphical user interface. > > So, maybe you can elaborate a bit about your (programming) skills and the > operating > system you are using. > > I'm on archlinux, been developing for years mainly in java and pythons but > do have a bit of experience in c++ and did use QT for some very old project. > > I've seen the webconnect features from the main, since it's not limited to > just the ofx importer I've been thinking that a custom importer could do > the job, but haven't really thought of using the statement format as it > doesn't seem documented. But if that enable doing the transaction import > without modal, I suppose it could work. Closest to documentation I found is > MyMoneyStatement::read function and its surroundings. I also see that there > is a write method, is it possible to export in that format? It would just > be quicker to get all the right xml structure. > > I will investigate more on that possibility, might be easier than creating > a new importer and in the end, I think it could be close to my hopes in > terms of usability. > > Quickly looking at that read method, I do have two questions: > > * Are the m_accountId in the statement and in the split required to be > internal KMyMoney id or they can be inferred like from ofx? I suppose they > are the internal Id > > * Similarly, are both part of the split needed to be filled or is there a > way in the import that the automatching of paye and categories and > scheduled transaction would work like an ofx import? > > Thanks again. > -- Best Regards, Dawid Wrobel
Re: [kmymoney] [Bug 457484] Reconciled transaction not accepted
I suppose it would be worth adding an explanation on how this works to the manual-- Best Regards, Dawid Wrobel
Re: [kmymoney] [Bug 457395] Appimage failing to build
I know there is an immanent 0.10.7 coming due to 0.10.6 somehow > not providing it's version information properly, but the error log seems > totally unrelated to that. It’s actually related to that exactly. The 0.10.7 change is about the missing Config.cmake file which will help KMymoney find libofx and its dependencies. Right now it relies on its own heuristic which causes some issues. I will fix all these issues this weekend. -- Best Regards, Dawid Wrobel
Re: Chase moves to Open Banking API
On Fri, Oct 7, 2022 at 4:27 AM Brendan Coupe via KMyMoney-devel < kmymoney-devel@kde.org> wrote: > My Chase credit card no longer works with Direct Connect (ofx in the US). > > I found the following link that explained why it stopped working this week: > Well, that sucks, but it's been happening for other banks since a while, so we kind of had it coming... > > https://www.banktivity.com/support/articles/banktivity-7/ofx-direct-connect-will-no-longer-be-supported-by-chase-as-of-october-6th-2022/ > > Is KMM going to support Open Banking? > No. None of the apps, be it open or closed sourced, actually *support* Open Banking. Any such app uses 3rd party interfaces, which are authorized by the banks themselves to use their Open Banking APIs. Per https://www.banktivity.com/support/articles/banktivity-for-mac/what-is-open-banking/ : "Yodlee in the US and Saltedge in the UK/EU, will download transactions from your bank using an API (application programming interface)." Applications themselves cannot be authorized — explicit business entities can, only, which are issued signing certificates. Hence Yodlee and Saltedge. The problem with those is that information about your transactions is passed through those 3rd parties, so forget about your privacy. This was previously discussed, with hypothetical solutions, see: https://invent.kde.org/office/kmymoney/-/issues/21 -- Best Regards, Dawid Wrobel
Re: Chase moves to Open Banking API
Hi, Are there any US banks and investment > brokers which still support OFX direct connect, and are not likely to > follow the herd? > It's inevitable for all banks. OFX direct connect is not safe, with mere login/pass credentials required to log in to a financial institution. And frankly speaking, I agree with this sentiment, login should require 2 Factor Authentication at all times. The notion that only a curated list of institutions/businesses can apply to have access to a bank's API is also reasonable, as this further strengthens the safety. Unfortunately, we get hit with collateral damage, but it's not all lost — despite a similar approach by the German FinTS standard, KMyMoney was still allowed to become a certified software and allows German/Austrian/Swiss banks customers to use KMyMoney to download transactions on the fly while remaining compliant with the regulations. So with that in mind, something definitely can still be done: in a form of an open letter to the industry/legislator/your favorite senator, bringing awareness over the loss of control over one's funds, as well as the companies like Intuit getting a front seat treatment to bank's APIs, the smaller proprietary software having to resort to Saltedge/Yodlee, which inherently severely affect users' privacy, and lastly over leaving the Open Source software at a complete loss. I can see how GnuCash, Skrooge, Money Manager Ex, Ledger, Firefly III et al would also want to get involved in this. At least they still provide an qfx file from the website. I suspect that > may not last long. Well, OFX Direct Connect is getting scrapped for reasons laid out above. Banks will continue to offer a statement export feature. Which, in fact, I believe could be leveraged as a workaround to the above problem with Woob. It already supports scraping banks' websites to obtain transactional history, but that's rather complicated and prone to frequent failures due to websites continuously getting updated. What I imagine that would help instead is to extend it with an ability to simply pass the from/to dates and download the OFX/QIF statement generated on the fly. This would make the scraping code required way smaller and, as such, more reliable. In fact, something similar already exists ( https://dev.woob.tech/api/capabilities/bill.html), except this one is for downloading pre-generated documents. Shouldn't be too difficult to have it extended to also support downloading docs generated on the fly. Would love for Woob maintainers join the conversation here, AFIK they are subscribed to this list. It needs to be noted, though, that any form of automated log in to a bank's website often puts users doing so in breach of their ToS. So while we're still in power to code away something functional to replace Direct Connect with, it would inevitably be a *hacky* way around the problem — a problem which can ultimately only be solved through awareness, advocating, and eventually a further, privacy-friendly legislation. -- Best Regards, Dawid Wrobel
Re: Chase moves to Open Banking API
On Sat, Oct 8, 2022 at 10:27 PM Jack via KMyMoney-devel < kmymoney-devel@kde.org> wrote: While direct connect using ONLY name/password may not be considered > safe, I can think of ways to still use Direct Connect with 2FA. For > example, any attempt to make such a connection triggers a text to a > mobile phone, where you can reply "Y" within some limited time to > authorize the connection. A variant is something that Heroku uses > (owned by Salesforce, it's hosting site for web apps) which is a custom > phone app. When you try to log in to their site, the app pops up and > you click OK or not, to allow or block the login from a browser. > That's exactly how these "Open" APIs work. That's not the problem, actually, we could totally use those APIs instead of Direct Connect. The problem is the added requirement of being a pre-authorized entity via on-purpose-issued certificates, as opposed to a regular TLS encryption. I created an account with https://developer.chase.com and am about to send a message, asking if they could look into our case. The FinTS precedent could help. > Absolutely no reason to totally scrap something that has worked well > for years That's a bit of a one-sided view. Banks have to fight fraud, so a simple user/pass login had to go. Even if it may never have affected you, it definitely have others, and banks are usually at financial responsibility for that. So it's understandable that they strengthen their security. > give various commercial entities near full access to your > financial information. I largely trust my bank to do a good job > protecting my data, but I'm not at all so comfortable with Intuit or > Yodlee (who I never heard of until this discussion.) > Well, no one is forcing anyone to do that. Yodlee/Saltedge are just integrators, the commercial software uses them out of convenience, as this relieves them from having to deal with all the banks individually — both in terms of integrating with their often unique/quirky APIs and getting their authorizations. Yes, they put their users at disadvantage by doing so, but it's their problem — which they obviously also rather conveniently don't mention (vide Banktivity). I wonder if FSF and/or EFF might take any interest in the direction > this is going. > I'll respond to that in the other e-mail you sent in that regard. -- Best Regards, Dawid Wrobel
Re: Chase moves to Open Banking API
Re: > I created an account with https://developer.chase.com and am about to > send a message, asking if they could look into our case. The FinTS > precedent could help. > FYI, I sent out the following message: To Whom It May Concern, Hello, I am one of the core developers of the open source KMyMoney personal accounting software, and personally a happy CHASE Bank customer. Over the past years I used the software in speech to automatically download the history of transactions using OFX Direct Connect, which worked perfectly. As you're obviously aware, you have decided to shut it down, in favor of the Open Banking API. The reasoning behind it is totally understandable. We are wondering, however, what would be the process of authorizing a non-profit, open-source software like KMyMoney to use your APIs. We don't want to go through the somewhat common route of leveraging the 3rd party integrators in likes of Yodlee or Salt-edge, as this would severely affect our users' privacy. The only way out is to establish a direct relationship with JPMorgan CHASE. It's worth mentioning that KDE e.V., the registered non-profit organization behind the KMyMoney, was previously authorized on our behalf by the German/Swiss/Austrian FinTS, which operate on the basis compatible with European Union's PSD2 directive, which, in turn imposes similar restrictions to your own. We would be happy to provide any details on how this was processed with FinTS. Hopefully that precedent will help to see our case in a favorable light. -- Best Regards, Dawid Wrobel
Re: Chase moves to Open Banking API
On Sat, Oct 8, 2022 at 10:37 PM Jack via KMyMoney-devel < kmymoney-devel@kde.org> wrote: Almost three years old, but > > https://www.eff.org/deeplinks/2019/12/mint-late-stage-adversarial-interoperability-demonstrates-what-we-had-and-what-we > > seems relevant, if a bit outdated. > This is super on point. Definitely worth reaching out to them! -- Best Regards, Dawid Wrobel
Re: Chase moves to Open Banking API
On Sat, Oct 8, 2022 at 11:37 PM Jack via KMyMoney-devel < kmymoney-devel@kde.org> wrote: > That's exactly how these "Open" APIs work. That's not the problem, > > actually, we could totally use those APIs instead of Direct Connect. > > The problem is the added requirement of being a pre-authorized entity > > via on-purpose-issued certificates, as opposed to a regular TLS > > encryption. > > That's not my understanding. I've seen mention of a one time > authorization for the bank to give your data to Intuit (and I'm still > not sure where Yodlee fits in.) OK, I see where the confusion is. What I was describing is how the process looks in authorizing the business behind the application/service (think: FinTech) with the Bank itself. >From a user's perspective, you need to authorize that very application/service to use your *actual* account. For that, the application/service will contact the bank, present you with a pop-up window that the *bank* provides, which will ask you to perform the 2 Factor Authentication — be it with a code sent to your phone, or, increasingly, directly in your bank's Andoid/iOS app. Once this is done, they would present you with information over what kind of permissions would that app/service have and let you you decide which of your account(s) you would want them have that access to. It sounds to me that when you request data in Quicken, it talks to Intuit. I can't tell. Technically speaking, Quicken as a standalone app could be talking directly to the banks using their APIs. In which case you would be the only person in possession of your financial data, outside of the bank. Whether they do it like this, or they pass that information through Intuit's intermediary servers, that can probably be inferred from Quicken's T&Cs. Chances are that Intuit being Intuit, same company behind Mint, which makes money off of user's data, would likely find it too hard to pass on that revenue avenue. That purpose-issued certificate you mention is used to secure the > connection between Intuit and the > bank, but it means your data does flow through Intuit. Certificates can be used directly by the application itself, there doesn't have to be some inherent intermediary. > (I don't really trust Intuit much more than I trust Yodlee.) Yodlee is an aggregator. They provide services to other FinTech companies if they don't want to be dealing with each bank individually. Quicken/Intuit used to use them before Open Banking API was a thing, but nowadays, AFIK, they deal with banks directly. Other software, like Banktivity, resorts to said aggregators, because they don't have enough resources to maintain legal and technical aspects of maintaining direct connection with all the many banks out there. Even if KDE/KMM could become such a pre-authorized entity, I don't think we > want to become > that type of middle-man. As explained above, there's no middle-man in such a scenario, just like there already isn't for the clientele of German/Swiss/Austrian FinTS banks that KMyMoney is authorized for already — althgouth that doesn't actually involve certificates. > I'm sure I"m missing something, and I'd love to see a more detailed > description of how it all actually works. > Hopefully I was able to help. -- Best Regards, Dawid Wrobel
Re: Chase moves to Open Banking API
On Sun, Oct 9, 2022 at 12:01 AM Dawid Wrobel wrote: It sounds to me that when you request data in Quicken, it talks to Intuit. > > > I can't tell. Technically speaking, Quicken as a standalone app could be > talking directly to the banks using their APIs. In which case you would be > the only person in possession of your financial data, outside of the bank. > Whether they do it like this, or they pass that information through > Intuit's intermediary servers, that can probably be inferred from Quicken's > T&Cs. Chances are that Intuit being Intuit, same company behind Mint, which > makes money off of user's data, would likely find it too hard to pass on > that revenue avenue. > One more thing: I said in my first email in this thread that personal finance applications, be it open or closed, don't use those APIs directly and instead resort to 3rd parties. This is the case for Banktivity or Mondeydance, which, as mentioned, have little resources. Mondeydance, for example, saw banks making it increasingly difficult for them to apply, some outright suggesting they ought to use the aggregators, after all — see https://infinitekind.com/blog/moneydance-plus-privacy-subscriptions However, Quicken may be an exception here, given their resources and the fact that they curate to the North America market exclusively, so the number of banks they need to deal with is way lower than the other software mentioned which curates to their worldwide clientele. -- Best Regards, Dawid Wrobel
Re: KMyMoney | Use QtKeychain instead KWallet directly (#46)
On Mon, Oct 10, 2022 at 6:16 PM Jack via KMyMoney-devel < kmymoney-devel@kde.org> wrote: > I don't know why I didn't notice this earlier, but if I don't want to > type all my passwords again, are there instructions for how I would go > about migrating them? (on Linux, KDE Plasma) > I imagine you'd have to rename them accordingly. Try saving a new credential using master build (I just merged the code). Then see the differences. The new credential should be saved under a "org.kde.kmymoney" name/folder. Renaming should be relatively easy, if my experience here on macOS with its own native vault is to be of any value. Unfortunately, this cannot be automated from the app level, but we could add a manual page/FAQ on how to do this, possibly with a bash script (via DBus). Which actually begs the question: should we look into how to prepare a "What's new in xxx release"? for when we push an alpha release? -- Best Regards, Dawid Wrobel
Re: KMyMoney | Use QtKeychain instead KWallet directly (#46)
> Perhaps some pop-up on needing a password telling why it might not be there if it used to be, and at least a pointer to instructions on how to migrate, if possible. The problem is that it would have to show only once, and for all users, as we won't be able to know whether or not they had some passwords saved previously. And if we were already doing a "one time for all" pop up, we might as well make it into a complete "What's new in this major release" and point them to an article/open a manual/page/whatever. -- Dawid
Re: new question/problem with direct connect
https://opensource.com/article/20/2/how-unsubscribe-mailing-list
Re: Chase moves to Open Banking API
On Wed, Oct 19, 2022 at 8:28 PM Jack via KMyMoney-devel < kmymoney-devel@kde.org> wrote: Thanks for the update. I, on the other hand, have not heard back from CHASE. The message I sent was through their developer account platform, so at least in theory it should have reached the component people without having to work through the red tape. -- Best Regards, Dawid Wrobel
Re: Master Branch Status
On Wed, Nov 9, 2022 at 6:18 PM Brendan Coupe via KMyMoney-devel < kmymoney-devel@kde.org> wrote: > I'm wondering if this has changed? Keeping in mind that I have plenty of > backup files and I understand the risks involved, has the master branch > gotten to the point where it is a viable option to use on a daily basis? I > would like to be able to give feedback to the developers on the coming > release to do my part. > > Been using it for the last 3 months, all the issues so far were mere annoyances, nothing affecting data integrity. > As I recall, running the master branch caused some issues and switching > back a forth between the 5.1 branch and the master branch was not > practical. I assume this is still the case. > > It would be great to get a short update on how far along the master branch > is and if possible, how soon it may be released. > Pretty much all the effort is on getting master to alpha state. Hard to pin the release on a specific date, though. As for the remaining work required, Thomas can possibly shed more light on it. -- Best Regards, Dawid Wrobel
Re: Jenkins build for MacOS failing
On Fri, Jul 14, 2023 at 11:01 PM Jack Ostroff via KMyMoney-devel < kmymoney-devel@kde.org> wrote: > The MacOS build of KMyMoney on Jenkins has been failing for a week. > > The build seems to fail while building aqbanking with > > 18:48:30 dyld[83380]: Library not loaded: libbrotlienc.1.dylib > 18:48:30Referenced from: > /Users/packaging/Craft/BinaryFactory/macos-64-clang/lib/libgnutls.30.dylib > I can see aqbanking blueprint was updated by Thomas just yesterday, removing Brotli library from the runtime dependencies here: https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/5d9bb8c38288654f55b95c916af9af3149340e00#8a96c0cfb12c7c2ffeb5716e773e72ed47202a6b_41_40 Although given it's from yesterday, it could very well be Thomas' attempt to remedy the issue you mention. -- Best, Dawid
