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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > -- > Bob Brush <[email protected]> > > _______________________________________________ > gnucash-devel mailing list > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
