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: arslist@ARSLIST.ORG 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 Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
