Save on form creates a related record but doesn't link them? No custom code.

[rita_m]

I've noticed something really interesting that I've never seen before.  This is potentially REALLY useful to me if I can just figure out how to fix it so that things link up correctly.  Hopefully someone can help.

I've created a new table Data Classes with 3 fields of type list (reference) and a couple other fields of type text.

I've added a reference field"Data Classes" that refers to this new table on our cmdb_ci application table, and put it on the form (bottom). I have also added the 3 related list fields on the Data Classes table to the application form (top 3 fields) by dot-walking through this new reference field on the Application form.  

Adding data to any of these 3 list fields and saving the Application record results in a new record being created in the Data Classes table with that data. 

• If I put data in all 3 fields, the correct data shows up in all 3 fields in the new Data Classes record.
• If I instead put one of the Data Classes's TEXT fields on the Application form, put data there, and save the application record, there is no new record created.

However, the Application record's Data Classes reference field to this Data Classes table (the bottom field shown, 2nd picture) is NOT updated when the new Data Classes record is created to reflect that new sys_id, so after the save/reload the 3 Data Classes list values shown on the Application form are blank again.  The new Data Classes related record exists, but the Application record doesn't have the correct sys_id for it.

Any ideas on how to best link the Application table to the new Data Classes record?  An onAfter business rule on the Application table that checks if a new Data Classes record was created, and if so adds that new sys_id to the Application and does ANOTHER update() is possible, but certainly not ideal.  Or would it just be safer to report this to SN as a bug and go about this some other way?

Thanks for any and all advice!

[BharathChintala]

@rita_m 

You should have 2 after business rules

first BR:

on application table

on insert 

in advanced

var gr = new GlideRecord('data_class');//enter your custom table

if(gr.get(current.u_data_class))// replace your field name of data class in application table

{

//do nothing

}else{

gr.initialize();

gr.application = current.sys_id;

gr.insert();

}

Seconf BR

on Data class table

On Insert

In advanced

var gr = new GlideRecord('application');//repllace cmdb application table

if(gr.get(current.application))//replace application filed name from data class table

{

gr.data_class = current.sys_id;

gr.update();

}

This BR will make sure relation build between these 2 tables. and if you want to restrict duplicate entry entries write one more Before BR on insert to check if a record is already available in data class and abort if it is there.

Thanks,

Bharath

[rita_m]

Hi Bharath - Thank you for responding!

I think that something like this idea will work, but there are some issues with it as suggested.

If I followed business rule 1 exactly then I'd have 2 data class records created - 1 is created by default, and then this would create another, and that 2nd record wouldn't have the data the user tried to set.  Additionally, this is happening on Application insert, and I only want applications where the user put data in the data_class fields to have this related data_class record, not all.  I can fix these by making business rule 1 =

On After, insert/update, in Advanced script:

if (current.u_cdata_classes.u_receives != "" ||
current.u_data_classes.u_created_changed != "" ||
current.u_cmdb_data_classes.u_sent_back != "") {
current.u_data_classes = current.u_data_classes.sys_id;
current.update();
}

I am not sure why business rule 2 is needed, or what exactly it does.  While my current data classes table does have a field that links back to the application, it wouldn't have a value at this point. I can create a script that would - on insert - search the application table to find one where the application.u_data_classes matches the new sys_id, and match the current.application = application.sys_id that way, and that would MOSTLY do what I need.

This code would set all the fields as I need them IN THE CASE WHERE THE APPLICATION UPDATE BUSINESS RULES RUN AT ALL.  

However, they don't always run.

It appears that if the application has NO changes and the ONLY changes that you save on the application form are for the Data Class table fields, then application table business rules for update are not triggered.  The Data Class table record IS STILL CREATED created, tho, but I've no way to trigger the scripts to link things together.  

If I make changes on the application form to both the Data Class table fields AND any application record field, then the application table business rule on update run as expected and everything now syncs up exactly how I need.

Any ideas for how to handle this situation?

Thanks,

-R