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>> 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@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
https://mail.kde.org/mailman/listinfo/kmymoney-devel
