Old subject was "Re: Roles in Incident Management 7.x: App doesn't match the doc & other tidbits"
A lot has been said recently about notifications in ITSM 7, so I will try to summarize what I know here. This one is about modifying notification preferences or disabling a notification altogether. I will post later about modifying the message, adding a new message etc. In short: to disable a notification in a given module (Change, Incident, Broadcast), for all users, and regardless of any other conditions (such as the ticket having certain values): a) Disable the record associated with that module, that event and that locale (if you have multiple languages) on form "NTE:SYS-Define NT Events" b)Disable the message itself for that event, that module (and the desired company, if you have multiple companies) on "SYS:Notification Messages" form. This is optional in some cases, but go ahead and do it anyway. It's good practice and you don't have to deal with the quirk that makes it optional. Use any status other than "Enabled". To find out the right event: --------------------------- If you didn't notice, "event" is the key. All messages fire when a specific "event" occurs in the application. It's fairly easy to figure out the event associated with any message...the event on which the message is set to go..if you look at events defined in NTE:SYS-Define NT Events form. Or, if you go to "SYS:Notification Messages" form instead, you can see not only the event name, but the more descriptive "message tag" and the actual message itself. In case you see a filter on the ticket form (say incident) setting up a particular message and want to disable that message, look for the "event tag" in the filter's set field and look for that tag in "SYS:Notification Messages" form. These filters are at or above order 800 and have names such as: HPD:INC:NTOwner_800_SetTag HPD:INC:NTAsgGrp_805_SetTag CHG:CRQ:NTCustConfirm_803_SetTag If you have the message text, you can also do a wildcard search for any reasonably unique phrase in the message on the message fields of "SYS:Notification Messages" form. Or, look in the NTE:Notifier Log for an actual record of the message that went out that you want to disable and see the associated event. If all fails, do logging to find out which filter around order 800 is setting up the notification. TO DISABLE A MESSAGE (you should really say disable notification on an "event") OR MODIFY ITS BEHAVIOR SELECTIVELY FOR SPECIFIC USERS(s): ------------------- Leave the "NTE:SYS-Define NT Events" and "SYS:Notification Messages" records alone, so the default behavior will be that the message goes only if the user has not indicated a preference for receiving no message. Then for the people who don't want the message or want it only on certain situations (based on group, priority, business hour, etc), create "User" kind of record(s) (as opposed to the default records you see for "System Default") for the user(s) on NTE:CFG:NotificationEvents form. This is the same form where preferences are stored if users themselves change their notificaton preferences from their people record (CTM:People ). For the same event, you can create multiple records for a user on "NTE:CFG:NotificationEvents" form. Say, on Low priority he wants no notification, on Med & High wants email only during bus hour, on High wants page at all times. If a user doesn't have a "User" preference for a given situation, (say a given event on a given module for a given priority) on "NTE:CFG:NotificationEvents" form, the "system default" record will apply. This was contrary to what I expected or wished. I wished if a "user" preference was available for a given event, "System Default" never applied but it does. TO DISABLE A MESSAGE (you should really say disable notification on an "event") OR MODIFY ITS BEHAVIOR FOR ***ALL*** USERS(s): -------------------- As you probably guessed...Modify the "System Default" record on "NTE:CFG:NotificationEvents" form. For example, take out paging, or send notification only during business hour, or change notification method. --- Jiri Pospisil <[EMAIL PROTECTED]> wrote: > ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Please Read The Disclaimer At The Bottom Of This > Email > ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Hi, > > the way to turn off a specific system default > notification for a user is to create a duplicate of > that notification event for the user and set the > notification method of that user notification to > None. > The notification engine checks if there is a user > specific event first and if there is, it ignores the > system default notification. > > Hope this helps. > > Jiri Pospisil > > Remedy Administrator > IT Production > > LCH.Clearnet > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of T. Dee > Sent: 12 November 2007 23:29 > To: [email protected] > Subject: Re: Roles in Incident Management 7.x: App > doesn't match the doc > & other tidbits > > > Rick - you indicated below that users can not opt > out of individual > notifications - is there a work around? This seems > strange - some users may > not want certain notifications, but may want other > notifications. > > I have notificed that if I create a NEW Notification > from the People Form / > Notifications tab / Update Notification Prefrences / > Create - this only > creates a new notification for that individual. Is > there not a way to > create a new notificiation that I can apply to > everyone? > > Notifications seem to be a little odd. > > Is there any place where it is documented which > Filters control which > notifications? > > Thanks!!!! > > T. > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook > Sent: Wednesday, October 24, 2007 1:57 PM > To: [email protected] > Subject: Re: Roles in Incident Management 7.x: App > doesn't match the doc & > other tidbits > > Great post, Rabi. All I can say is: Welcome to the > party that is ITSM 7. > We feel your pain. > > My favorite "As designed" feature is that of showing > the users all of the > notifications they can receive, but not giving them > the ability to opt out > of any of them, even though the screen leads the > user to believe that is an > option. > > Remember, you can't spell Quality without QA, though > BMC seems bent on > trying. > > Rick > > On 10/24/07, Rabi Tripathi <[EMAIL PROTECTED]> > wrote: > > > > Fol > > Still at war with IM 7 and this is the most recent > battle report-- > > > > Following IM functional roles are defined in the > "configure" doc: > > > > Support Group Admin > > Support Group Lead > > Support Group Manager > > > > But, only following 2 are available, when you go > to > > CTM:People->->"Support Groups" tab->"Update > Support Groups and Roles" > > button->"Functional Role Update" tab->Functional > Role: > > > > Incident Manager > > Support Group Lead > > > > I'm guessing: > > When they say "Support Group Manager" in docs, > they really mean > > "Incident Manager". "Support Group Admin" is pure > fiction, just to > > make it interesting, irrespective of the fact that > this role has > > defined privileges as per the document. Agree? > > > > Related question...when making somebody a member > of a support group, > > the "member" and "associate member" choices are > indistinct as far as > > the code behavior is concerned. Right? It says the > distinction is > "informational" > > only. I think I know the answer, but I still ask > this question, > > because I can't believe the designer didn't think > of having the code > > make some distinction such as not notifying > associate members when a > > group notification for, say, assignment, is sent. > > > > Ok, just found out that code will allow members or > associate members > > of a group to submit/modify incidents in which the > group is owner or > > assigned group. > > See Filter HPD:INC:ChkModifyPermission_017. > > > > However, code will allow members, but NOT > "associate members" of a > > group to modify Owner Group of any incident in > which the group is the > > owner. See filter HPD:INC:ChkModifyOwnership_021. > I don't know why/how > > in this instance, this distinction makes sense. At > any rate, the doc > > is wrong (pg 55 of config guide). > > > > Lastly, and this is the question I have to get > answer to for which I > > am beating around the bush above...how can I have > somebody > > "responsible" for a list of support groups (they > would review these > > group's tickets on Management console), without > having them receive > > all sorts of notifications that would go to group > members if I made him a > member of that group? > > > > I like the more granular and > closer-to-worldly-common-sense way roles > > and permissions have been defined in ITSM 7, but > the scheme appears > > immature, incomplete, inconsistent and above all, > not fully > > articulated anywhere. I wonder how many inside BMC > can explain to > > anybody in full detail, the way permissions/roles > work in ITSM 7. > > > > I remember doing Tivoli training long time ago in > which understanding > > permissions/roles used by the suite's different > modules came closer to > > being a specialization in itself. With ITSM 7, > it's not as complex, > > but it's certainly confusing. Is there no clear > explanation, precisely > > because it's so confusing/inconsistent?? > > > > Back to the war on error. > > Yeah, no T. I don't think BMC meant to terrify me, > but it surely has > > me pulling my hair figuring out if my > understanding is in error, or > > they have made errors in judgment, design, > execution, documentation.... > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at > www.arslist.org ARSlist:"Where the > === message truncated === ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
