This would need to be a search and link with the Attachment Object, I have been playing with it this evening and got it working but its rather odd so would like some feedback (system version 2016.1.1 Premise)
Create a new pick list
Now here is the odd bit its uses $([Journal#Email.]ParentLink_Category). All attempts so far to filter on $([Journal#Email.]ParentLink_RecID) are not working but the ParentLink_Category seems only to provide a limited list to my current Incident, not sure why.
Add a new Quick action to Journal.Email
Add a new button to Journal.Email for the select attachment and add the QA created above.
Its a start not sure why it works given the pick list setup (I have reset my cache and a few other bits to figure it out).
Hope this helps.
Great idea, I appreciate it!
Just tested it in 2015.2 On-Prem. It works fine with ParentLink_Category as long as you only need to use the attachment once.
Using Parentlink_Category doesn't make any sense to me as well but it works.
I'm pretty sure they do some undocumented filtering afterwards using LINQ or JS..
The "Search and Link" is basically updating the ParentLink_RecID in the Attachment table afterwards.
So if you want to use the same attachment in two different Emails you need to refer to Journal#Email somehow, ideally using the RecId. But I couldn't get it working yet to show me all the email attachments as well.
For some reasons the "ParentLink" property in Attachment is always null.
That's why we can't use it:
- That's how it gets translated when you use "ParentLink Equal To $([ValidationList]ParentLink_RecId)":
SELECT TOP 501 Attachment.RecId, Attachment.ATTACHNAME FROM Attachment WHERE (NULL IS NULL) ORDER BY Attachment.ATTACHNAME, Attachment.RecId
- That's how it gets translated when you use "ParentLink Equal To $([ValidationList]ParentLink)":
SELECT TOP 501 Attachment.RecId, Attachment.ATTACHNAME FROM Attachment WHERE (NULL = '1EF01D55A53341E8B891F0425D8A21EF') ORDER BY Attachment.ATTACHNAME, Attachment.RecId
The only option I can currently think of is to "re-link" the attachments back to the Incident after the mail is sent.
Even if it works technically, I don't like to have unneccessary database writes. I will open up an Incident to get the ParentLink working instead of finding workarounds for bugs.
Besides this, the Prompt() function is essentially a 1:1 mapping but ideally I would like to have a CheckboxList as it was in HEAT7.
Generally I just do not understand why HEAT removed many useful features which worked in HEAT7 (convert to SR, search constraints, related attachments, one-click report generation in a given format etc..)
You make a good point about the attachment re-linking to Journal.Email which is not be best idea as it removes it from the parent object. Linking the original attachment back to the parent object is also not a good option as the email then looses its attachment which break the audit trail for the email.
Before I continue the next section...WARNING the following has been carried out in a test system and should be fully tested before applying to any live systems. It comes with no guarantee or warranty, always backup your database before carrying out changes
So how does this work, we can use a new relationship on the attachment object for the Journal.Email that would then leave the attachment still connected to its original parent object.
- Create a new link field on the attachment Object AC_JournalEmailLink.
- Change the JournalEmailContainsAttachment relationship (although it says its contains relationship in the title its actual associated which is good as we don't want to delete the attachments):
That is it as the relationship name doesn't change nothing else is needed and keeps inline with the rest of the system. You will have to copy all the ParentLink_RecID's (on the attachment table) over to your new field for the existing relationships to be maintained.
Other considerations, things to play with:
- Could swap to a link table (fusion link) then you could have multiple emails using the same attachments.
- A full system test would be advised as this is a fairly major change to core functionality.