had a request from a client recently to generate a random list of records from a given table (specifically the Configuration Item table). These items would be used as a pool of records for a random audit of the records in that table. I don’t think this will be used all that often but I figured I’d throw it out here so that people could use it if they needed it. Here’s the code…

var tbl = 'cmdb_ci'; //Query from this table
var returnNum = 5; //Return this number of records in the array
var answer = new Array();

//Set up the GlideRecord query
var rec = new GlideRecord(tbl);
rec.query();
if(rec.hasNext()){
   //Get the number of records queried
   var numRecs = rec.getRowCount();
   //Return 'returnNum' number of random records in an array
   for(i=0; i<returnNum; i++){
      //Get a random number between 0 and 'numRecs'
      var randomNumber = Math.floor(Math.random()*numRecs);
      //Set the row number to 'randomNumber'
      rec.setLocation(randomNumber);
      //Add the random record to the array
      answer.push(rec.getDisplayValue().toString());
   }
}
gs.log(answer.join()); //Log the output
return answer; //Return the array

ne of the most common LDAP integration requirements is to disable users in Service-now when they become disabled in the LDAP source.
It is probably worth mentioning that you always want to deactivate user records (and most other records too) in Service-now instead of deleting them. Once a user record has been created in Service-now it should always remain in Service-now because that record could be linked to hundreds of other records (tasks, CIs, etc.). Deleting the record kills the relationship to those other records. Deactivating the record keeps that relationship in place.
Because the exact steps to set up this behavior vary depending on your LDAP setup and processes, this configuration isn’t something that can be predefined in Service-now. Typically a Service-now consultant assists with this setup and specific requirements are determined on a client-by-client basis. It has been my experience that there are two common approaches that can be used to disable Service-now users from LDAP. This article explains these approaches and how you can implement the needed functionality.

The basic idea to keep in mind when you set up either of these configurations is that the system needs to see some consistent data indicator per user object in LDAP that the user has been disabled. Generally this indicator is membership in a specific OU (which could be identified by parsing the ‘dn’ attribute) or through the use of the ‘useraccountcontrol’ attribute…or both. The bottom line is that Service-now cannot disable users from an external source unless it receives consistent data about those users indicating which ones should be disabled and which ones should not. With either of the approaches below this data MUST come into Service-now by way of an import set table where it can be evaluated and transformed. If these terms seem foreign to you you’ll want to familiarize yourself with Service-now Import Sets before you continue.

Disabling users in Service-now from an LDAP source typically involves one of these two methods…

1Separate import process from LDAP just for disabled users: In this approach you don’t attempt to handle disabled users through the standard LDAP import at all. Instead, you (or your LDAP Admin) produce a separate extract from your LDAP source that contains the users that need to be disabled. This extract can then be used in a separate import to simply set the ‘active’ flag on every record in the import to ‘false’. The entire script (‘target.active=false’) can be placed in the ‘Script’ field directly on the ‘Table Transform Map’ record.

The benefits to this solution are that the scripting is extremely simple and you don’t have to worry about identifying which users are active or inactive in Service-now. You simply deactivate everything in the feed! An additional benefit is that you don’t have to bring a bunch of users into a temporary import table just to see if they should be deactivated or not. Depending on the number of users records that have to be evaluated in your transform (and the number of attributes being brought in per record), this may be the only way to disable users without impacting the performance of the LDAP load. The obvious drawback to this method is that you have to have a separate process to create and drop the extract of disabled users in a location where your Service-now data source can pick it up.

2Open up the LDAP OU filter to bring everything in to your import set table (including disabled users) and then ignore inserts of disabled users based on certain script conditions: The sample ‘Users’ OU definition that Service-now provides in its out-of-box LDAP sample contains a filter that looks like this…

This filter is important because it defines what user records will be brought into the Service-now import set table to be evaluated. The red-highlighted portion of the filter in the image above represents the common problem faced when you try to disable users from an LDAP import. What it basically says is that all disabled users in your LDAP source should be filtered out. This is great but you can’t very well disable a user record when you cannot see because it is disabled! The solution in this case is to remove that portion of the filter so that you can see all of those user records. “Seeing” those user records means that they are all brought into your temporary import set table so that they can be evaluated by an import set transform and disabled if necessary.

