Notifications with a User Default Notify Mechanism are not going out. Customer is using LDAP ARS 6.3
Page 1 of 1
Notifications with a User Default Notify Mechanism are not going out. Customer is using LDAP ARS 6.3
Solaris version is 2.8
Sybase version is 12.5.1
ARS 6.3 Patch 14
Customer is using LDAP authentication and external authentication. If they have
notifications set up to do User Default as the mechanism, no one ever receives the notification. If they make the
Mechanism Email or Alert, the notifications go out and are received.
From Customer:
If we change the notification mechanism type in the AP:Administrator
form to User Default, no notifications are being sent whether it be
email or alert on the user record. If we change the notify mechanism to
Email in the AP:Administrator form, email notifications are sent as
expected.
We have identified that NO alert nor email notifications are sent out if
the approval process is set to use User Default. If the customer
changes the approval process to use email, then email notifications are
sent. I'm waiting for the customer to test setting the approval process
to use alert to see if alert notifications are sent appropriately.
Sybase version is 12.5.1
ARS 6.3 Patch 14
Customer is using LDAP authentication and external authentication. If they have
notifications set up to do User Default as the mechanism, no one ever receives the notification. If they make the
Mechanism Email or Alert, the notifications go out and are received.
From Customer:
If we change the notification mechanism type in the AP:Administrator
form to User Default, no notifications are being sent whether it be
email or alert on the user record. If we change the notify mechanism to
Email in the AP:Administrator form, email notifications are sent as
expected.
We have identified that NO alert nor email notifications are sent out if
the approval process is set to use User Default. If the customer
changes the approval process to use email, then email notifications are
sent. I'm waiting for the customer to test setting the approval process
to use alert to see if alert notifications are sent appropriately.
giby.varghese@gmail.com- Posts : 107
Points : 222
Reputation : 3
Join date : 2009-11-11
Re: Notifications with a User Default Notify Mechanism are not going out. Customer is using LDAP ARS 6.3
External-Authentication-Return-Data-Capabilities:
The previous definition of this configuration setting was:
#define NO_EMAIL_ADDR 0x0001
#define AR_EXT_AUTH_DATA_NO_NOTIFY_MECH 0x0002
#define AR_EXT_AUTH_DATA_NO_GROUP_IDS 0x0004
#define AR_EXT_AUTH_DATA_NO_LICENSE_INFO 0x0008
This is a bit mask that allows the Admin to define what the return data capabilities are for the AREA plug-in they
have in place. By knowing this, the server can make intelligent choices when needing notification information
about users. Before this enhancement, if the server needed to know an email address for a user and external
authentication was enabled, it would make the External Authentication call to determine if it could get the email
address. This is wasteful if the plug-in is never going to return email addresses. Because of the architecture of
the notification processing in the server, it only makes sense to skip the External Authentication call if it doesn't
return email addresses, notify mechanism, and group ids. Therefore, if the setting of this config item includes the
first 3 bits (i.e., 7), the server will not make the External Authentication call when looking for notification
information. This was designed with future use in mind, therefore there is also a license info bit that is not used right now.
This patch introduces a new setting for the bit mask:
#define AR_EXT_AUTH_DATA_NO_NOTIF_VALIDATION 0x0016
This setting allows the Admin to define that the AREA plug-in is not to be used for notification user validation. In
the typical notification user processing, the server would make one AREA call to simply validate that the name
was a user name and then subsequently make another AREA call to get the user's email address. When the
NO_NOTIF_VALIDATION option is chosen, the server will skip the user validation check and check to see if the
name is a group name. If not a group name, then the user will be considered to not be a user in the system and
the name will be used as the email address. Therefore a setting of:
External-Authentication-Return-Data-Capabilities: 23
will avoid the two AREA calls that would normally occur during notification user processing.
The previous definition of this configuration setting was:
#define NO_EMAIL_ADDR 0x0001
#define AR_EXT_AUTH_DATA_NO_NOTIFY_MECH 0x0002
#define AR_EXT_AUTH_DATA_NO_GROUP_IDS 0x0004
#define AR_EXT_AUTH_DATA_NO_LICENSE_INFO 0x0008
This is a bit mask that allows the Admin to define what the return data capabilities are for the AREA plug-in they
have in place. By knowing this, the server can make intelligent choices when needing notification information
about users. Before this enhancement, if the server needed to know an email address for a user and external
authentication was enabled, it would make the External Authentication call to determine if it could get the email
address. This is wasteful if the plug-in is never going to return email addresses. Because of the architecture of
the notification processing in the server, it only makes sense to skip the External Authentication call if it doesn't
return email addresses, notify mechanism, and group ids. Therefore, if the setting of this config item includes the
first 3 bits (i.e., 7), the server will not make the External Authentication call when looking for notification
information. This was designed with future use in mind, therefore there is also a license info bit that is not used right now.
This patch introduces a new setting for the bit mask:
#define AR_EXT_AUTH_DATA_NO_NOTIF_VALIDATION 0x0016
This setting allows the Admin to define that the AREA plug-in is not to be used for notification user validation. In
the typical notification user processing, the server would make one AREA call to simply validate that the name
was a user name and then subsequently make another AREA call to get the user's email address. When the
NO_NOTIF_VALIDATION option is chosen, the server will skip the user validation check and check to see if the
name is a group name. If not a group name, then the user will be considered to not be a user in the system and
the name will be used as the email address. Therefore a setting of:
External-Authentication-Return-Data-Capabilities: 23
will avoid the two AREA calls that would normally occur during notification user processing.
giby.varghese@gmail.com- Posts : 107
Points : 222
Reputation : 3
Join date : 2009-11-11
Similar topics
» When connecting Remedy User to a server using a specified AR TCP Port, query menus fail with: ARERR [90] Cannot establish a network connection to the AR System server : test.Remedy.COM : RPC: Program not registered.
» Filter notifications with 'add shortcut' creates url in Email that doesn't work. More then 30 characters in the servername ARERR [9280]
» Windows 7 compatibility for User tool
» What needs to be configured to give an Asset Admin user access to view and modify a CI?
» When User or Admin Tools try to connect to the server an ARERR 90 is received with the message RPC: Program not registered.
» Filter notifications with 'add shortcut' creates url in Email that doesn't work. More then 30 characters in the servername ARERR [9280]
» Windows 7 compatibility for User tool
» What needs to be configured to give an Asset Admin user access to view and modify a CI?
» When User or Admin Tools try to connect to the server an ARERR 90 is received with the message RPC: Program not registered.
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum