Service Portal - adding 'Close Notes' to Ticket Conversations Widget

[mcarpenter]

Hi All:

We have a requirement to add close notes to the ticket conversations widget in Service Portal.   We need there to be notes in the request details form about why a ticket has closed so that the customer has a point of reference other than email.   We had been using a workaround Client Script that auto-populates the Close Notes into the Comments field, however this is causing confusion with the technicians.

Has anyone else already added this filed to this widget?    

[ndt13]

What are the conditions that trigger your BR?  There might be another BR that is triggering this one again, so may need to change the order of your business rules or you may need to modify the conditions after you figure out what is causing this to run twice.

Does it happen all of the time or just sometimes? Another thing that could be causing this - if there are mandatory fields that are left empty when the form is submitted, the BR might run before the onSubmit error occurs.

[Charlotte Pakes]

This may be too late for you, but may be helpful for others.

I've done this for Incident (we don't use Close notes on Request, just Additional comments). Our solution displays the Close notes in the Conversation View in the Portal without adding them to Additional comments. If the Incident is reopened, the Close notes are then copied and saved into Additional comments so the customer has a record of what they were.

From what I remember of implementing this, I looked at how the widget built the 'entries' for the Conversation view, and added code following this convention to create a 'Close notes' entry, then inserted that into the array of entries created in the mergeStreamEntries function.

Hope this is helpful.

[Phonsie Hevey1]

Following from Charlotte's reply I added some code to the server script field of a clone of the std_ticket_conversations widget. This works well as long as the closed_by and closed_at fields are set along with the close_notes.

data.hasWritableJournalField = false;
data.hasReadableJournalField = false;
if (data.canRead && !data.isNewRecord) {
	data.stream = $sp.getStream(data.table, data.sys_id);
	
	// Add close notes to the activity stream
	data.close_notes = $sp.getField(gr, 'close_notes');
	data.closed_at = $sp.getField(gr, 'closed_at');
	data.closed_by = $sp.getField(gr, 'closed_by');
	if (data.close_notes.value) {
		data.stream.entries.push({
			"login_name": data.closed_by.display_value,
			"user_sys_id": data.closed_by.value,
			"initials": buildInitials(data.closed_by.display_value),
			"sys_created_on": data.closed_at.value,
			"field_label": "Close notes",
			"name": data.closed_by.display_value,
			"value": data.close_notes.display_value,
			"element": "comments"
		});            
	}
	
	// Journal fields come in correct order already
	// so grab the first 2 writeable fields
	if ('journal_fields' in data.stream) {
		var jf = data.stream.journal_fields;
		for (var i = 0; i < jf.length; i++) {
			if (jf[i].can_read === true)
				data.hasReadableJournalField = true;
			if (jf[i].can_write === true) {
				data.hasWritableJournalField = true;
				if (!data.primaryJournalField)
					data.primaryJournalField = jf[i];
				else if (data.includeExtended && !data.secondaryJournalField)
					data.secondaryJournalField = jf[i];
				else
					break;
			}
		}
	}
}

It seems like the initials are got from the user_sys_id field rather than the initials field.

Kind regards,

Phonsie