[Kmymoney-devel] Feature request

TIm Dawson tadawson at tpcsvc.com
Sun Apr 14 16:48:42 UTC 2013


Just testing I also note that kmymoney is not capable of multi-select on 
files to import.  So, 30 or so trips through that gui to update sounds a 
lot like a PITA . . .

- Tim

On 04/14/2013 07:02 PM, Brendan Coupe wrote:
> I download 12 accounts every day or two with one click from KMM. In my
> case going to each website would be significantly more painful. Not sure
> if either of us is a "normal" KMM user but I am much more efficient with
> KMM. You are missing many new features running the old KDE 3 version.
>
> I worked with Thomas for a while to get the OFX import to work better
> and to be less intrusive. For example, there is no dialog box at the end
> if there are no new transactions. I did not write any code, I compiled
> with his patches and tested the changes out. Thomas is in Europe and did
> not have access to an bank with OFX downloading available so he could
> only do so much without someone to help test and debug the changes. No
> need to code in order to help although I'm sure they would welcome
> coding help if you offered.
>
> If you have not received a response from Thomas please look for it
> below. He said his emails to you were bouncing back.
>
> *
> ----
> Brendan*
>
>
> On Sat, Apr 13, 2013 at 11:48 PM, Thomas Baumgart <thb at net-bembel.de
> <mailto:thb at net-bembel.de>> wrote:
>
>     Hi guys (and if present) girls,
>
>
>     lets tackle this from the technical perspective to give Tim an idea
>     what would
>     be involved, leaving the security issues aside. Or maybe, I should
>     touch this
>     first, because a few requirements must be met for this to work:
>
>     * KMyMoney data must not be stored encrypted (using GPG)
>     * The OFX password (and I am sure you must have entered it at least
>     once) must
>     be stored in the unprotected KMM file. It will be stored in clear-text.
>
>     Now the technical issues:
>
>     * KMyMoney is a single user / single process application. Running it
>     in the
>     background must make sure that the file is not opened otherwise.
>     * KMyMoney is a GUI application. In its current setup it won't work
>     w/o a
>     graphical environment (so you would not be able to run it in the
>     background).
>     * The process of importing any data (whether OFX, QIF, HBCI, CSV,
>     ...) is tied
>     with some user interaction during the process of recording the
>     transactions
>     into the engine. This user interaction must be somehow eliminated if
>     running
>     in the background is required.
>
>
>     Proposal: do it the old UNIX way - one program for each task
>
>     * Setup external (to KMyMoney) means to download the OFX files from
>     the bank
>     (wget, curl, perl, php are some options) and start them via cron to
>     drop the
>     information into a directory
>     * add a cli option to KMyMoney that passes the name of the directory
>     to the
>     application
>     * add a feature that this directory is scanned for files at startup
>     and start
>     importing them automatically after opening the KMyMoney data file
>     * Remove processed files to a another directory to let the user
>     decide what to
>     do with them after processing
>
>     I think that this will cover Tims requirements and also keeps
>     modifications to
>     KMyMoney at a low level. All interactive code can remain as it is.
>
>     Another idea just crossing my mind:
>
>     * Download files as explained above
>     * Use KMyMoneys 'web-connect' feature to import the files one at a time
>
>     Web-Connect works as follows:
>
>     * Start KMyMoney and open your data file.
>     * Start a second KMyMoney instance with the file to be imported as
>     argument
>     * If the file is importable (and OFX should be) it will trigger the
>     first
>     instance to do the import.
>
>     Maybe we have to tweak this mechanism for the second instance to
>     wait until
>     the import is finished. Don't know what happens if you use this too
>     fast in a
>     consecutive manner as it quits right after triggering the first
>     instance.
>
>
>     Have a nice weekend.
>
>     Thomas
>
>
>     On Sunday 14 April 2013 09:05:06 TIm Dawson wrote:
>
>      > As I said - I guess I use the thing differently than a lot of
>     folks. I
>      > have not been prompted for (or entered) an account password since the
>      > day the online account was defined - it's just load up kmymoney, hit
>      > "update" and it goes . . . and I pretty much use the program
>     standalone
>      > - kwallet is something that, despite being a kde user since the 2.x
>      > (maybe older, I forget) I have never bothered with . . .
>      >
>      > A large part of this is simply that this bank does not allow any
>      > transactions via OFX that can cost you anything . . . . it's
>     pretty mucn
>      > inquire only, and the OFX password has nothing to do with the main
>      > account, so I regard this as quite low risk.  (If they ever
>     change that,
>      > then I may need to rethink . . . ).
>      >
>      > Anyhoo, were I a PC user, I might also regard doing this manually as
>      > "pretty much the way of life" but being a Linux (Unix) user, it's
>     pretty
>      > much alien to me . . . technology is there so that we *DON'T*
>     have to do
>      > things manually, right?
>      >
>      > I too have been a kmymoney user from well before the days when
>     OFX was
>      > supported at all, and frankly, that was the one thing that pretty
>     much
>      > made it a non-starter for me.  And yes, I remember the pain of
>     the first
>      > deployments, when the OFX stuff was only partially integrated, and
>      > hacking code to get it to work . . . .
>      >
>      > So, based on my use of the OFX tools, yes, I could schedule to
>     bring up
>      > an OFX dump on an interval, but that is only marginally better .
>     . . I
>      > still need to take the time to process all the files, and only
>     *then* is
>      > the data in kmymoney of value to me - again, kind of defeating what I
>      > see as a primary purpose for a financial tool - current data on
>     demand.
>      >
>      > As far as checking for fraud and such, at this point, I do that
>     through
>      > the banks web page view - since it is current, it's much less
>     painful.
>      > What I mainly use kmymoney for is end of year tax
>     reconcilliation, and
>      > long term financial reporting (again, since the bank does not
>     have that
>      > much data online at any given time), since the US allows (well,
>     at least
>      > used to - don't get me started on *THAT*) us to deduct sales tax, and
>      > proper categorization of all transactions over a year in kmymoney
>     gives
>      > me a very good handle on that.
>      >
>      > The main reason that this came back up to me, is that I happened to
>      > (finally) take a look at the kde 4 variants of kmymoney (my personal
>      > system is still on kde3 . . . so running the old stuff) and wanted to
>      > see what all had evolved, since what I personally run is pretty much
>      > "stuck in time" and while there is a lot of good new stuff, this was
>      > still absent.
>      >
>      > So, I figured I'd ask . . . .
>      >
>      > To me, the security issues are pretty much a non-reason for doing
>     or not
>      > doing this . . . if the feature is there (and assuming the
>     workload is
>      > not large) then it's up to the user to decide what is secure or
>     not, no?
>      >   And I admit - I had not looked at the other means of password
>      > management - I've been doing it this way so long that frankly,
>     was not
>      > aware there was any other way.  Which is why the assumption that
>     running
>      > the already present account update features decoupled from the
>     GUI was
>      > the way to go . . . that would be the "golden ticket" at least
>     for me,
>      > and as I said, would not appear to require too much coding,
>     although I
>      > have not looked at the kmymoney source in a while.
>      >
>      > And yes, I have no issue helping on this, testing, whatever . . . .
>      > although my largest liability in that area is that while I am a
>     fair C
>      > programmer, I have never touched C++, which is why I chose to
>     basically
>      > beg for this first!
>      >
>      > Heck, if the code is structured such that the account file open and
>      > update functions are reasonably standalone (and in separate libs,
>     which
>      > appears to be the case) then putting together something like a cli
>      > command "kmymoney_update" would appear possible as well, and
>     frankly if
>      > I knew the code better (as well as C++) I probably would have taken a
>      > stab at it by now.
>      >
>      > Thanks for listening - working on making a formal request as well
>     . . .
>      >
>      > - Tim
>      >
>      > On 04/14/2013 05:06 AM, Brendan Coupe wrote:
>      > > I
>      > > n addition to the kwallet limitation I also have my KMM file
>     encrypted
>      > > so it can't be opened without the password. I guess options
>     could be
>      > > added to the command line to supply both the KMM password and the
>      > > kwallet password but that's not a very secure way to go. Kind
>     of defeats
>      > > the purpose of encrypting the file and storing the password
>     safely. Or
>      > > maybe this feature would only work if you left KMM running (not
>     a simple
>      > > cron job).
>      > >
>      > > Given the amount of effort required to manually enter the
>     transactions
>      > > that are more than 30 days old it seems like it would be much
>     easier to
>      > > have a reminder emailed to you every 2 or 3 weeks and do it
>     manually
>      > > until this feature is added. You don;t have to reconcile your
>     accounts
>      > > every time you download.
>      > >
>      > > Another option you may explore is finding a way to run a cron
>     job to
>      > > download the OFX file from Chase every couple of weeks and
>     storing them
>      > > so that you can import them when you get around to using KMM every
>      > > quarter. Not sure if there is a command line interface
>     available to do
>      > > this in the OFX tools. Or you could look for a bank that lets your
>      > > access YOUR data for more than 30 days:-)
>      > >
>      > > I have been using KMM since before you could download OFX files
>     from the
>      > > bank from within the program. I use to download them manually
>     from each
>      > > bank and import them into KMM. I was so happy when I could
>     finally do
>      > > this from within thee program, I did not see the need to have the
>      > > automated. I prefer to download them frequently so I know if
>     there is
>      > > any fraud going on in any of my accounts. I use to think I
>     wanted to
>      > > have KMM update in the background (probably because MS Money
>     could) but
>      > > haven't felt that way in years - mostly because of the security
>     issues
>      > > it would cause..
>      > >
>      > > In the future I would suggest avoiding comments like "which is
>     an absurd
>      > > requirement...". The developers work for free and they are
>     usually very
>      > > accommodating if you ask nicely and are patient. You should
>     also plan to
>      > > help debug these changes when they are made if you want to make
>     sure
>      > > they work as you hope. I was compiling KMM  with patches a few
>     months
>      > > ago and got exactly the features I had asked for and more (the Not
>      > > Marked, Not Reconciled counts on the home screen). The process
>     usually
>      > > works great but not always as quickly as we'd like. The again
>     Microsoft
>      > > never added any features that I requested in MS Money:-)
>      > >
>      > > I have been reading the user and developer groups since I
>     started using
>      > > KMM. I don't think automatic bank downloads have been requested
>     very
>      > > often (maybe once or twice) and I assume that's a factor in
>     determining
>      > > which features are added next (along with degree of difficulty
>     and ...).
>      > >
>      > > *
>      > > ----
>      > > Brendan*
>      > >
>      > >
>      > > On Sat, Apr 13, 2013 at 3:12 PM, Jack <ostroffjh at sbcglobal.net
>     <mailto:ostroffjh at sbcglobal.net>
>      > >
>      > > <mailto:ostroffjh at sbcglobal.net
>     <mailto:ostroffjh at sbcglobal.net>>> wrote:
>      > >     On 2013.04.13 13 <tel:2013.04.13%2013>
>     <tel:2013.04.13%2013>:20, TIm Dawson wrote:
>      > >         One of the most basic features that I would have
>     assumed would
>      > >         have been a "gimme" in any financial management package
>     that can
>      > >         be utilized in conjunction with a financial
>     organization (IE,
>      > >         can upload transactions from a bank) would be the
>     ability to
>      > >         actually schedule those uploads to happen *WITHOUT* any
>     user
>      > >         intervention.  Either I am totally blind, or in the 5+
>     years
>      > >         that I have been using KMymoney, this feature has been
>     painfully
>      > >         and notably absent.
>      > >
>      > >         Perhaps it's just my patterns as a user, in that I don't
>      > >         necessarily reconcile my accounts monthly (more like
>     quarterly,
>      > >         unless there is an issue) and what happens is that
>     Chase only
>      > >         keeps 30 days of online transactions uploadable, so
>     inevitably,
>      > >         I spend way too much time hand entering stuff that
>     should have
>      > >         been uploaded.  Barring my remembering to do this on a
>     periodic
>      > >         basis (which is an absurd requirement . .  .) a
>     mechanism to
>      > >         schedule this via cron (or other process scheduler) to run
>      > >         *WITHOUT* user intervention would appear to be an
>     obvious need -
>      > >         and need not be anything more sophisicated than a
>     command line
>      > >         option such that kmymoney can be run such as "kmymoney
>      > >         --update-all" and have an OFX update occur, the same as if
>      > >         update-all was selected from the gui, but with no
>     intervention,
>      > >         and no need to load the gui to a desktop.
>      > >
>      > >         Seems like all the parts are there . . . again, I can't
>     fathom
>      > >         why this isn't available (or have managed to miss it
>     for years .
>      > >         . . ).
>      > >
>      > >     Tim,
>      > >
>      > >     I don't think you have missed anything, although I don't
>     see the
>      > >     absense of this feature to be either painful or notable.
>       However,
>      > >     to make sure it does not get forgotten, you can open a
>     ticket at
>      > > bugs.kde.org <http://bugs.kde.org> <http://bugs.kde.org>, using
>     the severity of "wishlist."
>      > >
>      > >     As for whether it's simple and essential or not - that's up for
>      > >     debate.  Personally, I prefer to download transactions more
>      > >     frequently, and interactively, so I can assure correct
>     matching of
>      > >     payees and categories.  Also, if there were a command line
>     option
>      > >     that could be scheduled with cron, it would mean that the
>     password
>      > >
>      > >       to the OFX account would need to be available.  That may
>     or may
>      > >
>      > >     not be an issue for you - but it likely is for some people.
>       I have
>      > >     my passwords stored in kwallet, and the first time it is
>     accessed in
>      > >     any session, it requires me to enter my password to open
>     the wallet.
>      > >
>      > >       If you remove the requirement for a password to the
>     wallet, some
>      > >
>      > >     people would consider that a security issue.  I know KMM
>     can store
>      > >     the password itself, but some don't consider that sufficiently
>      > >     secure.  Yes - KMM could have the feature, and the paranoid
>     among us
>      > >     could keep the password on kwallet and just not use the
>     feature, but
>      > >     this leads to a second point (as has been pointed out on
>     this list)
>      > >     developer time is somewhat limited, and all the developers are
>      > >     volunteers.  They add features and fix bugs because they
>     want to,
>      > >     not because someone says it is essential.
>      > >
>      > >     As a short term workaround - you could have cron send you a
>     message
>      > >     reminding you to download your transaction.
>      > >
>      > >
>      > >     Jack
>      > >
>      > >     _________________________________________________
>      > >     KMyMoney-devel mailing list
>      > > KMyMoney-devel at kde.org <mailto:KMyMoney-devel at kde.org>
>     <mailto:KMyMoney-devel at kde.org <mailto:KMyMoney-devel at kde.org>>
>      > > https://mail.kde.org/mailman/__listinfo/kmymoney-devel
>      > >     <https://mail.kde.org/mailman/listinfo/kmymoney-devel>
>      >
>      > _______________________________________________
>      > KMyMoney-devel mailing list
>      > KMyMoney-devel at kde.org <mailto:KMyMoney-devel at kde.org>
>      > https://mail.kde.org/mailman/listinfo/kmymoney-devel
>     --
>
>     Regards
>
>     Thomas Baumgart
>
>     GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
>     -------------------------------------------------------------
>     Of all the computing resources available, the most valuable one is
>     programmers' time. Especially in open source where most of us have to
>     sneak in time to write and debug code. (Ace Jones)
>     -------------------------------------------------------------
>
>     _______________________________________________
>     KMyMoney-devel mailing list
>     KMyMoney-devel at kde.org <mailto:KMyMoney-devel at kde.org>
>     https://mail.kde.org/mailman/listinfo/kmymoney-devel
>
>


More information about the KMyMoney-devel mailing list