Notifications with a User Default Notify Mechanism are not going out. Customer is using LDAP ARS 6.3

View previous topic View next topic Go down

Notifications with a User Default Notify Mechanism are not going out. Customer is using LDAP ARS 6.3

Post  giby.varghese@gmail.com on Fri Jun 11, 2010 11:52 am

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.

giby.varghese@gmail.com

Posts : 107
Points : 222
Reputation : 3
Join date : 2009-11-11

View user profile

Back to top Go down

Re: Notifications with a User Default Notify Mechanism are not going out. Customer is using LDAP ARS 6.3

Post  giby.varghese@gmail.com on Fri Jun 11, 2010 11:53 am

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.

giby.varghese@gmail.com

Posts : 107
Points : 222
Reputation : 3
Join date : 2009-11-11

View user profile

Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum