Bug 336843 - Attach files to Transactions

[Ted Creedon]

File bloat should be avoided adding scanned files would make the data file
impossible to administer

Have you considered a check & repair function to detect link rot?


On Thu, Nov 14, 2013 at 9:55 PM, Bob Brush <gnucash at wvit.net> wrote:

> 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,
> or employee?
>
> 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?
>
> -Bob
>
>
>
> 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 [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
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> --
> Bob Brush <gnucash at wvit.net>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>