VI 10.8 - actions behind the DISPOSITIONs

[agesser]

hi experts,
In previous VI versions, while user is doing a disposition to alert (e.g for alert with pk_field = 123) we could see dada datahub VI did a:
select 1 from PREP_TABLE where pk_field  = 123;
and if the query brings nothing - we got an error
so, we had to keep all rows for the created alerts at PREP_TABLE forever.
Questions:
1 - is this the same case at 10.8 or it was changed?
2 - what happening for automatic dispositions, while alert is created VI is doing this query?
3 - what can be the reason that for some scenario, VI is doing such select for all rows at the PREP_TABLE (let's say PREP_TABLE has 1000 rows from previous running, now created 10 new alerts, but we can see 1000 queries from PREP_TABLE)?

Thanks a lot,

Alex.

[_austin_]

Hi Alex,

In alert management for Visual Investigator, a user has to be able to see the actionable entity for an alert - whatever entity the alert was on - to be able to disposition it. This was a feature added when we added entity-level security; we thought people should not be able to work an alert if they cannot see the entity related to the alert. So, when an analyst invokes a disposition, the system will verify that the user can see the alert. Note that the alert service cannot differentiate between "I cannot see this entity because of visibility rules" and "I cannot see this entity because there is no record in the database"; those 2 situations behave the same (for security reasons).

You are not the first person who has asked about these visibility checks during disposition. I have heard of use cases where the current behavior causes challenges to the solution. I think it would be nice if the system had a setting at the domain level to let you control whether that check needs to be made or not. 

So in answer to your questions:

1. this is still the current behavior in all versions of Visual Investigator
2. I don't think this check is made for automatic dispositions. To do a document visibility check, we would need to use the current user's credentials. Most of the alert creation process is done as "the service" which has all permissions. So in that path through the code, I believe the database check is short-circuited.
3. I cannot explain what you are describing in question 3, could you give more background? I would expect a request for 10 new alerts to cause the system to read the 10 actionable entities, because the alert usually needs to compute and save the entity's label in the alert label. Is it possible that other things are happening coincidentally in the system, like an indexing run, and that is causing all the records to be read?

Austin

[agesser]

hi Austin,
Thank you very much for your answer:

for 1 - we are going to PostgreSQL of the VI 

and union the result of the query to the PREP table so PK will be there for disposition:

(As a big picture):

create table FINAL_PREP_TABLE as

select col_PK, col1, col2,col3

from PRER_TABLE_BEFORE_FINAL

union all

select al."actionable_entity_id",null,null,null

from avi_Alert.tdc_alert_v al-- from PG

where al."actionable_entity_type_nm" = 'AAA'

about 2 and 3: 

we've opened Case CS0054656 SAS Vi 10.8: send queries to external DB - if you can take a look there for more details it will be great!
We will publish the result for all here after that.

Thanks a lot,

Alex.