I would also like to see this feature / bug sorted. I think it's a good feature to have to be able to add files to a transaction for scanned receipts invoices etc.. but there should be some form of icon displayed to show that a file is attached to the transaction.

Also a way of editing the attached transaction / or deleting the link would be a good idea too.

I'd like to thank the developers that worked on implementing the transaction associate /attach feature.  This is a great feature and they did a great job.  I'd also like to upvote the previous suggestions for ways to build upon this feature, including the suggestion for an icon or some UI indicator that shows that a transaction has an attachment.  Very important enhancement, IMHO.  In addition...

1.) There should be ways of handling unknown file types.  The method(s) for handling unknown file types should also be available for known file types.  Take, for example, a file containing random data:

dd if=/dev/urandom of=/home/user/rdata bs=512 count=10

(In the real world, this could be an encrypted file, for example, or a bitcoin wallet, or whatever.)

In my current desktop environment, the example file 'rdata' created above, when associated with a transaction in GnuCash, will be opened by Emacs.  This is not very useful.

Possible solutions (also useful for known file types):
1.a.) Provide a means to open the containing folder instead of the file itself; i.e.  open the containing folder in the system file manager instead of the file itself (perhaps by right-clicking the transaction to bring up a context menu).
1.a.i) It would be nice if -- when the system file manager opens the containing folder -- it had the file selected, so that pressing <Return> would initiate the default desktop action for the file, or pressing the keyboard context menu key would activate the context menu for the file.  (Helpful if the containing folder has a large number of files that the user would have to scroll through to find the one he/she is interested in.)
1.b.) Similar to '1.a', but provide a means to open an xterm that has the current directory set to the containing folder (perhaps by right-clicking the transaction to bring up a context menu).
1.b.i) It would be nice if -- the name of the file were also copied to the clipboard so that a simple <Paste> would insert it on the command line in the xterm.
1.c.) Provide a means to copy the full uri of the file to the clipboard (perhaps by right-clicking the transaction to bring up a context menu).

2.) In addition to the above, it would be nice to be able to associate a directory with a transaction; to associate a directory uri instead of a file uri. Currently a tech-savy, uri-savy user can accomplish this by entering a directory uri in the associate location dialog, but most users probable won't realize this.  Some enhancements to the UI would make this feature more accessible.

3.) In addition to the above, it would be nice to be able to associate multiple files with a single transaction.  One way of implementing this might be to allow strings that contains multiple uri's.

The lack of visual feedback for this is a major oversight. Users should be able to see that the transaction has changed, that it is different from others.

Here's a 'me-too.'

I have been scanning documents as I enter them by the dozens and was about to embark on attaching them, but since I now discover I'll have no easy visual clue as to which transactions/invoices/bills have attachments or not, I'm not about to start that project. This is quite a shame, because it would be really useful.

I also agree that being able to edit the attachment link or even deleting it is nearly a necessity to make this feature usable. Linking the wrong attachment by mistake without a way to correct that mistake makes the feature useless.

My suggestion would be for possibly a paperclip icon to indicate the attachment since that is used in various applications already, especially email apps where attachments are common.

Additionally, adding the ability to search or filter searches by an attachment flag would be helpful here for invoices and bills.

Yet another me-too.  Externally created documents are critical for audits. They are scanned and placed into a directory by type or usage, by fiscal year, with intelligent file names. Begin able to open such a file, whether PDF, DOC, PNG, etc., from inside a transaction is great. But for the purposes of audit (or pre-audit), it's important to know how many of our transactions have the proper documentation. Having an icon or link, something we can view (and hopefully export when we export the transaction list) would be very, very helpful.

I would like to see some development attention for this good idea, to that end, I have initiated a bounty that may be claimed by the person(s) credited to implementation of this feature request.

Here's a link to it: 

https://freedomsponsors.org/issue/780/add-visual-indicator-in-register-that-a-transaction-is-linked-to-a-file-or-uri

If you are so inclined, feel free to pile on the offer to sweeten the deal if this is something you want to see done.

Yes. Very important feature -> to attach file(s).

Needs at least a flag and a "delete" function. Multiple attachments would be nice.

cfdoe1's suggestions all look excellent when time permits.

Be good to have a parameter in the configuratio dialog that allows setting a "root" directory for the files. Or maybe define it per account under the Account definition (edit account); default to the "root" in the config dialog; use quotes to spec a fully qualified uri; no quotes, start with "/" to spec a uri relative to the "root" defined (defaulted) in the config dialog. This would allow later "correction" (hah!) of file trees. This could be important since such documentary files often serve multiple uses and are located not in a dedicated gnucash directory but in a more general purpose location - which could well suffer change later from external causes. Linking to the documents from a dedicated gnucash dir might work OK but copying, ie. creating duplicate master documents, s/b avoided at all costs - therein lies Hell.

