Client Script to check Work Notes have been entered.

[John Prouty]

I want a Client Script that will detect if a Work Note has been entered for the record.  Once data is entered in the Work Note, SN moves the data to the Activities Log, so the Work Notes field is empty.  But the Activity Log contains all kinds of data (changes to fields, opened by data, etc.).  How do I find only Work Notes entries?

[John Prouty]

I am trying to build a Client Script to make sure that when the user changes the state to "Cancel", that they explain in the Work Notes why they did it.  But it they entered a note before changing the state and save the record and then change the state. the field will be empty, but they did enter an explanation.  So it should pass the business rule, whereas checking the work notes, it would fail.

Is there a way to query the Journal?

[Willem]

You can use current.work_notes.getJournalEntry(1); for the last work note.

Or current.work_notes.getJournalEntry(-1) for all work notes.

[John Prouty]

Is there a way to getJournalEntry for a specific type (Work Notes, versus State or Priority or Opened or Updated...).

[Willem]

Alternatively you can query (via script) the 'sys_journal_field'-table for your work note entry:

[rajneeshbaranwa]

I do not think this is the best way to solve the business case. In above scenario you have to define what duration (before changing the state ) you consider as valid duration to enter cancel reason. 

A user could have entered previous work note 1 day before changing state but there is great chance that it is not the reason for cancellation, while a work note update 5 minutes before has great chance of being cancel reason.

Once you determine the duration, you have to capture previous work note entry and have to find how many minutes before this entry was added. If it comes within your duration threshold then it is a valid cancellation reason entry or else it is not. 

This is complicated way of doing this.

Rather than that I would suggest you to create a business rule to ensure users are entering cancellation reason whenever they change status to cancelled, otherwise prompt them an error message. You might have to conduct user training session, but eventually users will learn to enter cancellation reason while cancelling the ticket.