This is entirely as expected behavior. When an e-mail comes in, the file(s) attached to it are stored in a specific location, per user preferences. by default, this is on the GoldMine server in the GoldMine\mailbox\attach\...\ folder tree. There are additional options to further segment the sub-folders below that level by user and/or date.
GoldMine's e-mail record simply points to the file(s) in those locations. It doesn't retain a copy of the file(s) inside the database or anything like that.
If your users are then moving the underlying file, the GoldMine e-mail record is going to remain unchanged and, of course, not be aware of the change in the file's location.
I'd suggest that the user(s) NOT move the files as the default mail attachment location is probably universally accessible already. If it is not, it might be a good idea to figure out a different strategy for your users' attachment location settings to avoid this whole chain of events.
...Unless, of course, I'm completely misunderstanding the workflow here...?
Thanks for your answer Doug. I appreciate the comment and I understand where your coming from. As far as your answer goes, you definitely understand the workflow. The biggest issue is that the process used to work in Goldmine but only recently has stopped working. I just can't figure out why there would be a change since we haven't updated Goldmine in a while. Thank you again for getting back to me.
When the user receives the e-mail it will be stored in the ...\GoldMine\mailbox\attach\...\ directory like DCastell mentioned. Is this the file that is then being moved by the user? Or, is the scanner saving a copy of the scan to a separate repository location that the user is going to and then moving that document?
With the image not appearing in the e-mail, this will definitely occur if the file is moved from the ...\GoldMine\mailbox\attach\...\ folder. In this scenario, the users should copy the file instead of moving it, retaining the original file for the email record.
If the users are moving a separate file from a repository location that the scanner saves to, this will have no effect on the e-mail in GoldMine as this file is not referenced in that e-mail. In this scenario, I would suspect a user rights issue on the GoldMine Mailbox folder preventing users from accessing the file, or an issue with the local GM.INI file on the user's workstation causing the file to be stored in a local folder preventing other users from accessing the file.
Hello Joseph. I appreciate the response.
The scanned file is indeed stored in the \GoldMine\mailbox\attach\... directory as previously established. This is also the file that is being moved. What is the problem is that Goldmine used to update the link when moving the file, and still does if the file is a word doc, etc., created on the user's PC and then moved. I just can't understand why the function would have worked previously but no longer does, even without an update?
GoldMine has never functioned this way. It does not monitor the file after capturing it's location. Perhaps there is a third-party utility that manages the links when a file is moved that is no longer working.
You can't say that it has "never functioned this way" when indeed it did. For a long time it did. I appreciate you trying to help, but telling me that something that I know used to work, and in some circumstances still does [see above], (because I used this function many times) doesn't exist isn't very helpful.
Your original description does not mention which method the users are employing to move the file. If they are going the file location in Windows Explorer and moving the file to a new location, then GoldMine will not be aware of this change. If they are right-clicking the attachment in the e-mail within GoldMine and selecting the 'Move' option from the pop-up menu, then GoldMine will be aware of the change and the link should be updated accordingly. There is an issue with this method, if the attachment is also being displayed in the body of the e-mail, then the attachment showing in the header will update and still function properly, but the image reference will not and the display of the image will no longer show in the body of the email.
To clarify things, I'll go ahead and post some screen shots.
I've taken the liberty of running through the process that the user is doing because visuals in my opinion are always nice. I hope that you or anyone reading this will be able to find some better information from this.
Step 1 - the user scans the file into their email (as seen as JhaldenTest123.pdf). Here I should note that the type of file as well as the number of recipients of the email do not change the outcome of the process.
Step 2 - The user links the email to a contact (I realize that it was already linked in the first picture, but again doesn't change the outcome). Here I'll note that it doesn't matter which contact the email is linked to.
Step 3 - The user is moving the email (the name of the destination folder will be seen in the next step). Another note...The destination of the file also doesn't change the outcome.
Step 4 - The user chooses the destination (here seen as n:\dealers\dealer agreements-signed\)
Step 5 - the user fast files the email. Here I'll note that the order in which the user fast files, links, and moves the file don't change the outcome.
Step 6 - the user goes to the history under the contact (I filed it under myself because the contact doesn't matter)
Step 7 - the email is opened, and the file is no longer there
Step 8 - I went to view the email in the browser to see what was going on with the attachment. Aaaaaaannnnnnd.........
Step 9 - Goldmine didn't update the link to the attachment.
This helps clear things up a lot.
1. The behavior you're seeing isn't normal. The link should be updated.
2. I have some questions:
a. What exact/full version of GoldMine are you on?
b. Does your mailbox table still have an RFC822_old column?
c. How many records are in your mailbox table?
d. Does your sql server perform routine consistency checks/index/statistics maintenance on the tables in your GoldMine database?
3. Do you have a current maintenance contract with HEAT? Have you contacted support?
The GoldMine version that we are on is:
GoldMine Premium Edition Version 2016.1.0.161
I'd have to get back to you on the sql side of things. And when I spoke to support they told me that they didn't know what the issue was and not to use it. That was what led me to ask on here because just saying not to use it isn't an acceptable answer if you ask me.
I agree with DCastell, this is definitely not normal. Two questions:
- Does the file actually get moved to the location specified by the user?
- If you use a UNC path, instead of a mapped drive is there an improvement?
FWIW, I tried the exact same steps in my own GoldMine 2016.1.0.179 and it worked flawlessly.
I agree, that is not an acceptable answer from support. Call back and escalate the issue.
Good morning, hope your weekend was well. To answer your first question, the file is actually getting moved to the desired location and the user can open up the file if they go directly to the folder via File Explorer. To answer your second question, I get the same results regardless of the location that the file is moved to.