- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-29-2016 06:50 AM
Hi folks,
New question about receiving attachments added to the table when responding by email not copied over to other table.
An inbound action is triggered when someone replies to a TASK email. Email body is copied to the TASK Work Notes, which triggers to copy the attachments to another table and close the TASK. When updating the Work Notes manually in the TASK (and adding attachments), the TASK get closed (by business rule) and Attachments are copied over to the other table. Unfortunately this is not working for the inbound action.
Funny detail is when TASK has already attachment, the current attachments are copied over using the inbound action, which looks like the attachments are not fully uploaded when Business Rule to copy attachments is triggered....
Who can help me with this?
Many thanks!
-- Titus
Solved! Go to Solution.
- Labels:
-
Team Development
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-30-2016 06:48 AM
Hi Titus,
I guess pasting the script I supplied into the inbound action isn't working...?
In theory it should work with any inbound email action.
What the script should do is update any attachments that are currently linked to the email that is being processed to the target record identified by the inbound action, so in your case a "u_finance_task" record. This should mean that the attachments are linked to this record before your business rule runs (which I guess is the one that then copies/moves the attachments up to the parent table ("u_finance").
If it isn't working you could add some logging, for example:
var sysAttach = new GlideSysAttachment();
var emailSysId = sys_email.getUniqueValue();
gs.log("Email sys_id is: " + emailSysId, "TITUS");
if (emailSysId) {
var sysEmailAttachments = sysAttach.getAttachments("sys_email", emailSysId);
gs.log("Number of attachments found: " + sysEmailAttachments.getRowCount(), "TITUS");
gs.log("Updating attachments to table: " + current.getTableName() + " and sys_id: " + current.getUniqueValue(), "TITUS");
while (sysEmailAttachments.next()) {
sysEmailAttachments.setValue("table_name", current.getTableName());
sysEmailAttachments.setValue("table_sys_id", current.getUniqueValue());
sysEmailAttachments.update();
}
}
After testing just check the System Log->All for messages where source is "TITUS".
Regards,
Nigel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-29-2016 07:54 AM
Hi Titus,
Just to double check I've understood what is happening:
1. When your business rule on the Task table is triggered it closes the task and copies the current set of attachments on that Task to another table
2. When the Task is updated by the inbound email action and the business rule is triggered ALL of the attachments are not copied
3. The attachments that are not copied are the ones on the inbound email that set the Task to closed
If I've got that right I think I know what is happening (and I think you were on the right track as well).
An inbound email action will first run the script which in your case is to update the task which in turn triggers your business rule.
Once the script has completed the inbound email action code will then link the attachments to the Task record and so this is too late for your business rule.
One thing you could try is to move the attachments as the first thing in your inbound email action script. The attachments will already exist but will be linked to the inbound email. An example of script to do this is:
var sysAttach = new GlideSysAttachment();
var emailSysId = sys_email.getUniqueValue();
if (emailSysId) {
var sysEmailAttachments = sysAttach.getAttachments("sys_email", emailSysId);
while (sysEmailAttachments.next()) {
sysEmailAttachments.setValue("table_name", current.getTableName());
sysEmailAttachments.setValue("table_sys_id", current.getUniqueValue());
sysEmailAttachments.update();
}
}
Only downside to this approach is it will move the attachments whether the inbound script is successful or not but I guess this doesn't fail very often!
Hope that helps.
Regards,
Nigel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-29-2016 10:22 AM
Thanks Nigel,
You're correct with you understanding!
I copied the script into the inbound action and not sure if I changed correctly to have it pointed to the correct table(s)
Inbound action is targeting to the FTASK (u_finance_task) with the u_finance as the parent table....
Are you able to help me out to update your piece of script?
Thanks,
Titus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-30-2016 06:48 AM
Hi Titus,
I guess pasting the script I supplied into the inbound action isn't working...?
In theory it should work with any inbound email action.
What the script should do is update any attachments that are currently linked to the email that is being processed to the target record identified by the inbound action, so in your case a "u_finance_task" record. This should mean that the attachments are linked to this record before your business rule runs (which I guess is the one that then copies/moves the attachments up to the parent table ("u_finance").
If it isn't working you could add some logging, for example:
var sysAttach = new GlideSysAttachment();
var emailSysId = sys_email.getUniqueValue();
gs.log("Email sys_id is: " + emailSysId, "TITUS");
if (emailSysId) {
var sysEmailAttachments = sysAttach.getAttachments("sys_email", emailSysId);
gs.log("Number of attachments found: " + sysEmailAttachments.getRowCount(), "TITUS");
gs.log("Updating attachments to table: " + current.getTableName() + " and sys_id: " + current.getUniqueValue(), "TITUS");
while (sysEmailAttachments.next()) {
sysEmailAttachments.setValue("table_name", current.getTableName());
sysEmailAttachments.setValue("table_sys_id", current.getUniqueValue());
sysEmailAttachments.update();
}
}
After testing just check the System Log->All for messages where source is "TITUS".
Regards,
Nigel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-11-2020 04:54 PM
Thank you...work like a charm!