Once those records hit your import set table your transform takes over and can manipulate the target records in the Service-now user table as required. The exact script that you write depends on the LDAP attributes that you bring into Service-now that indicate a disabled user. Here are a couple of common examples that I’ve used before to filter based on OU (from the ‘dn’ attribute which comes into your import table as ‘u_dn’) and the ‘useraccountcontrol’ attribute (which is usually 514 or 546 for a disabled user). For more information on the ‘userAccountControl’ attribute see this page.

//Deactivate LDAP-disabled users during transform based on 'userAccountControl' attribute
if(source.u_useraccountcontrol == '514' || source.u_useraccountcontrol == '546'){
   target.active=false;
   target.locked_out=true;
}

//Deactivate LDAP-disabled users during transform based on OU membership in 'dn'
if(source.u_dn.indexOf('OU=Disabled Accounts') > -1){
   target.active = false;
   target.locked_out = true;
}

The last piece to this solution is VERY IMPORTANT. Because you’ve opened your OU definition filter so that you can see enabled and disabled accounts from your LDAP source, Service-now will evaluate all of those records. That part is desirable. What isn’t desirable is the insertion of 50 thousand inactive LDAP accounts from 5 years ago that you don’t want to be created in Service-now. You should NEVER create a user record in Service-now for a user that is inactive. The only thing you want to do is disable any existing Service-now users as they are disabled in your LDAP source. In order to prevent this from happening you need to set up a script that runs before the transform of each record and identifies if a record is disabled AND is being inserted. If an insert of a disabled user is happening then the operation should be ignored by the transform. Here’s what that ‘onBefore’ transform map script looks like…

Please note that the exact content of this script depends on the way disabled users are defined in your LDAP source. You may need to change this script to meet the needs of your environment.

//Ignore any insert of a disabled record as defined by the 'userAccountControl' attribute
var uc = source.u_useraccountcontrol;
if((uc == '514' || uc == '546') && action == 'insert'){
   ignore = true;
}

The script examples above are given to show the different parts of solution #2. If you put all of it together you can produce a very elegant solution that only requires a single script. Here’s a great script that I got from Valor Poland that puts all of this together in a single script…and makes it so that you don’t have to rely on hard-coded ‘userAccountControl’ values. It also allows you the option of reactivating LDAP user accounts as well. The script can be placed in the ‘Script’ field of the ‘Table Transform Map’ record or in an ‘onBefore’ transform map script. Very, very cool.
Note that this script makes use of the ‘userAccountControl’ attribute. If you are using another method to indicate disabled users in your LDAP source then this script wouldn’t apply.

//Deactivate LDAP-disabled users during transform based on 'userAccountControl' attribute
//Convert the userAccountControl attribute back to a hex value
var ctrl = parseInt(source.u_useraccountcontrol, 10);
ctrl = ctrl.toString(16);

//The only digit we care about is the final one
//A final hex digit value of '2' in 'ctrl' means disabled
if(ctrl.substr(-1) == "2"){
   //Deactivate and lock the user account
   target.active = false;
   target.locked_out = true;
   //Ignore any insert of a disabled record
   if(action == 'insert'){
      ignore = true;
   }
}
else {
   //Optional:  Reactivate and unlock the user account
   //target.active = true;
   //target.locked_out = ctrl.substr(-2, 1) == "1";
}

ost Service-now administrators and consultants know how to configure and use UI Actions. UI Actions are UI elements that can show up on a form or a list as a button, link, or context menu. When these UI elements are clicked they execute some JavaScript. Most of the time UI Actions are used to perform some server-side update to a record or records. In other cases, you can use the ‘Client’ checkbox on the UI Action record to execute some client-side JavaScript (including checking for mandatory fields).
But what if you need to do both? The classic case is when you want to click a button to make an update to a record, but only if the user has provided the correct input first. An example would be a ‘Reopen Incident’ button that changes the state on an incident record from ‘Resolved’ to ‘Active’. Usually you want to require the user to provide some sort of comment or additional information explaining why they are reopening the ticket. The problem is that you don’t always want the ‘Comments’ field to be mandatory so the validation needs to happen at the time the ‘Reopen Incident’ button gets clicked. Validation of mandatory fields needs to happen client-side but the update to your record needs to happen server-side. How can you accomplish both of these things with a single UI Action? This article shows you how.

The basic format for using a Client Script and Business Rule in the same UI Action looks something like this…

//Client-side 'onclick' function
function runClientCode(){
   if(<CONDITION_TO_VALIDATE == false>){
      return false;  //Abort submission
   }
   //Call the UI Action and skip the 'onclick' function
   gsftSubmit(null, g_form.getFormElement(), '<button_action_name>'); //MUST call the 'Action name' set in this UI Action
}

