Re: Field 112 control in ITSM 7
Hi Strauss, What we understand is that you want to add group information to Assignee Group(ID 112), dynamically & explicitly. To do this add your own worlflows & dynamic groups to your own fields without affecting the default workflows of ITSM 7. This will definitely save your efforts of reinvention from the scratch. Hope this helps... Regards. *Sandeep Vyom Labs Pvt. Ltd. An ISO 2 certified company. Consulting | Outsourcing | Training || BMC Remedy BSM | ITIL Web : www.vyomlabs.com * strauss wrote: It has become evident that the ITSM 7 application does not, in fact, implement multi-tenancy properly, only a faint shadow of it. We had been led to believe in all of our discussions with engineers at two different UserWorlds (and had not been able to disprove it in testing) that the permissions of an Incident would be modified to reflect the customer, current owner, and current assigned group throughout the life cycle of the request. This is not, in fact, what is taking place, OOTB, at least not once you have patched through 007. The only permissions being posted to the incident are those of the customer - one group id in field 112. Has anyone had to supplement the ITSM 7 application with workflow that dynamically and explicitly adds group information to field 112 for the assigned support group and the owner group, and removes it as the incident changes assignment/ownership? If not, I guess I will be inventing it from scratch - this HAS to work. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com 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: Field 112 control in ITSM 7
As a general rule I try to avoid using "copy to new" unless it is a form I developed. Too many of the OOB forms either have a field that is part of a unique index (which prevents the new record from being saved at all) or a field that controls something like security gets copied and probably shouldn't. Thanks for the heads up on this one. --- J.T. Shyman -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Tuesday, May 13, 2008 5:08 PM To: arslist@ARSLIST.ORG Subject: Re: Field 112 control in ITSM 7 This server and all of my test servers along the way have always been set to Enable Multiple Assign Groups at birth. I know it is working because we have run into another idiosyncrasy where my data manager had copied to new several support staff records from customer records (only the login name differs, then you add all of the permissions to the new record). Those support staff records were visible to other companies that should not have been able to see them. It turns out that they still carried the group ID for the original, global customer company, as well as the new group id for their new home operational company. This only occurs when you copy to new in CTM:People. Thanks for the tips. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of J.T. Shyman Sent: Tuesday, May 13, 2008 3:58 PM To: arslist@ARSLIST.ORG Subject: Re: Field 112 control in ITSM 7 Chris, In my experiments with ITSM 7.0.3 Patch 7 I've found that field 112 on HPD:Help Desk will get set with multiple values if the option "Enable Multiple Assign Groups" is turned on for the AR Server. Additionally, I've found that field 112 gets set with the company values from the Customer, Contact and Categorization tab and NOT from the Assignment tab (and seems to be updated when any of these changes). In other words, Support Company does not get populated into field ID 112. This would seem to be counter-intuitive, no? My guess is that BMC reasoned the categorization and support company would match. Something else to watch out for: If multiple assign groups is enabled and you have an incident with a contact in Company A, a customer in Company B, a categorization from Company C and a Support company of Company D then all users who have access to Company A, Company B or Company C will be able to view the incident. Users in Company D will not be able to. --- J.T. Shyman -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Tuesday, May 13, 2008 4:19 PM To: arslist@ARSLIST.ORG Subject: Field 112 control in ITSM 7 It has become evident that the ITSM 7 application does not, in fact, implement multi-tenancy properly, only a faint shadow of it. We had been led to believe in all of our discussions with engineers at two different UserWorlds (and had not been able to disprove it in testing) that the permissions of an Incident would be modified to reflect the customer, current owner, and current assigned group throughout the life cycle of the request. This is not, in fact, what is taking place, OOTB, at least not once you have patched through 007. The only permissions being posted to the incident are those of the customer - one group id in field 112. Has anyone had to supplement the ITSM 7 application with workflow that dynamically and explicitly adds group information to field 112 for the assigned support group and the owner group, and removes it as the incident changes assignment/ownership? If not, I guess I will be inventing it from scratch - this HAS to work. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com 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: Field 112 control in ITSM 7
This server and all of my test servers along the way have always been set to Enable Multiple Assign Groups at birth. I know it is working because we have run into another idiosyncrasy where my data manager had copied to new several support staff records from customer records (only the login name differs, then you add all of the permissions to the new record). Those support staff records were visible to other companies that should not have been able to see them. It turns out that they still carried the group ID for the original, global customer company, as well as the new group id for their new home operational company. This only occurs when you copy to new in CTM:People. Thanks for the tips. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of J.T. Shyman Sent: Tuesday, May 13, 2008 3:58 PM To: arslist@ARSLIST.ORG Subject: Re: Field 112 control in ITSM 7 Chris, In my experiments with ITSM 7.0.3 Patch 7 I've found that field 112 on HPD:Help Desk will get set with multiple values if the option "Enable Multiple Assign Groups" is turned on for the AR Server. Additionally, I've found that field 112 gets set with the company values from the Customer, Contact and Categorization tab and NOT from the Assignment tab (and seems to be updated when any of these changes). In other words, Support Company does not get populated into field ID 112. This would seem to be counter-intuitive, no? My guess is that BMC reasoned the categorization and support company would match. Something else to watch out for: If multiple assign groups is enabled and you have an incident with a contact in Company A, a customer in Company B, a categorization from Company C and a Support company of Company D then all users who have access to Company A, Company B or Company C will be able to view the incident. Users in Company D will not be able to. --- J.T. Shyman -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Tuesday, May 13, 2008 4:19 PM To: arslist@ARSLIST.ORG Subject: Field 112 control in ITSM 7 It has become evident that the ITSM 7 application does not, in fact, implement multi-tenancy properly, only a faint shadow of it. We had been led to believe in all of our discussions with engineers at two different UserWorlds (and had not been able to disprove it in testing) that the permissions of an Incident would be modified to reflect the customer, current owner, and current assigned group throughout the life cycle of the request. This is not, in fact, what is taking place, OOTB, at least not once you have patched through 007. The only permissions being posted to the incident are those of the customer - one group id in field 112. Has anyone had to supplement the ITSM 7 application with workflow that dynamically and explicitly adds group information to field 112 for the assigned support group and the owner group, and removes it as the incident changes assignment/ownership? If not, I guess I will be inventing it from scratch - this HAS to work. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com 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: Field 112 control in ITSM 7
That seemed the most obvious solution - I just wondered if anyone had done it and had success, i.e., not found serious flaws in it where it would break something else. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Feliciano, Ferdinand, A (Rocky) Sent: Tuesday, May 13, 2008 3:27 PM To: arslist@ARSLIST.ORG Subject: Re: Field 112 control in ITSM 7 Create a workflow on modify that will set the value of field 112 to $group1$ + $group2$ + $group3$. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Tuesday, May 13, 2008 1:19 PM To: arslist@ARSLIST.ORG Subject: Field 112 control in ITSM 7 It has become evident that the ITSM 7 application does not, in fact, implement multi-tenancy properly, only a faint shadow of it. We had been led to believe in all of our discussions with engineers at two different UserWorlds (and had not been able to disprove it in testing) that the permissions of an Incident would be modified to reflect the customer, current owner, and current assigned group throughout the life cycle of the request. This is not, in fact, what is taking place, OOTB, at least not once you have patched through 007. The only permissions being posted to the incident are those of the customer - one group id in field 112. Has anyone had to supplement the ITSM 7 application with workflow that dynamically and explicitly adds group information to field 112 for the assigned support group and the owner group, and removes it as the incident changes assignment/ownership? If not, I guess I will be inventing it from scratch - this HAS to work. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" NOTICE: This e-mail (and any attachments) may contain PRIVILEGED OR CONFIDENTIAL information and is intended only for the use of the specific individual(s) to whom it is addressed. It may contain information that is privileged and confidential under state and federal law. This information may be used or disclosed only in accordance with law, and you may be subject to penalties under law for improper use or further disclosure of the information in this e-mail and its attachments. If you have received this e-mail in error, please immediately notify the person named above by reply e-mail, and then delete the original e-mail. Thank you. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com 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: Field 112 control in ITSM 7
Chris, In my experiments with ITSM 7.0.3 Patch 7 I've found that field 112 on HPD:Help Desk will get set with multiple values if the option "Enable Multiple Assign Groups" is turned on for the AR Server. Additionally, I've found that field 112 gets set with the company values from the Customer, Contact and Categorization tab and NOT from the Assignment tab (and seems to be updated when any of these changes). In other words, Support Company does not get populated into field ID 112. This would seem to be counter-intuitive, no? My guess is that BMC reasoned the categorization and support company would match. Something else to watch out for: If multiple assign groups is enabled and you have an incident with a contact in Company A, a customer in Company B, a categorization from Company C and a Support company of Company D then all users who have access to Company A, Company B or Company C will be able to view the incident. Users in Company D will not be able to. --- J.T. Shyman -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Tuesday, May 13, 2008 4:19 PM To: arslist@ARSLIST.ORG Subject: Field 112 control in ITSM 7 It has become evident that the ITSM 7 application does not, in fact, implement multi-tenancy properly, only a faint shadow of it. We had been led to believe in all of our discussions with engineers at two different UserWorlds (and had not been able to disprove it in testing) that the permissions of an Incident would be modified to reflect the customer, current owner, and current assigned group throughout the life cycle of the request. This is not, in fact, what is taking place, OOTB, at least not once you have patched through 007. The only permissions being posted to the incident are those of the customer - one group id in field 112. Has anyone had to supplement the ITSM 7 application with workflow that dynamically and explicitly adds group information to field 112 for the assigned support group and the owner group, and removes it as the incident changes assignment/ownership? If not, I guess I will be inventing it from scratch - this HAS to work. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com 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: Field 112 control in ITSM 7
Create a workflow on modify that will set the value of field 112 to $group1$ + $group2$ + $group3$. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Tuesday, May 13, 2008 1:19 PM To: arslist@ARSLIST.ORG Subject: Field 112 control in ITSM 7 It has become evident that the ITSM 7 application does not, in fact, implement multi-tenancy properly, only a faint shadow of it. We had been led to believe in all of our discussions with engineers at two different UserWorlds (and had not been able to disprove it in testing) that the permissions of an Incident would be modified to reflect the customer, current owner, and current assigned group throughout the life cycle of the request. This is not, in fact, what is taking place, OOTB, at least not once you have patched through 007. The only permissions being posted to the incident are those of the customer - one group id in field 112. Has anyone had to supplement the ITSM 7 application with workflow that dynamically and explicitly adds group information to field 112 for the assigned support group and the owner group, and removes it as the incident changes assignment/ownership? If not, I guess I will be inventing it from scratch - this HAS to work. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" NOTICE: This e-mail (and any attachments) may contain PRIVILEGED OR CONFIDENTIAL information and is intended only for the use of the specific individual(s) to whom it is addressed. It may contain information that is privileged and confidential under state and federal law. This information may be used or disclosed only in accordance with law, and you may be subject to penalties under law for improper use or further disclosure of the information in this e-mail and its attachments. If you have received this e-mail in error, please immediately notify the person named above by reply e-mail, and then delete the original e-mail. Thank you. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Field 112 control in ITSM 7
We did it but not through group 112. The reason we chose to go that was strategic - we do not know what changes BMC will make in future versions to break whatever we customized. Instead we did it through Dynamic Groups + workflow. In the end it was pretty slick and conditional. Contact me off-list for specifics if you need. William Rentfrow, Principal Consultant [EMAIL PROTECTED] C 701-306-6157 O 952-432-0227 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Tuesday, May 13, 2008 3:19 PM To: arslist@ARSLIST.ORG Subject: Field 112 control in ITSM 7 It has become evident that the ITSM 7 application does not, in fact, implement multi-tenancy properly, only a faint shadow of it. We had been led to believe in all of our discussions with engineers at two different UserWorlds (and had not been able to disprove it in testing) that the permissions of an Incident would be modified to reflect the customer, current owner, and current assigned group throughout the life cycle of the request. This is not, in fact, what is taking place, OOTB, at least not once you have patched through 007. The only permissions being posted to the incident are those of the customer - one group id in field 112. Has anyone had to supplement the ITSM 7 application with workflow that dynamically and explicitly adds group information to field 112 for the assigned support group and the owner group, and removes it as the incident changes assignment/ownership? If not, I guess I will be inventing it from scratch - this HAS to work. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Field 112 control in ITSM 7
It has become evident that the ITSM 7 application does not, in fact, implement multi-tenancy properly, only a faint shadow of it. We had been led to believe in all of our discussions with engineers at two different UserWorlds (and had not been able to disprove it in testing) that the permissions of an Incident would be modified to reflect the customer, current owner, and current assigned group throughout the life cycle of the request. This is not, in fact, what is taking place, OOTB, at least not once you have patched through 007. The only permissions being posted to the incident are those of the customer - one group id in field 112. Has anyone had to supplement the ITSM 7 application with workflow that dynamically and explicitly adds group information to field 112 for the assigned support group and the owner group, and removes it as the incident changes assignment/ownership? If not, I guess I will be inventing it from scratch - this HAS to work. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
