Bug 336843 - Attach files to Transactions
gnucash at wvit.net
Fri Nov 15 00:55:52 EST 2013
I really like the file management implementation of the program
Shotwell, the comments on Gramps reminded me. It is much the same
situation as here, some users want the program to store the files,
others say please don't touch my files, so it handles this by prompting
at the beginning, and by answering the question the user self educates
and creates the appropriate expectations. If this would be a good
model, I'm thinking it would work like this:
"GnuCash can copy the image into your data folder or it can import
without copying" Cancel, Copy Image, Import in Place?
I don't know if image is the correct wording, it could be receipt if
that isn't limiting, or pdf, I would hate to limit some future case not
yet imagined, maybe just "file"?
I also find the "Preferences" in shotwell to be helpful and may also be
a good model? If so maybe like this:
Import files to: (default to same location as data file)
Directory structure: (Custom)
Pattern: (%Y/%B/%B %d, %Y - %A)
Example - 2009/March/March 10, 2009 - Tuesday
Rename imported files to lowercase: (y/n)
I think that using this type of file organization would be great and
allow flexibility, some will want less than ten folders for their
images, others will want a labyrinth of organization, and others will
want to use either an existing system or something unrelated to the
program to organize. It would also be best to have patterns for GnuCash
specific things in case you would want your image folders to have the
same pattern as the account tree list, or organize by vendor, customer,
And finally not to throw in the kitchen sink, but it would be cool to
add metadata to the file also, maybe a visible summary of the
transaction (for those outside GnuCash) it is linked to with a gnc link
(gncthing:thing=eb9a14a0e076e0029bfd2e623b2f2cc8#) to the transaction,
the Company name, the date of the transaction it was linked to, and/or
things like that..
Would it be good to display the file in GnuCash using webkit?
Would it be good to have thumbnails?
On Wed, 2013-11-13 at 20:55 -0800, John Ralls wrote:
> On Nov 13, 2013, at 5:09 PM, Patrick <patrick at setsuid.net> wrote:
> > Indeed, a very relevant question. I had thought about storing the file
> > itself in the database as a binary blob, but had concerns the db would
> > grow too large and cause other stability issues. Also, that wouldn't
> > work well with the XML back-end.
> > I'm not sure how to ensure file availability, given any other program
> > or user outside of GNUCash could alter the filesystem (and, for
> > instance, delete the file.) That sounds intractable to me, assuming a
> > file:// url is used. Granted, there's nothing to guarantee an
> > http/https url will be around at next retrieval either. There is no
> > URL validation code in the input phase of the "Associate Location"
> > function - it'll just fail on retrieval. Same problem, different
> > space.
> > Fundamentally, they are just links. But, to Derek's point, how then to
> > educate the user-base so as not to cause resentment when someone's
> > relative removes the linked files and the user blames GnuCash.
> > In the end, I gave up pondering this further as I wasn't getting
> > anywhere. Definitely non-trivial.
> The other application project I work on, Gramps , has a similar feature for linking "media" (image) files. It offers some tools for (re)configuring the root path on relative file names along with an option for storing either relative or absolute pathnames and a tool for switching from relative to absolute and back. It also offers an option to include "media" in a zipped backup bundle.
> The way to manage user expectations is documentation, which there isn't any yet for this new feature. Considering that I'm holding off string and feature freeze for this, is it *really* mature enough to add 6 weeks before release? Roger it's a widely-requested feature, roger that someone made a public announcement implying that it's going to be in the next release, roger the code is simple and straightforward. But it's not documented and we don't really know what users expect. Can we get that information and meet the bulk of those expectations in 6 weeks?
> John Ralls
>  http://www.gramps-project.org
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
Bob Brush <gnucash at wvit.net>
More information about the gnucash-devel