How do I prevent a parent table from showing its extended tables data

[jhuston]

I created a custom app by extending the incident table.   (<-- This may have been a bad idea, in fact I'm pretty sure it was).   Its has all the fields I need and some that the task table didn't have.   Fields that we built out in incident when we first got our instance.

So I have this app, and I have imported 1000's of records into it that are sensitive, so I lock them down to a specific role.   That works fine, but when I pull up my list of all incidents as an ITIL user, say sorted by created date.   It will filter out extended tables records with security constraints.   I guess I get that, but isn't there a way to extend a table without messing up the data in the app in which the parent was created for in the first place.

If not, I'm guessing I should have just created my own table in the beginning or extended the task table>

Thanks for you help

Side note:   I pretty much based the decision on the article below

2.1.2 Know When to Extend a Base Table

Extending a base table incorporates all the fields of the original table and creates new fields for the new table. This inheritance is used to create major subcategories of data. In general, when you create a new table, it should extend a base table if:

• The fields or attributes of an existing table are similar to the ones you want to use.
• The scripts for an existing table are useful for the application.
• The information contained in the new table is essential to the process that will use the table. For example, if the process is task based, extending the Task [task] table may be a better option than creating a new table with many of the same fields. Similarly, if the process involves an asset (that is, a CI), extending one of the CMDB tables may be a better solution than creating a new table, as long as you extend a table that contains the majority of the fields you require.

[Gurpreet07]

What i understand is ...

1. incident table is showing records of new extended table from it .... if so then you could hide those records in several ways ...   a. Adding a filters condition in modules ...i.e. sys_class_name = 'incident'

        b. Use a before query business rule on incident table to remove get only those records for which sys_class_name is incident  

        c. You may create a Read ACL and in script create a condition like if (current.sys_class_name == 'incident') answer = true

[Daryll Conway]

If anyone is interested the BR is really simple...

(function executeRule(current, previous /*null when async*/) {


   // Filter results to the incident table only
   if(current.sys_class_name == 'incident'){

   }
   else{
   return false;
   }
})(current, previous);

[andy_dufresne]

Hi Daryll, Thanks for the code on it.   So I copied your code and created a 'before query' business rule and then I opened up the incident form, it still shows up the data from a table which I have inherited.   Should I be doing anything outside this? I also put a debug business rule and can confirm that this business rules does fire up.

[Vladi]

Hi andy,

I have tried several ways of writing this, but finally following worked in Istanbul:

(function executeRule(current, previous /*null when async*/) {

// Add your code here

if (gs.isInteractive() && current.getTableName() == "incident") { //so you don't filter extended table lists

var qc = current.addQuery("sys_class_name", 'incident'); //you show only Incidents

}

})(current, previous);

PS.

If this reply assisted you, please consider marking it ✅Correct, ��Helpful, or ��Liking it.

This enables other customers to learn from your thread.