//Code that runs without 'onclick'
//Ensure call to server-side function with no browser errors
if(typeof window == 'undefined')
   runBusRuleCode();

//Server-side function
function runBusRuleCode(){
   current.<field_name> = <value>;
   current.update();
   gs.addInfoMessage('You did it!');
   action.setRedirectURL(current);
}

So why does this work? I had to go to a Service-now developer to find out. The reason is that UI Actions can run scripts at two different times. The first time is when the UI Action gets clicked. When you define a ‘Client’ UI Action you also give that UI Action the name of a function in your ‘Script’ field to execute. This function has to be called explicitly (through the ‘onclick’ event) or it doesn’t run at all.
The second time is on the way to the server. This is how any UI Action without the ‘Client’ checkbox selected gets run. On the way to the server the entire UI Action script gets executed regardless of whether or not the ‘Client’ checkbox is checked. What this means is that any script you include in your UI Action that isn’t enclosed in a function will be run on the way to the server. The script above takes advantage of this fact by making a specific call to the ‘Client’ function, performing client-side validation, and then the UI Action calls itself if the client-side validation passes.
When the UI Action calls itself it bypasses the ‘onclick’ function because the button didn’t get clicked the second time. So the script continues to the first point where there is something to execute. At that point you can call your Server-side function! The only thing you need to be careful of is that you only call the Server-side function if the script isn’t running in the client anymore. That’s what the check in the middle does…and eliminates any browser errors saying that ‘current’ (or any other Server-side function or object) isn’t defined.

Here is a solution I’ve used in the past to give users the ability to reopen an incident record. The solution uses a UI Action button to check if the ‘Comments’ field has been filled in (this is the ‘Client-side’ portion). If the validation passes, then the incident record gets updated.

//Client-side 'onclick' function
function reopen(){
   if(g_form.getValue('comments') == ''){
      //Remove any existing field message, set comments mandatory, and show a new field message
      g_form.hideFieldMsg('comments');
      g_form.setMandatory('comments', true);
      g_form.showFieldMsg('comments','Comments are mandatory when reopening an Incident.','error');
      return false;  //Abort submission
   }
   //Call the UI Action and skip the 'onclick' function
   gsftSubmit(null, g_form.getFormElement(), 'reopen_incident'); //MUST call the 'Action name' set in this UI Action
}

//Code that runs without 'onclick'
//Ensure call to server-side function with no browser errors
if(typeof window == 'undefined')
   serverReopen();

function serverReopen(){
   //Set the 'State' to 'Active', update and reload the record
   current.state = 2;
   current.update();
   gs.addInfoMessage('Incident ' + current.number + ' reopened.');
   action.setRedirectURL(current);
}

ne of Service-now.com’s principal strengths comes from its extensible framework. Built into the framework is the ability to retrieve information using one of a myriad of methods. If you want to get data out of any table, you can get it via direct web services, using basic auth data retrieval, having it pushed to a client, FTP server or  linux server by using the scheduled data extract, and more.  However, there are times when none of these solutions give you a logical way to achieve what you want in a simple manner.  I will give two examples: 1) adding an item to a cart, 2) fetching an attachment from a record.  For tasks such as these, the flexible Scripted Web Services is the answer.

Scripted web services are used in many integrations where a product wants to accomplish something that doesn’t have a simple solution already built-in.

How to use Scripted Web Services

This functionality requires the Web Service Provider – Scripted plugin.

There are four parts to scripted web services: WSDL (generated for you), script, input variables, output variables.  The WSDL is created for you and is what you’ll use on the client side to access your new web service.  The script is simple JavaScript and performs the required action.  Within the script you retrieve the input variables that you expect the client to send your web services.  Those variables are references using request. notation.  Once the script nears an end, you can set the output variables – the data you want to send back to the client – by using  response. notation.

This is the most flexible way to receive SOAP data and to return whatever you wish to return.  Let me explain by solving to two problems mentioned above.

Ordering a Blackberry

var cart = new Cart();
var item = cart.addItem('e2132865c0a801650010e411699');
cart.setVariable(item, 'original', request.phone_number);

// set the requested for
var gr = new GlideRecord("sys_user");
gr.addQuery("user_name", request.requested_for);
gr.query();
if (gr.next()) {
  var cartGR = cart.getCart();
  cartGR.requested_for = gr.sys_id;
  cartGR.update();
}

