[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