how to get child table field into parent table

[yekambaram]

Hi thanks in adv,

How to get child table field into parent table.

Eg: parent table is cmdb_ci table and child table is cmdb_ci_server.

the field classification is present in cmdb_ci_server table but i want to get that filed into parent table cmdb_ci table

  var child = new GlideRecord('cmdb_ci');

  child.addQuery('operational_status',1); //operational status field is present in cmdb_ci table so it gets filtred and working fine

but when i try to filter child table field its not getting

child.addQuery('classification','production'); // its not working because the classification field is present in the cmdb_ci_server.

how to filter the records based on classifiacation from cmdb_ci glide record

[yekambaram]

Hi chuck,

Here is the requirement that when we select the configuration item in the change request table then based on the configuration item we are filtering only down stream cis that to selected classes in the change task configuration item, to achieve this we create a script include on cmdb_ci table and call the script include in ref qualifier of configuration item in change task form.

till now i achieved the requirement but i want to filter more based on classification field present in the cmdb_ci_server table which is a child table of cmdb_ci table.we are filtering based on the cmdb_ci table but in that i want to filter the cmdb_ci_server field.

_addChildCIs: function (id, infoObj, affectedCIs, currentDepth, classArr) {

              if (infoObj.affectedCIsCount >= this.maxAffectedCIs)

                      return;

              var rel = new GlideRecord('cmdb_rel_ci');

              rel.addQuery('parent', id);

              rel.query();

              var childs = [];

              while (rel.next()) {

  childs.push(rel.child.toString());

              }

              if (childs.length) {

                      var child = new GlideRecord('cmdb_ci');   /// here i am using cmdb_ci table but in this i have to filter cmdb_ci_server field 'classification'

                      child.addQuery('sys_id', childs);

                                                                    var s= child.addJoinQuery('cmdb_ci_server'); //i tried this code

                                                                      s.addCondition('classification','production');

                    child.addQuery('operational_status',1); // this is filtering based on operationl_status which is present in cmdb_ci table it is working fine

                      child.query();

                      while (child.next() && infoObj.affectedCIsCount < this.maxAffectedCIs) {

                              var pid = child.sys_id.toString();

                              if (!infoObj.visitedCIs[pid]) {

                                      infoObj.visitedCIs[pid] = true;

                                      if (classArr[0] == 'ALL' || this.arutil.contains(classArr, child.sys_class_name.toString())) {

                                              affectedCIs.push(pid);

                                              this._addCI(pid, infoObj);

                                      }

                                      if (currentDepth < this.maxDepth)

                                              this._addChildCIs(pid, infoObj, affectedCIs, currentDepth + 1, classArr);

                              }

                      }

              }

      },

[manu92]

Hi Chuck,

Just came across this post : https://www.servicenowguru.com/scripting/promote-field-extended-table-servicenow/

Although this works, could you let me know if this would cause any ill effects in the future especially for cmdb discoveries & other integrations?

Thanks in advance.

[Chuck Tomasi]

I only recommend promoting a field if you are REALLY, REALLY, REALLY sure that field is required across multiple sub-classes. While there are no immediate ill effects, any business rule or other script that modifies that value and isn't properly tied to that class could have ramifications on other classes. This happened to me when someone had a field on task. They wanted to use this field on problem and incident. I was in charge of change and had finished my work a couple weeks ago when I received a bug report that change suddenly started having issues.

It turns out that the field, although innocent enough, had a BR to maintain it and the BR was doing this for all classes, not just problem and incident. It was easy enough to fix by adding this to the BR condition

current.sys_class_name == 'incident' || current.sys_class_name == 'problem'

so it no longer impacted change, sc_request, or any other task tables, but it's an example of what you need to watch out for when dealing with fields on a parent class.

[Dan T_]

The prior method promoteColumn() is no longer available effective in London.  See KB0743116.

[Dan T_]

The prior method promoteColumn() is no longer available effective in London.  See KB0743116.