ACK alarm group only if on particular computer

[tmalone]

Ship automation issue. Some alarms can be acked only from specific computers.

I am sure the click for alarm ack on the alarm line holds the "magic" for how it works. Is there a way through AES configuration to do this?

Or can someone point me at the script where to put the IF(myComputer) THEN ack ELSE beep.

Thanks,
Todd Malone

[Gertjan van Schijndel]

In the workstation authorization you could remove the acknowledge permission for these specific computers.

You could implement 'HOOK_isAckable' and/or 'HOOK_isTableAckable' to replace the acknowledge action with the beep. For more information on the parameters of these functions you can look in the online at the functions 'isAckable'/'isTableAckable' and/or look in the library 'libCTRL.ctl' how these functions work.

[tmalone]

But, the same workstations need to ACK their alarms, just not others.

This is the general issue with the way OA does the ACK, it is "all or nothing". What I need is selective ACK by alarm class.

[Gertjan van Schijndel]

With both options it is possible to a prevent certains alarms from being acknowledged.
In the alert class you can define the required permission bit for the acknowledge.
In the example of the function 'isAckable' in the online help one element is removed from the acknowledge list.

[tmalone]

Help me understand the HOOK_ keyword?

I have seen this before in STD lib functions, but I thought it was limited to those graphical elements.

[tmalone]

I am finding that a number of HOOK_ type functions might be recognized, however there is no comprehensive list.

Inside some functions there is code like this:

if( isFunctionDefined("HOOK_isAckable") )
{
HOOK_isAckable(iType, daDps, iReturnValue);
return;
}

Which will skip the standard isAckable function and run the HOOK function. It seems that HOOK functions do not exist in the ETM code, and are the there so Customers/Integrators can replace basic functionality without editing the original function libraries. This is great because we want to avoid taking over an ETM library for fear that next version the library changes and we do not get an update.

So, the real trick is to understand what original ETM library function is called for some feature you want to override. This is not always obvious. This is where a comprehensive list of possible HOOK functions with a short description would be highly useful.

You should load your HOOK control library file using the config.level and LoadCtrlLibs = "MyHooks.ctl" in sections like [ui], etc.

now, back to your solution: isAckable or isTableAckable are the choices you suggested. I am trying to understand why one would be used over the other?

[tmalone]

My testing shows that the best choice for what I want to do is:

HOOK_aes_acknowledgeTableFunction

This function has some documentation in the help and provides a mapping list of things the alarm to be acked has defined. For example,
"__alertClass" : System1:disturbance

I can key off of this mapping and decide if this alert class can be acked by this workstation.

The "got cha" is that you must also have ALL of the functionality of the original aes_acknowledgeTableFunction in your HOOK function if you want it to work as in the original manner with your "hooks".

[tmalone]

Turns out that the HOOK_aes_acknowledgeTableFunction(string sObjectName, int iType, mapping mTableMultipleRows);

Is really cool. It returns a bool that allows the ACK code to run like usual. No need to duplicate the old code in the HOOK function.

We were even about to make a filtered alarm viewer with a special sObjectName to allow for ACK there, but not on the main alarm page.

Todd