Bug 336843 - Attach files to Transactions

John Ralls jralls at ceridwen.fremont.ca.us
Wed Nov 13 23:55:36 EST 2013


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 [1], 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?

Regards,
John Ralls

[1] http://www.gramps-project.org


More information about the gnucash-devel mailing list