Modify Create Change Order to copy fields

[Joe Schmoetzer]

I need to modify Create Change Order in Incidents. For a certain category if Create Change Order is clicked than I want the Change Order to have a specific category and to copy over the affected service. Create Problem does this with Summary so I know the logic has to exist somewhere.

 

I've found some posts that look similar on Communities but the answers are generally "do this" and I don't know how to "do this".

[Edgar Louw]

Hi Joe

 

I'm not sure this is possible, as the incident, request and problem is in the same table and uses the same fields. Change is very much separted from the CR table and only fields that matches is Summary, description and requestor when you create from incident. The category could be populated but then you would need a way for the two category tables to talk to each other.

 

The two tables will not have the same fields to copy over. Change is Module is on it's own.

 

I think very extensive coding, would only work here. Not sure how to start here. You will need build Categories on both sides also. Affected services uses the same table.

 

I could be wrong, i'm not sure how the create change from incidnet works.

 

Regards

 

Edgar Louw

[David Ng]

Joe,

 

Can you provide some of those community posts that had similar materials?  Where the answers were "do this"?

 

Something I could imagine might work may be to create a button on the given incident such that the CO is created via maileater or web services and the parameters you are looking to pass along are given in that matter.

[Anthony_L]

Hi Joe,

 

I was able to identify a simple piece of spl code to do what you need to do. Do note that this is outside the scope of support and any unintended consequences would also be outside the scope of support so use this at your own discretion.

1.) Create a .spl file in the site/mods/majic folder. You can name it whatever you want. I named it cr_create_chg.spl
2.) In the .spl file put the following:

cr::site_call_to_change_mapping( object change )
{
// copy cr summary to change justification
change.impact = impact;
}

and then save. Note the above copys over the impact field and as such you would need to change it to suit your needs. For example if the change order field is called chg_project and the request field is called cr_project. It would be:

change.chg_project = cr_project.

3.) Restart SDM.
4.) Try and Create a Change Order from a request/incident.

[Joe Schmoetzer]

Tried this:

cr::site_call_to_change_mapping( object change )
{
change.zaffected_service = affected_service;
change.organization = zorganization;
}

 

Got this: 

 prov_base.c 1010 SQL Query has returned (5000) rows for (domsrvr/superuser/jschmoetzer). Clause (SELECT ca_organization.organization_uuid, ca_organization.org_name, ca_organization.inactive FROM ca_organization ORDER BY ca_organization.org_name) Input (<None>)

 prov_base.c 1025 SQL Query has finished (9935) rows for (domsrvr/superuser/jschmoetzer). Clause (SELECT ca_organization.organization_uuid, ca_organization.org_name, ca_organization.inactive FROM ca_organization ORDER BY ca_organization.org_name) Input (<None>)

 

and the values were not filled in. I'm assuming something is wrong with my implementation

[Anthony_L]

Hi Joe,

 

Try to do impact first like in the example to make sure you are doing it right as I have tested that one and it works. I don't see why it would do those SQL Queries. It should just be a simple copy and paste of the UUID from the request to the change order.

[Joe Schmoetzer]

Didn't work going to Change Order. SET.impact is also in frm002 as well.

[Legacy User]

Hi Joe,

 

Via htmpl is simple, when the user use the button "Create Change Order" you have the variable $args.NEXT_PERSID with the incident id. If the user create the change order via other way this variable is empty.

 

You can create a pdm_id with this condition and populate the requested field via pdm_list.

 

Regards

Francisco

[Legacy User]

Hi Joe,

1. Copy incident 'affected_service' to change 'zaffected_service':

The fields that are to be copied to another ticket (this applies to all ticket types) are placed in form 'frm002' in the detail form.  You could copy Incident 'affected_service' to Change 'zaffected_service' by adding the following lines into the form 'frm002' in the Incident detail form detail_in.htmpl:

<input type="hidden" name="SET.zaffected_service" value="$args.affected_service">

<input type="hidden" name="KEY.zaffected_service" value=<PDM_FMT ESC_STYLE=JS2>"$args.affected_service.COMMON_NAME"</PDM_FMT>>

The new Change will pick up the contents of SET.zaffected_service' and 'KEY.zaffected_service' just by virtue of the fact that the detail_chg form has a field called 'zaffected_service' which is an SREL.

 

2. Set the Change Category depending on the original Incident Area:

Can you give some more detail of the use case for this?  What is the business problem that you're trying to solve?   I would like to better understand your specific need before trying to suggest a solution.

 

Regards,

james

[Joe Schmoetzer]

I got this to work for Request -> Incident but it won't work for Request -> Change Order. Impact is also in frm002 but doesn't carry to Change Order either.

[Legacy User]

Joe, you're absolutely right.  The form 'frm002' is used when creating a CR from a CHG, or creating a CR from another CR, but not when creating a CHG from a CR.  My apologies for confusing the issue.  I'll give this some more thought...

 

Regards,

James

PS: it would still be helpful to understand your business requirement.

[Grant Bruneau]

Hi James,

 

A few months ago you gave me the idea to create a new form section to pass values from an incident to a co. In our case we were trying to solve the bug where the incident was not associated with a co if the co was in edit for longer than 5 minutes. 

Change field mapping from Create Change Order button on Incident 

I was able to build the solution mentioned in that thread and it works well. We have it in place on the request, incident and problem forms. In addition to fixing the co association bug it also gives the ability to map additional fields from the r/I/p to the CO. Which I think would solve JoeSchmos use case.

 

I would be happy to share this solution. Let me know if you think it would solve this query. If so I will share it here.

[Legacy User]

Hi Grant and Joe,

 

I'm embarrassed to say that I'd forgotten about that alternative!  And I'm sure it would work for Joe's issue. 

 

In the meantime I looked up the function 'cr::site_call_to_change_mapping' which Anthony Lee mentions above (and I didn't know about) and which also came up in this thread: When creating a Change Order from an existing Incident, how can I add an additional argument to be populated in the Change Order? 

 

I took the sample source from %NX_ROOT%\samples\call_mgt\chg_site.spl, copied that to site\mods\majic\chg_site.spl, commented out the other functions in chg_site.spl, edited function site_call_to_change_mapping as below, restarted SDM  and the fields shown below are duly copied across from an incident to a change.  So there you go, Joe - two solutions for the price of one!

cr::site_call_to_change_mapping(object change)
{
    string method; method = "cr::site_call_to_change_mapping";
    logf(TRACE,"%s START.",method);
    // default the change request group from the call request group
    if (!is_null(this.group)) change.group = this.group;
    // default the change request assignee from the call request assignee
    if (!is_null(this.assignee)) change.assignee = this.assignee;

    // Set CHG field 'zAffectedService' from CR 'affected_service'.   
    if (!is_null(this.affected_service)) 
    {
        logf(TRACE, "%s setting zAffectedService", method);
        change.zAffectedService = this.affected_service;
    }
    logf(TRACE,"%s END.",method);
}

Setting the Change Category is still to be sorted.  You could hard-code the mapping from the Incident Area to a Change Category into the function site_call_to_change_mapping.  But it might be tidier to add a new field to the Incident Area object pcat - something like 'zMappedChgCat' - and make that an SREL to chgcat.  Maintain the field 'zMappedChgCat' in the Incident Area detail form, pick it up in 'site_call_to_change_mapping' from the CR category as 'this.category.zMappedChangeCategory', and set the mapped category into the change if it is not null.  That would probably be my preference.

 

Regards,

James

[Jon_Israel]

Hi gbruneau  - did James' post help you out here?