View Issue Details

IDProjectCategoryView StatusLast Update
000853810000-009: Alarms and ConditionsSpecpublic2024-06-04 15:24
Reporterasthomas Assigned ToPaul Hunkar  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionwon't fix 
Product Version1.05.01 
Summary0008538: ClientUserId cannot be set during alarm acknowledgement
Description

My application sends an acknowledgement to an A&C alarm in a UA server. It does this by calling the method, MethodIds.AcknowledgeableConditionType_Acknowledge. This method has 2 arguments, the byte[] event ID and a string comment.

There is no argument to set the ClientUserId on the condition, so I cannot specify who acknowledged this alarm.

The spec indicates that ClientUserId is set by the session authentication. That produces some bad behaviour, like using the certificate subject name as the user ID. In any case, the session user is not necessarily the user name that I want. My application requires operators to log in to the application, separate from the back-end connection to the UA server, so I want the currently logged-in operator's name in the ClientUserId, not the session user.

The obvious resolution is to add an additional argument on AcknowledgeableConditionType_Acknowledge, or create an AcknowledgeEx method, so the caller can specify the acknowledger's name. That would also be more consistent with OPC A&E.

TagsAlarms
Commit Version1.05.04 RC
Fix Due Date2023-10-15

Activities

Jim Luth

2023-04-18 16:58

administrator   ~0019198

consider adding an additional string field to hold the "friendly user name". We can't accept unverifiable "users" in the exsisting UserID field.

Jim Luth

2023-08-01 17:22

administrator   ~0019767

Agreed to add one new method to add a friendly user name to the Session.

Paul Hunkar

2024-06-04 15:23

developer   ~0021259

if the User name is from a back end and thus the UA connection does not have a user name - the plant or product process should simply require that a comment shall be entered and that the comment shall start with User information. This could even be automated in a product,

Jim Luth

2024-06-04 15:24

administrator   ~0021260

Agreed to no-fix in web meeting.

Issue History

Date Modified Username Field Change
2022-12-22 21:24 asthomas New Issue
2022-12-22 21:24 asthomas Tag Attached: Alarms
2023-04-18 16:58 Jim Luth Note Added: 0019198
2023-04-18 16:58 Jim Luth Assigned To => Paul Hunkar
2023-04-18 16:58 Jim Luth Status new => assigned
2023-08-01 17:22 Jim Luth Note Added: 0019767
2023-08-01 17:30 Jim Luth Commit Version => 1.05.04 RC
2023-08-01 17:30 Jim Luth Fix Due Date => 2023-10-15
2024-06-04 15:23 Paul Hunkar Status assigned => resolved
2024-06-04 15:23 Paul Hunkar Resolution open => won't fix
2024-06-04 15:23 Paul Hunkar Note Added: 0021259
2024-06-04 15:24 Jim Luth Status resolved => closed
2024-06-04 15:24 Jim Luth Note Added: 0021260