var rc = cart.placeOrder();
response.request_number = rc.number;

The script is a simple example of how to order a backberrry for a specific user.  Phone_number and requested_for are sent via the soap client to the script and the scripted web service returns the request_number back to the client.  Something that would be very difficult to figure out using traditional web service methodologies is quite simple to do with using this technique.

Fetching an attachment from a task record

var StringUtil = Packages.com.glide.util.StringUtil;
var  gr = new GlideRecord("sys_attachment");
gr.addQuery("table_sys_id", request.sys_id);
gr.query();
if (gr.next()){
   var sa = new  Packages.com.glide.ui.SysAttachment();
   var binData =  sa.getBytes(gr);
   var encData =  StringUtil.base64Encode(binData);
   response.file_name = gr.file_name;
   response.table_name = gr.table_name;
   response.encodedAttachment = encData;
}
else{
   gs.log("Record not found");
}

Again, this is pretty straightforward.  What would be the alternative if direct web services were used?  Well, there would need to be a call to the sys_attachment record to find out the file_name, table_name, and associated task record.  Then there would need to be several more calls to fetch every attachment chunch (attachments are stored as chunks of data internally) only to reassemble the data client-side….not very friendly.

I created an update set for the fetch attachment record that you may download and apply to your instance: Fetch Attachment scripted web service.  Remember to enable the Web Service Provider – Scripted plugin before applying the update set.

maps (Business Service Maps) are a central feature of Service-now.com that allow users to view a visual representation of the Service-now CMDB and the Business Services and CIs that those services are composed of. Service-now BSM maps also allow you to display additional information about (and take action on) the CIs represented in the map through the use of BSM Map Actions. I was recently working to create a BSM Map Action that I wanted to display for particular types of CIs and I couldn’t see how to set up a condition that would allow me to identify the type of CI.
What I learned is that each BSM Map has certain information available through URL parameters and through a ‘Data’ object about each node on the map. I just had to find the right piece of information! The solution was to use something like the following in my ‘Condition’ field on my BSM Map Action definition.

this.getData('ci_type') == 'cmdb_ci_win_server'

This script basically says that the Map Action should not be displayed unless the CI is a Windows Server.

There are several different pieces of data that you can use to help you construct these conditions. Here is a script that I wrote to output this information in an alert message when a Map Action is clicked. The script can be placed directly in the ‘Script’ box on a Map Action record.

//Output data about a given Map Node
var mapData = '------Map Node Data------\n';
mapData += '--Access with: this.getID()--\n'
mapData += 'ID' + ' = ' + this.getID() + '\n\n';

mapData += '--Access with: this.getData("<Node Name>")--\n';
for(var n in this.data){
   mapData += n + ' = ' + this.data[n] + '\n';
}

//Output data about Diagram URL Parameters
var diaData = '\n\n------Diagram Parameter Data------\n'
diaData += 'Access with: this.diagram.getParam("<Parameter Name>")\n\n';
for(var p in this.diagram.params){
   diaData += p + ' = ' + this.diagram.params[p] + '\n';
}
alert(mapData + diaData);

common Graphical Workflow requirement in Service-now is to tell the workflow to wait for some trigger before continuing. The ‘Wait For condition’ activity is available out-of-box and is very simple to configure. Usually when working with Service Requests or Change Requests I am asked how you can set up the workflow to wait for completion of all associated tasks before closing the Request Item or Change Request ticket. This can be easily accomplished by using a script in your ‘Wait For condition’ activity to query for any associated tasks that are still marked as ‘Active’. If the task is marked as ‘Active’ then it hasn’t been closed yet and the workflow should wait for that closure. Here are some sample scripts that I’ve used before to wait for task completion on both Request Items and Change Requests.

The scripts below can be pasted into the ‘Wait For condition’ activity script field as shown here…

//Query for all tasks to see if they are inactive
var rec = new GlideRecord('sc_task');
rec.addQuery('request_item', current.sys_id);
rec.addQuery('active', true);
rec.query();
if(rec.hasNext()){
answer = false;
}
else{
//Continue
answer = true;
}

//Query for all tasks to see if they are inactive
var rec = new GlideRecord('sc_task');
rec.addQuery('request_item', current.sys_id);
rec.addNotNullQuery('wf_activity');
rec.addQuery('active', true);
rec.query();
if(rec.hasNext()){
answer = false;
}
else{
//Continue
answer = true;
}