(In reply to A from comment #6)
> I would like to see some development attention for this good idea, to that
> end, I have initiated a bounty that may be claimed by the person(s) credited
> to implementation of this feature request.
> 
> Here's a link to it: 
> 
> https://freedomsponsors.org/issue/780/add-visual-indicator-in-register-that-
> a-transaction-is-linked-to-a-file-or-uri
> 
> If you are so inclined, feel free to pile on the offer to sweeten the deal
> if this is something you want to see done.

Does the GnuCash project have any policy on this kind of bounty?

This features was recently implemented by Robert Fewell and  will appear in the next major release (2.8.0), which is currently planned for 2018. The bounty claim should be his if he wishes to take it.

I find it a bit awkward it will take until then before the feature will be released. This is due to the gnucash backport policy.

@devs: I'm considering backporting the minimal base part of Roberts work to maint. That is the indicator itself only. This is a relatively well contained bit of gui code that's not too complicated to review. I'm talking about commits 5bb53c044..5f75f106ee here. Robert made more improvements, but this minimal set would greatly increase the usefulness of the file association feature. Any objections ?

(In reply to cfdoe1 from comment #2)
> I'd like to thank the developers that worked on implementing the transaction
> associate /attach feature.  This is a great feature and they did a great
> job.  I'd also like to upvote the previous suggestions for ways to build
> upon this feature, including the suggestion for an icon or some UI indicator
> that shows that a transaction has an attachment.  Very important
> enhancement, IMHO.  In addition...
> 
> 1.) There should be ways of handling unknown file types.  The method(s) for
> handling unknown file types should also be available for known file types. 
> Take, for example, a file containing random data:
> 
> dd if=/dev/urandom of=/home/user/rdata bs=512 count=10
> 
> (In the real world, this could be an encrypted file, for example, or a
> bitcoin wallet, or whatever.)
> 
> In my current desktop environment, the example file 'rdata' created above,
> when associated with a transaction in GnuCash, will be opened by Emacs. 
> This is not very useful.
> 
> Possible solutions (also useful for known file types):
> 1.a.) Provide a means to open the containing folder instead of the file
> itself; i.e.  open the containing folder in the system file manager instead
> of the file itself (perhaps by right-clicking the transaction to bring up a
> context menu).
> 1.a.i) It would be nice if -- when the system file manager opens the
> containing folder -- it had the file selected, so that pressing <Return>
> would initiate the default desktop action for the file, or pressing the
> keyboard context menu key would activate the context menu for the file. 
> (Helpful if the containing folder has a large number of files that the user
> would have to scroll through to find the one he/she is interested in.)
> 1.b.) Similar to '1.a', but provide a means to open an xterm that has the
> current directory set to the containing folder (perhaps by right-clicking
> the transaction to bring up a context menu).
> 1.b.i) It would be nice if -- the name of the file were also copied to the
> clipboard so that a simple <Paste> would insert it on the command line in
> the xterm.
> 1.c.) Provide a means to copy the full uri of the file to the clipboard
> (perhaps by right-clicking the transaction to bring up a context menu).
> 
> 2.) In addition to the above, it would be nice to be able to associate a
> directory with a transaction; to associate a directory uri instead of a file
> uri. Currently a tech-savy, uri-savy user can accomplish this by entering a
> directory uri in the associate location dialog, but most users probable
> won't realize this.  Some enhancements to the UI would make this feature
> more accessible.
> 
> 3.) In addition to the above, it would be nice to be able to associate
> multiple files with a single transaction.  One way of implementing this
> might be to allow strings that contains multiple uri's.

Thank you for the added suggestions. Each of them should be put in a separate bug report though for individual discussion. Alternatively you can make feature requests via https://gnucash.uservoice.com

Listing them all in one single bug report makes it more difficult to manage.

(In reply to Kevin Brubeck Unhammer from comment #8)
> (In reply to A from comment #6)
> > I would like to see some development attention for this good idea, to that
> > end, I have initiated a bounty that may be claimed by the person(s) credited
> > to implementation of this feature request.
> > 
> > Here's a link to it: 
> > 
> > https://freedomsponsors.org/issue/780/add-visual-indicator-in-register-that-
> > a-transaction-is-linked-to-a-file-or-uri
> > 
> > If you are so inclined, feel free to pile on the offer to sweeten the deal
> > if this is something you want to see done.
> 
> Does the GnuCash project have any policy on this kind of bounty?

No. What kind of policy were you thinking of ?

(In reply to rlaggren from comment #7)
> Yes. Very important feature -> to attach file(s).
> 
> Needs at least a flag and a "delete" function. Multiple attachments would be
> nice.
> 
> cfdoe1's suggestions all look excellent when time permits.
> 
> Be good to have a parameter in the configuratio dialog that allows setting a
> "root" directory for the files. Or maybe define it per account under the
> Account definition (edit account); default to the "root" in the config
> dialog; use quotes to spec a fully qualified uri; no quotes, start with "/"
> to spec a uri relative to the "root" defined (defaulted) in the config
> dialog. This would allow later "correction" (hah!) of file trees. This could
> be important since such documentary files often serve multiple uses and are
> located not in a dedicated gnucash directory but in a more general purpose
> location - which could well suffer change later from external causes.
> Linking to the documents from a dedicated gnucash dir might work OK but
> copying, ie. creating duplicate master documents, s/b avoided at all costs -
> therein lies Hell.

This is part of Robert's implementation for the 2.8 release and a part that can't be backported easily.

(In reply to Geert Janssens from comment #9)
> @devs: I'm considering backporting the minimal base part of Roberts work to
> maint. That is the indicator itself only. This is a relatively well
> contained bit of gui code that's not too complicated to review. I'm talking
> about commits 5bb53c044..5f75f106ee here. Robert made more improvements, but
> this minimal set would greatly increase the usefulness of the file
> association feature. Any objections ?

For your information, these parts have been backported.

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=744790. Please continue processing the bug there and please update any external references or bookmarks.