Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits
++ 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: arslist@ARSLIST.ORG 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: 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
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: 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
Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits
That is correct. Custom notifications that YOU create can be treated that way, but not the OOB ones. You will have to control that via group membership and availability. Rick On 11/1/07, T. Dee [EMAIL PROTECTED] wrote: Rick - you mean that I can not turn off a notifications by user? For example - John Smith does not want to receive notifications when he OPENS a new Incident, but wants to receive Notifications when his Incident is Resolved. 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: [Hide Quoted Text] 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 [Hide Quoted Text] 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? [Hide Quoted Text] 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 Received: from apotex.apotex.com (apotex.apotex.com [209.29.196.10]) by webmail.bellhosting.com (Webmail 2.0) with HTTP for [EMAIL PROTECTED]; Thu, 01 Nov 2007 13:40:37 -0400 Message-ID: [EMAIL PROTECTED] Date: Thu, 01 Nov 2007 13:40:37 -0400 From: Tyrone Dee [EMAIL PROTECTED] To: arslist@arslist.org Subject: Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding
Roles in Incident Management 7.x: App doesn't match the doc other tidbits
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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
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
Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits
In Functional Role Update for my support account record, in my primary (default) support group, in the Functional Role pull-down, I see: Change Infrastructure Change Approver Infrastructure Change Assignee Infrastructure Change Manager Release Manager Foundation Broadcast Submitter Support Group Admin Support Group Manager Incident Incident Manager Support Group Lead Problem Problem Manager SLM Service Level Manager The roles you seek are all there, but under different headings. Don't be confused by the documentation for ITSM 7 - it has very little to do with the actual application as installed (and patched) that you are exploring on your server ;-) Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi Sent: Wednesday, October 24, 2007 12:46 PM To: arslist@ARSLIST.ORG Subject: Roles in Incident Management 7.x: App doesn't match the doc other tidbits 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ _ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits
Its always a nice thing when documentations contradict functionality isn't it :-) I wonder whether that is the new ITIL standard where documentations mean net to nothing. Apparently its not too rare to find documentations that contradict requirements or functionality etc.. Be prepared to find things in the wrong places when installing help for certain applications too. I do not remember which applications I found those but I did come across that recently with the new version of one of the applications that I had installed. The directory name as well as the path to where you find that directory was wrongly documented in the help install guide section.. Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of strauss Sent: Wednesday, October 24, 2007 2:18 PM To: arslist@ARSLIST.ORG Subject: Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits In Functional Role Update for my support account record, in my primary (default) support group, in the Functional Role pull-down, I see: Change Infrastructure Change Approver Infrastructure Change Assignee Infrastructure Change Manager Release Manager Foundation Broadcast Submitter Support Group Admin Support Group Manager Incident Incident Manager Support Group Lead Problem Problem Manager SLM Service Level Manager The roles you seek are all there, but under different headings. Don't be confused by the documentation for ITSM 7 - it has very little to do with the actual application as installed (and patched) that you are exploring on your server ;-) Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi Sent: Wednesday, October 24, 2007 12:46 PM To: arslist@ARSLIST.ORG Subject: Roles in Incident Management 7.x: App doesn't match the doc other tidbits 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
Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits
Hope somebody addresses this in Vancouver. My customers are saying they pay to much to be QA for BMC. Good luck all. R _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Wednesday, October 24, 2007 1:50 PM To: arslist@ARSLIST.ORG Subject: Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits ** Its always a nice thing when documentations contradict functionality isn't it :-) I wonder whether that is the new ITIL standard where documentations mean net to nothing. Apparently its not too rare to find documentations that contradict requirements or functionality etc.. Be prepared to find things in the wrong places when installing help for certain applications too. I do not remember which applications I found those but I did come across that recently with the new version of one of the applications that I had installed. The directory name as well as the path to where you find that directory was wrongly documented in the help install guide section.. Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of strauss Sent: Wednesday, October 24, 2007 2:18 PM To: arslist@ARSLIST.ORG Subject: Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits In Functional Role Update for my support account record, in my primary (default) support group, in the Functional Role pull-down, I see: Change Infrastructure Change Approver Infrastructure Change Assignee Infrastructure Change Manager Release Manager Foundation Broadcast Submitter Support Group Admin Support Group Manager Incident Incident Manager Support Group Lead Problem Problem Manager SLM Service Level Manager The roles you seek are all there, but under different headings. Don't be confused by the documentation for ITSM 7 - it has very little to do with the actual application as installed (and patched) that you are exploring on your server ;-) Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi Sent: Wednesday, October 24, 2007 12:46 PM To: arslist@ARSLIST.ORG Subject: Roles in Incident Management 7.x: App doesn't match the doc other tidbits 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
Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits
Do you have your installation logs? The installation logs are the best things that would tell you if there was a problem with importing any of the core config data. You should be able to see a readable summary of these logs on the .html log files found in the Log file directory of all applications. The other .log files are however more useful as they usually have the reason for failure. If you see reasons like the data already exists you can ignore such failures. But failures that occur after timeouts etc are the ones that you got to beware of. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Rabi Tripathi Sent: Wednesday, October 24, 2007 3:46 PM To: arslist@ARSLIST.ORG Subject: Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits Rick: I am always dismayed when you start sympathizing/empathizing with me, because I start singing...If not Rick, then who?...will know the answer. :( Christopher: My installation doesn't have Support Group Admin and Support Group Manager. Not under Foundation, not anywhere else. I will dig in to see why. What modules do you have installed? I have all except AM. The big question is still there. On Management Console, can I have anybody see/manage tickets that belong to a list of groups, without having to make him a member of those groups (which would trigger all group notifications to them?) How? Can't we allow some self-described VIP to have a sense of total control, without bothering him with all the details of how the underlings are earning their pay every day? - Original Message From: strauss [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Wednesday, October 24, 2007 2:18:10 PM Subject: Re: Roles in Incident Management 7.x: App doesn't match the doc other tidbits In Functional Role Update for my support account record, in my primary (default) support group, in the Functional Role pull-down, I see: Change Infrastructure Change Approver Infrastructure Change Assignee Infrastructure Change Manager Release Manager Foundation Broadcast Submitter Support Group Admin Support Group Manager Incident Incident Manager Support Group Lead Problem Problem Manager SLM Service Level Manager The roles you seek are all there, but under different headings. Don't be confused by the documentation for ITSM 7 - it has very little to do with the actual application as installed (and patched) that you are exploring on your server ;-) Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi Sent: Wednesday, October 24, 2007 12:46 PM To: arslist@ARSLIST.ORG Subject: Roles in Incident Management 7.x: App doesn't match the doc other tidbits 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
