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"
