How to change the field on parent form based on child record.

[hsingh]

I have change record with three tasks underneath it   Coding,Code review and documentation. How can I make the close notes mandatory when the code review task is complete. I tried UI policies as well as client script can you help me with an example how is it possible?

[Bhavesh Jain1]

Write a business rule on change task table BEFORE update when state changes to Complete.

Script : Query if parent close notes are filled in.

If yes, allow submit

else

gs.addErrorMessage('Please fill the close notes in the parent change record');

current.setAbortAction(true);

[mduluk]

So to make sure,   Person A closed the code review, and then Person B needs to update the close notes the next time they open the change request.     The easiest way to do it is to add a check box to the change request table, but not put it on the form.   Call it something like u_code_reviewed.   Write a business rule that runs when the code review task is complete that sets the checkbox to true.   Then your ui policy can say if u_code_reviewed = true, close notes are mandatory.

You might be able to skip the checkbox and just set the close notes mandatory via the business rule, but I don't know if that will carry over if another person opens the change request later.

[Jared Healy2 · Accepted solution]

For the functionality you describe, the best bet is a Display business rule for the Change Request table along with a client script to enforce the mandatory field. If you haven't used display business rule, they are quite useful. I just searched for the Wiki article but am having trouble finding it. Essentially the display business rule allows you to run code on the server side and then populate variable values into "g_scratchpad" which is then accessible on the client side when the form is displayed.

/***************************************************************

* Display business rule to be placed on the change_request table

***************************************************************/

// Scratchpad variable for your required field set to false

// until the condition is met

g_scratchpad.requireCloseNotes = 'false';





// Query the change task table for child tasks of this change

var cTask = new GlideRecord('change_task');

cTask.addQuery('change_request',current.sys_id);

cTask.query();

while(cTask.next()){

   // Loop through the tasks and validate the states or data you care about

   if(cTask.short_description == "Code Review" && cTask.state == '3')

             g_scratchpad.requireCloseNotes == 'true';

}









/*************************************************

* Client script to be placed on the change_request

* table. Must also have the business rule to work.

* Client script should be onLoad.

*************************************************/

function onLoad() {

   if(g_scratchpad.requireCloseNotes == 'true')

             g_form.setMandatory('close_notes', true);

}

Hopefully that helps.

[jim pisello]

Assuming there is some information in the Code Review task that is not likely to change (and thus can be relied upon when querying the Change Task records), I'd write an onSubmit client script that makes a synchronous AJAX call to a script include. The script include would query all Change Tasks associated with the current Change Request looking for closed Code Review tasks. If any are found, return something to the client script to indicate that (a "true" or "false" string for example). That indicator can be used in an IF statement to determine whether Close Notes have been added to the change request and if not, alert the user, abort the submission and make the Close Notes field mandatory.

Otherwise, I like Mike Duluk's answer as well, though this requires adding new fields to the Change Request table. That's not a big deal if it's only needed for a limited number of different change types, but if you start throwing new fields onto the table for each different kind of Change you're processing, the table can get mucked up with fields that are useful only in narrow circumstances. If you do pursue this option I'd urge you to fully document the field, including its specific uses and the circumstances under which it is expected to be used.

[Jared Healy2]

Hey Jim,

Good points. Ajax would be more appropriate if there were timing concerns such as someone opens the change request to modify and right after that the change task for code review is completed. For both the display business rule and the change field (any solution that is business rule based), the values wouldn't be refreshed until the request is loaded again.

Ajax is great for this type of scenario as it's checking the states on the server at the exact moment you click submit. But if you haven't implemented it before, it can be a little confusing. But if a timing issue like this isn't a concern then a business rule solution would work as well using a database field or g_scratchpad.