Sorry, but that has zero effect on this case. Already tested and proven.
________________________________ From: Vyom Labs Support <itsm.supp...@vyomlabs.com> To: arslist@ARSLIST.ORG Sent: Friday, September 27, 2013 6:32 AM Subject: Re: Notifications firing unexpectedly - Odd case Hi, We can overcome this by enabling the option "None" for the field "Default Notify Mechanism" on the "User" form and By setting the "Email Address" as blank on "CTM:People" form. Please find attached screen shots in this regards. -- Regards, Nitesh Kumar Vyom Labs Pvt. Ltd. BSM Solutions & Services || ITIL Consulting & Training Email: [hidden email] || Web Site: www.vyomlabs.com Follow Vyom Labs http://twitter.com/#!/vyomlabs || http://www.linkedin.com/company/vyom-labs -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Ray Gellenbeck Sent: Thursday, September 26, 2013 11:42 PM To: arslist@ARSLIST.ORG Subject: Notifications firing unexpectedly - Odd case I have ITSM installed but have customer workflow installed. At one point, all members of a given group are sent a email notification via filter. An unexpected behavior happens. Details (this is tricky, so read carefully) 7.6.04 server (Remedy OnDemand system, not that it matters except to describe underlying components/config) Each person's UserID/login is their email address (for SSO purposes, we use the full email address for their ID to allow the solution to be accessible by all our domains). Example, my login ID would be Raymond.Gellenbeck@(domain).sony.com ODD BEHAVIOR (PROBLEM): If the person's profile in CTM:People is set to "Offline" and their actual "E-Mail Address" field is blank, they still get an email sent via the workflow. ***NOT*** what was expected nor desired. More detail and theory on why this happens: Setting someone to Offline in CTM:People does NOT set their User record's "Status" field to "Disabled". The ARS Email engine is getting the command from the filter to email this group, then creating a record for each group member. For each message record, it then checks that person's CTM:People record's email address field and changes the "to" value from the UserID to email address if it finds a value. It does not skip records set to "Offline". Alternately, it may be checking the User table instead. Regardless of where it checks, if it fails to find a value for email address, it leaves the UserID in place and attempts to send. I tested this theory by creating a new group member (bigbob, for example). The test member record has no value for email address and the userID is not a valid email address. Sure enough, the email engine fills in the value bigbob, then fails to find an email address and attempts to send the message to just "bigbob" and results in the attempt record being set to "error" instead of "sent". So, I guess the point is, do NOT think that just setting a person to "Offline" will prevent them from getting email messages if you use this naming convention for loginID's. To explain, we use this scheme so that all domains can participate in using the change management tool and the microsoft-side team decided they wanted to use this scheme rather than the "(domain)\(domainID)" format. Replies are welcome that clarify the source(s) the email engine checks and what the rules are regarding status and when to ignore a person/record. Thanks in advance. Raymond H. Gellenbeck Manager | Business Service Management Sony Network Entertainment P: 858.207.1563 | M: 619.500.3993 E: raymond.gellenb...@am.sony.com _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
