copy attachments from request to RITM

kunal16
Tera Expert

Hi,

I have a requirement to copy all the attachments from Request to the corresponding RITMs.

I have written an After-Insert Business rule on the Request table to achieve the same. But it seems the code is not working as expected.

Name: Copy Attachments to RITM

Table: Request (sc_request)

When to run: After - Insert

Script:

(function executeRule(current, previous /*null when async*/) {

  // Add your code here

  var ritm = new GlideRecord('sc_req_item');

  ritm.addQuery('request', current.sys_id);

  ritm.query();

  while(ritm.next())

  {

  GlideSysAttachment.copy('sc_request', current.sys_id, 'sc_req_item', ritm.sys_id);

  }

})(current, previous);

Any lead will be appreciated. Thanks in advance!!

22 REPLIES 22

I am going to agree with @kalai above, I don't recommend copying attachments:

  • Bloats the database size
  • If edits are done on the parent request, those won't be reflected in the child req items

 

You can make a copy of the Ticket Attachments widget and tweak it to show the parent request's attachments.

Hi Michael,

Would you be able to detail the tweaking of the Ticket Attachment widget to show the attachments on the portal.  Our attachments are associated with the RITM.  I have already created a related list on the REQ form, but the attachment does not show on the portal when being viewed by an approver.

Thanks

Caliban

Caliban, I see you are going down the path of copying attachments.  As others have chimed in since my post again I would strongly recommend against that.

  • In the Widget Editor, pull up the Ticket Attachments widget
  • click the "hamburger" button and select Clone Ticket Attachments
  • Change the Server script to something like below:
(function() {
	data.sys_id = input.sys_id || options.record_id || $sp.getParameter("sys_id");
	data.table = "sc_request";
	data.sys_id = _getRequestID("sc_req_item", data.sys_id);
	data.maxAttachmentSize = parseInt(gs.getProperty("com.glide.attachment.max_size", 1024));
	if (isNaN(data.maxAttachmentSize))
		data.maxAttachmentSize = 24;
	data.largeAttachmentMsg = gs.getMessage("Attached files must be smaller than {0} - please try again", "" + data.maxAttachmentSize + "MB");
	data.attachmentSuccessMsg = gs.getMessage("Attachment successfully uploaded");
	
	if (!data.table || !data.sys_id)
		return;

	var gr = new GlideRecord(data.table);
	if (!gr.isValid())
		return;
	
	if (!gr.get(data.sys_id))
		return;

	if (input && input.action == "deleted") {
		gr.comments = input.action + " an attachment";
		gr.update();
	}

	data.canWrite = gr.canWrite();
	data.canAttach = gs.hasRole(gs.getProperty("glide.attachment.role")) && GlideTableDescriptor.get(data.table).getED().getAttribute("no_attachment") != "true";
	data.canRead = gr.canRead();

	function _getRequestID(table, id) {
		var rec = new GlideRecord(table);
		if (rec.get(id)) {
			return rec.getValue('request');
		}
		return id;
	}
})();

 

Then add this widget to your page.  Here is an example where I just added it below the OOB attachments one.

find_real_file.png

Hi Michael,

Thanks for your response.  I completely agree that duplicating the attachments is not the way to go and having related lists is the way forwards.  

However the request from the Product owner is to be able to view the attachments on the Request in the portal not the console, and due to prior amendments the attachments are added to the RITM not the REQ when requested.

I will outline the issues that everyone has stated in this thread in the hope that this enhancement does not proceed

randrews
Tera Guru

I can't emphasize enough how much i agree with kalai you shouldn't be creating copies of attachments in your system... you should instead create related lists that SHOW the SAME attachment...

 

what happens here when someone updates the attachment on the main request.. you know have an invalid copy on EACH item.. so now you are creating rules to update those....

 

so it is NOT just a matter of cluttering up the attachment table with duplicate records but of keeping the data that is attached to records up to date!