Chris, Worse... I got the "I don't have SRM 7.6 installed on my VM"
We did a half hearted test using Operational Categorization and the requester console and it worked on 7.6.03 so I'm hoping it was addressed. I'm throwing up a 7.6.03 Dev environment now so I will let everyone how the testing goes on that. I guess the question is how effective is multi-tenancy for use in reality and not just sales speak? The current workaround is that there is a separate login ID for those users who need access to create requests using the "other" company. It's just clunky when they are used to using SSO and now have to go to the login page. Tauf Chowdhury | Forest Laboratories, Inc. Analyst, Service Management Mobile:646.483.2779 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of strauss Sent: Monday, December 13, 2010 10:42 AM To: [email protected] Subject: Re: Issue with Multi Tenancy and Interface forms I'll bet you get the old "working as designed" response on this one. Most of the ITSM workflow sets Company values based upon the HOME company of the user; whatever their location is in their CTM:People form. This design drove us to create all of our customer accounts in one customer company that everyone has access to - these are synced in from LDAP - and to set most of our categorizations to Global. All of our support staff have a second login account, homed in the appropriate Company for their support organization (there are 26 Operating Companies at our University - distributed support areas and central computing directorates all have their own company). This allows tickets created for user accounts located in the main customer company to use global or customer company categorizations, and to be fairly portable between support companies (there are some other issues there we handled with customization, and with a global Ticket Transfer operational company that all support staff have access to). Tickets created by support staff within their own support company are then secured and private within that company, a capability that our security people also wanted to have. In your case, the simplest solution might be to use Global Product Catalog entries; we have seen enough trouble with company-specific categorizations to have avoided them in our system. Note that we do not use SRM, but even in Kinetic Request it is possible to specify a combination of user account (and therefore Company) with a Location or Categorization that does not match that Company, and get the same sort of Incident creation failure that you are seeing. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Chowdhury, Tauf Sent: Friday, December 10, 2010 11:55 AM To: [email protected] Subject: Issue with Multi Tenancy and Interface forms ** All, I just submitted this as an issue but I wanted to see if any of you tested or ran into this. I'm in SRM 7.6 training and the issue is still present. I apologize in advance if my scenario is confusing but it's the best way I could describe the issue! Here is the scenario and you can test it out in your environments: 1. Joe User on the People form is part of Company A. (Field ID on people form: 1000000001). 2. In the Access Restrictions on the People Form, Joe User has Company A and Company B in his Access Restrictions table. Joe User does not have Unrestricted Access. Joe is a part of support groups in both companies (irrelevant). 3. An Incident Template is created for users in Company B and the Product Catalog Entry that is used is a categorization specific to Company B. 4. Now, an SRD is created for Company B using a PDT and AOT with the Incident Template from #3 related to it. SO far, so good. 5. Joe User goes to Request Entry and because he is a part of both Company A and Company B, he can request the Company B service. Still good! 6. After hitting Submit, however, the Fulfillment Incident is never created and the error is that the Product Categorization is invalid. Upon further investigation, I have found that this is because on the Incident Interface form, there is workflow that looks up Joe User on the people form and uses field ID 1000000001 from the people form to fill in the Company field on the Interface form. Because of this, the Company is set to Company A which doesn't have access to the Product Catalog entry which is specific to Company B. I have tried to hard code the Categorizations and Company on the PDT but this does not work. I am not sure if this is issue has been corrected in 7.6.03/04 but it is definitely a show stopper when it comes to segregating data. -Tauf Chowdhury ________________________________ This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ********************************************************************** This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
