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 <t...@net-bembel.de
<mailto:t...@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 <ostrof...@sbcglobal.net
<mailto:ostrof...@sbcglobal.net>
> >
> > <mailto:ostrof...@sbcglobal.net
<mailto:ostrof...@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@kde.org <mailto:KMyMoney-devel@kde.org>
<mailto:KMyMoney-devel@kde.org <mailto:KMyMoney-devel@kde.org>>
> > https://mail.kde.org/mailman/__listinfo/kmymoney-devel
> > <https://mail.kde.org/mailman/listinfo/kmymoney-devel>
>
> _______________________________________________
> KMyMoney-devel mailing list
> KMyMoney-devel@kde.org <mailto:KMyMoney-devel@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@kde.org <mailto:KMyMoney-devel@kde.org>
https://mail.kde.org/mailman/listinfo/kmymoney-devel