//Query for all tasks to see if they are inactive
var rec = new GlideRecord('change_task');
rec.addQuery('change_request', current.sys_id);
rec.addQuery('active', true);
rec.query();
if(rec.hasNext()){
answer = false;
}
else{
//Continue
answer = true;
}

//Query for all tasks to see if they are inactive
var rec = new GlideRecord('change_task');
rec.addQuery('change_request', current.sys_id);
rec.addNotNullQuery('wf_activity');
rec.addQuery('active', true);
rec.query();
if(rec.hasNext()){
answer = false;
}
else{
//Continue
answer = true;
}

ere’s a cool tip that was just sent to me by my friend Jim Coyne. We collaborated to solve a problem that he had in his environment and this post shows the result he came up with. This post shows how you can manipulate records in the email log (sys_email table) when you have a need to change the contents or recipients of an email record. This isn’t something that should be relied upon heavily and I would consider it basically a last resort but it can prove very helpful in solving the right type of problem.

The problem in this example was that there were emails being sent from Jim’s Service-now system that contained sensitive information. It was necessary to send this information as part of an integration with a 3rd party system but they didn’t want to retain that information in Service-now to be viewed in logs and in the activity history of task records.

The solution that we talked about was to set up a business rule on the ‘sys_email’ table to intercept these emails immediately after they were sent and parse out the sensitive information. This way, the email could be sent to the 3rd party system, but there would be no record of that sensitive information retained in Service-now. Jim then went and did the hard work and here is the resultant business rule…

var index = current.body.indexOf('Service Request Form');
if (current.recipients == 'abc@xyz.com' && index != -1 ){
   current.body = 'Log information sent to 3rd party system';
   current.body_text = 'Log information sent to 3rd party system';
}

often get the request to set up access for group managers to be able to manage the members of their groups in Service-now. This configuration isn’t too difficult to set up but it does involve a few different pieces. It’s also important to consider your group setup in your system before allowing access in this way. If you are bringing in group memberships from a data source like LDAP for example, the last thing you want is to have your managers manually changing those group memberships within Service-now. The configuration shown below could be easily customized to allow access only to non-LDAP groups if you needed to do both however.

This solution requires you to modify the out-of-box ACLs for the ‘sys_user_grmember’ table. You’ll also need to modify the ‘Omit Edit Condition’ field for the ‘Group Members’ related list on the ‘Group’ form. These configurations are outlined below.

var answer = false; //Restrict access by default
if(gs.hasRole('user_admin') || current.group.manager == gs.getUserID()){
answer = true; //Allow access if user has 'user_admin' role or is group manager
}
answer;

var answer = true; //Hide the 'Edit' button by default
if(gs.hasRole('user_admin') || parent.manager == gs.getUserID()){
answer = false; //Show the 'Edit' button if user has 'user_admin' role or is group manager
}
answer;

That should do it! You may also want to create a ‘Groups’ module that is available for the role that your group managers have. This will allow your group managers easy access to the groups in the system (and with a filter access to the groups that they manage).

efined Related Lists can be a very simple and useful tool to provide users with information in a related list directly on a form (even if that information is not directly associated with the record being viewed). The Service-now wiki contains documentation on this topic so I won’t cover that here. The point of this article is to point out something that often gets overlooked when working with Defined Related Lists and to share a few Defined Related Lists that I’ve used in the past.

One of the familiar defined related lists is the ‘Incidents by Same Caller’ list that you can display at the bottom of your incident form. The name says it all, but it looks something like this…

If you navigate to ‘System Definition -> Relationships’ and open up the ‘Incidents by Same Caller’ relationship record you’ll see that it uses the following query to produce the resultant related list…

current.addQuery('caller_id', parent.caller_id);

But what happens when we set the Caller field with an empty value?

The image above shows that you’ll get exactly what you’re supposed to get, but probably not what you want. Depending on your setup, there might not be a whole lot of value in showing a list of incidents with no caller…at least at the bottom of your incident form. The solution to this is to filter out any records where the field you are querying is empty. In this case, we want to filter out any records where the Caller field is empty like this…

current.addQuery('caller_id', parent.caller_id);
current.addNotNullQuery('caller_id');

Adding the ‘addNotNullQuery’ line gives us the result we would expect at the bottom of our incident form.

Here are a few other examples of defined related lists I have implemented in the past. Please share any defined related lists you have come up with by commenting on this post below!

current.addQuery('task', parent.sysapproval);
current.addNotNullQuery('task');

