Make checklist items read only once task is closed

gowthamanbalu · ‎08-28-2017

Hello All,

I would like to know if there is a way to restrict checklist items in the record form being updated or modified after record moved to closure state.

Regards,

GB

francescodotti · ‎09-27-2017

Hi,

after trying with ACL and Client scripts, I found a very simple way.

You have to modify the UI Macro inline_checklist_macro. I added a condition linked to the state of the containing task

inline_checklist_macro

<?xml version="1.0" encoding="utf-8" ?>

<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">

<g2:evaluate>

var isBrowserSupported = (GlideVTBCompatibility.getCompatibility() != 'block');

var isNewUI = gs.getProperty('glide.ui.doctype', 'false') == 'true';

var isNewRecord = true;

if (isBrowserSupported $[AMP]$[AMP] isNewUI) {

var sysID = current.getUniqueValue();

var tableName = current.getTableName();

isNewRecord = current.isNewRecord();

// get the checklist ID for this record

var checklistID = null;

var checklist = new GlideRecord("checklist");

checklist.addQuery("document", sysID);

checklist.addQuery("table", tableName);

checklist.query();

if (checklist.next())

checklistID = checklist.getUniqueValue();

if (current.state == -5 || current.state == 3 ) { // Pending or Closed

var readOnly = "true";

} else {

var readOnly = "false";

}

</g2:evaluate>

<body>

<j2:if test="$[!isNewRecord]">

<g:macro_invoke macro="checklist_template" readonly="$[readOnly]" record="$[sysID]"

table="$[tableName]" checklistid="$[checklistID]"/>

</j2:if>

</body>

</j:jelly>

Thanks.

PS: Hit like, Helpful, Correct, if it answers your question.

View solution in original post

francescodotti · ‎09-27-2017

Hi,

after trying with ACL and Client scripts, I found a very simple way.

You have to modify the UI Macro inline_checklist_macro. I added a condition linked to the state of the containing task

inline_checklist_macro

<?xml version="1.0" encoding="utf-8" ?>

<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">

<g2:evaluate>

var isBrowserSupported = (GlideVTBCompatibility.getCompatibility() != 'block');

var isNewUI = gs.getProperty('glide.ui.doctype', 'false') == 'true';

var isNewRecord = true;

if (isBrowserSupported $[AMP]$[AMP] isNewUI) {

var sysID = current.getUniqueValue();

var tableName = current.getTableName();

isNewRecord = current.isNewRecord();

// get the checklist ID for this record

var checklistID = null;

var checklist = new GlideRecord("checklist");

checklist.addQuery("document", sysID);

checklist.addQuery("table", tableName);

checklist.query();

if (checklist.next())

checklistID = checklist.getUniqueValue();

if (current.state == -5 || current.state == 3 ) { // Pending or Closed

var readOnly = "true";

} else {

var readOnly = "false";

}

</g2:evaluate>

<body>

<j2:if test="$[!isNewRecord]">

<g:macro_invoke macro="checklist_template" readonly="$[readOnly]" record="$[sysID]"

table="$[tableName]" checklistid="$[checklistID]"/>

</j2:if>

</body>

</j:jelly>

Thanks.

PS: Hit like, Helpful, Correct, if it answers your question.

ty_roach · ‎11-27-2019

Suggest using Checklist Pro, a ServiceNow store application that works in both classic UI as well as in the Service Portal.

The problem with the OOB checklists is that they are unreliable, meaning, people can change the content of the checklist item after the fact, add items, delete items, change items. There's also no guarantee that the same checklist will appear for same situation. There is no way to restrict who can edit the checklist or when it can be edited (like do you really want people changing checklist responses after the record has been closed).

Enter Checklist Pro. We built Checklist Pro to solve all those problems and more. Checklist Pro application administrators can define when checklists get created and associated with records in a table (any table - not just those that extend TASK), when these checklists can be edited, when the associated record is considered "closed" (and thus should prohibit further checklist updates). We even added the ability to define "Required" checklist items that allow enforcement, thereby preventing a record from closing unless the required items are completed. We've built convenience Database Views to go with the most common checklist tables, which include TASK, SYSAPPROVAL_APPROVER, CMDB_CI.

They work in the Service Portal as well as in the Classic UI.

They'll work with other Scoped Applications (like HR or SecOps or even custom scoped apps & tables).

For more information contact TyGR LLC or goto our youtube channel to see it in action.

Also - besides the classic Checkbox Item, Checklist Pro allows you to include various data types, including Textbox fields, Date, Integer, Custom Choice Lists and Reference fields.