[Kmymoney-devel] Feature request

Sun Apr 14 16:02:24 UTC 2013

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> 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>> wrote:
> > >     On 2013.04.13 13 <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>, 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>
> > >     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
> > 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
> https://mail.kde.org/mailman/listinfo/kmymoney-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20130414/33b835ef/attachment-0001.html>