var qc = current.addQuery('table_sys_id', parent.sys_id);
qc.addOrCondition('table_sys_id', parent.request_item.sys_id);
qc.addOrCondition('table_sys_id', parent.request_item.request.sys_id);
current.addNotNullQuery('table_sys_id');

few months ago I wrote about copying change requests using a UI action. While that method works great, it does require you to specify each and every field and value that you want to populate into the new change request. If you’ve got a lot of fields to copy over then you might end up with a pretty big script and a lot of items to copy over. You also need to be aware of any new fields that get added after you create the script and make sure that they get copied if necessary.

The following method works in much the same way, but it copies by performing an insert against the current record (rather than starting from a brand new change record and supplying each value). Because of this, you’re concerned about overriding any of the values (such as start and end dates) that you don’t want to be copied over from the record you are copying. This method works better if you know you want to copy over all (or the majority) of the field values from a given change.

copyChange();
function copyChange() {
//Get the current sys_id value for querying
var chgID = current.sys_id.toString();
//Initialize new change for insertion
var newChange = current;
newChange.requested_by_date = 'NULL';
newChange.start_date = 'NULL';
newChange.end_date = 'NULL';
newChange.calendar_duration = 'NULL';
newChange.opened_at = current.opened_at;
newChange.opened_by = current.opened_by;
newChange.sys_created_on = current.sys_created_on;
newChange.sys_created_by = current.sys_created_by;
current.insert();

//Copy attachments for this change
Packages.com.glide.ui.SysAttachment.copy('change_request', chgID, 'change_request', newChange.sys_id);

//Copy associated tasks and CIs
copyTask(chgID);
copyCI(chgID);
gs.addInfoMessage('Change ticket ' + newChange.number + ' created.')
action.setRedirectURL(newChange);
}

function copyTask(chgID) {
//Find the current change tasks and copy them
var tasks = new GlideRecord('change_task');
tasks.addQuery('change_request', chgID);
tasks.query();
while(tasks.next()){
var taskID = tasks.sys_id.toString();
var newTask = tasks;
newTask.change_request = current.sys_id;
tasks.insert();

//Copy attachments for this task
Packages.com.glide.ui.SysAttachment.copy('change_task', taskID, 'change_task', tasks.sys_id);
}
}

function copyCI(chgID) {
//Copy over the affected CI list
var cis = new GlideRecord('task_ci');
cis.addQuery('task', chgID);
cis.query();
while(cis.next()){
var newCI = cis;
newCI.task = current.sys_id;
cis.insert();
}
}

One other method for copying a change (or any other ticket) is to reference the record to copy and copy from the referenced record. You could use the script below to copy a change that is pulled from a reference field on any form. Just provide the name of the field to grab the change from in line 3.

//Get the current sys_id value for querying
//Provide the name of the reference field to copy change from
var chgID = current.your_change_reference_field.toString();
var rec = new GlideRecord('change_request');
rec.get(chgID);
copyChange();

function copyChange() {
//Initialize new change for insertion
var newChange = rec;
newChange.requested_by_date = 'NULL';
newChange.start_date = 'NULL';
newChange.end_date = 'NULL';
newChange.calendar_duration = 'NULL';
newChange.opened_at = current.opened_at;
newChange.opened_by = current.opened_by;
newChange.sys_created_on = current.sys_created_on;
newChange.sys_created_by = current.sys_created_by;
rec.insert();

//Copy attachments for this change
Packages.com.glide.ui.SysAttachment.copy('change_request', chgID, 'change_request', rec.sys_id);

//Copy associated tasks and CIs
copyTask(chgID);
copyCI(chgID);
gs.addInfoMessage('Change ticket ' + newChange.number + ' created.');
action.setRedirectURL(rec);
}

function copyTask(chgID) {
//Find the current change tasks and copy them
var tasks = new GlideRecord('change_task');
tasks.addQuery('change_request', chgID);
tasks.query();
while(tasks.next()){
var taskID = tasks.sys_id.toString();
var newTask = tasks;
newTask.change_request = rec.sys_id;
tasks.insert();

//Copy attachments for this task
Packages.com.glide.ui.SysAttachment.copy('change_task', taskID, 'change_task', tasks.sys_id);
}
}

function copyCI(chgID) {
//Copy over the affected CI list
var cis = new GlideRecord('task_ci');
cis.addQuery('task', chgID);
cis.query();

while(cis.next()){
var newCI = cis;
newCI.task =
rec.sys_id;
cis.insert();
}
}