On Thu, 4 May 2006 23:43:08 -0400, A R Kosch <[EMAIL PROTECTED]> wrote:
>On Thu, 4 May 2006 23:16:11 -0400, Axton <[EMAIL PROTECTED]> wrote: > >>With 5.x(not sure the release this was fixed, whether 6.x or later 5.x >>patch), there was a problem with group notifications if using the >>canned AREA for authentication. The users that had a blank password >>would not get notified from group notifications unless the email >>address and notification method were stored in the ldap directory and >>mapped in the AREA config form. >> >>Test it. Create a group with two members, give one a password, the >Worth a try! It works until stressed, then is broken, I'll see if my test >case survives the broken state if both users have unblank, Remedy >passwords. Thanks much for the suggestion, Axton! I can inform the list >tomorrow afternoon if this works... ann By golly, Axton! In my test environment adding the Remedy password to unblank the password caused the email notification that had been missing to be created! Of my two group members, I already had one using a nonblank password and that was the one that WAS being created. It is still a puzzle in broken production cases when all group members have blank passwords, some received notifications and some didn't. It may just be how this problem behaves, or there is something else involved there, or there are two issues. I'll pursue this with Remedy support and let the list know the fix(es). Thanks so very much for your time responding to my posts! Have a great weekend.... Ann Kosch >>other a blank password, use the same email address for both. see if >>you get 1 email or two when you notify the group. Was an old problem, >>but may be one of those that never got fixed until the next release >>(6.x). >> >>Axton Grams >> >>On 5/4/06, A R Kosch <[EMAIL PROTECTED]> wrote: >>> On Thu, 4 May 2006 21:18:06 -0400, Axton <[EMAIL PROTECTED]> wrote: >>> >>> >Do you use the provided precompiled AREA plugin for authentication? >>> >>> Yes we do. What do you think, then. >>> >>> I noticed info in KB or somewhere that once a change is made to >registered >>> user info, AREA keeps performing AREAVerifyLoginCallback stuff until a >>> restart is done. I see that happening in the log ad nauseam, constantly. >>> >>> With our ARS 5.1.2, are they creating a separate user_cache yet when a >>> change is made to go with the new dev cache setting? >>> >>> I've wondered about an unpatched Oracle 8.1.7 client and about rpcbind >that >>> I think we use ver 2 and current release is at 4. Doc says I should >have >>> dev server's Oracle client patched to match compiled libs but production >>> doesn't require it; they both have the same problem.... Granted, I >need to >>> have DBA patch the Oracle client regardless. Also, for dev server, I >have >>> RPC-Non-Blocking-IO: T in config file as required. >>> >>> I've checked number of file descriptors rlimit is 1024 and pfiles shows >>> conservative numbers on arserverd < 300. This is on our development >server; >>> I am showing 9 Oracle threads/processes/(whatever the correct >terminology) >>> into the R database both in a broken state and just restarted. >>> >>> Later, >>> ann >>> > >>> >Axton Grams >>> > >>> >On 5/4/06, A R Kosch <[EMAIL PROTECTED]> wrote: >>> >> David, thank you for sharing about group notification issues! Remedy >>> >> support is looking into it. >>> >> >>> >> BTW, arreload didn't fix our problem either. >>> >> >>> >> Regards, >>> >> ann >>> >> ~*~ ~*~ ~*~ >>> >> A. R. Kosch >>> >> Special Projects/Analyst >>> >> Remedy ARS Administrator/Coordinator >>> >> >>> >> [EMAIL PROTECTED] >>> >> 785-532-4933 >>> >> Kansas State University >>> >> Computing and Network Services >>> >> >>> >> >>> >___________________________________________________________________________ >____ >>> >> UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org >>> >> >>> > >>> >>__________________________________________________________________________ >_____ >>> >UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org >>> >>> >___________________________________________________________________________ >____ >>> UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org >>> >> >>__________________________________________________________________________ >_____ >>UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > >_______________________________________________________________________________ >UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org >========================================================================= _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
