But this is the exact issue that we are seeing, is that the permissions field is filled with:
Requester Company (Incident - Customer tab Company) Contact Company (Incident - Contact tab company) Incident Owner Company (Incident - Classification tab - Company) A simple 'work around' we considered as well as Christopher mentioned: **Do NOT put in the "Requester Company" and the "Contact Company" into the permissions listing - only put in the 'Incident Owner Company' AND... **Put in the login of the 'Customer' and the login of the 'Contact' However since we are trying to "stay inside the box", this code change takes us outside, and obviously for ALL MODULES (Incident, change, task, ...) The advantages of Multi-Tenancy as Christopher points out far exceed this "glitch", (other than the security aspect :( ) and the options of isolation (cti, templates, ...) Again thanks for all the feedback it IS appreciated!!! Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 503 2701 Fax: +1 408 503 2912 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Thursday, February 15, 2007 12:20 PM To: arslist@ARSLIST.ORG Subject: Re: Implementation Q> ITSM 7 and "Shared People" as 'Generic Contact' Company If only one group in your enterprise needs the restrictions on their tickets, then you have to use multi-tenancy to provide it for them. In our case, it was a requirement from our information security team. On our current 5.5 application we have a customization to row-level-lock a record for their group on CTI, but then they cannot assign it to another group for resolution because that group will never see it; the locking is global in an single-tenancy environment. Once you go with multi-tenancy, you spend the rest of your time making sure that everyone else can see what they need to see in order to do their work. The big advantage is that the complex back-end design allows you to present a much simplified front-end to your users and customers. Right now our support techs have to wade through all of our 1,400 helpdesk and 900 change categorizations in their entirety, including many that other support areas needed but no one else wants to see. Multi-tenancy will enable us to limit our support techs to only those CTI that they need to see and use. Customer Summaries and all of the other tools (templates, decision trees) are able to be simplified in the same manner. We think that the end result will be a much easier application to use (for the support staff) than we have today. We'll have to see how the Requester Console works out - we may still be using all of our ARSPerl CGI scripts to provide guided ticket creation for customers reporting problems/making requests for specific IT systems. Segregation of tickets by the Requester's company should be limited to support staff using their own IDs to place restricted tickets. You need a global customer company that everyone can see, or you will have nothing but trouble creating tickets for them, and then moving those tickets around between groups. Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://remedy.unt.edu/helpdesk/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lammey, Peter A. Sent: Thursday, February 15, 2007 1:35 PM To: arslist@ARSLIST.ORG Subject: Re: Implementation Q> ITSM 7 and "Shared People" as 'Generic Contact' Company I saw how Multi tenacy worked when I attended the Service Desk and Change Management 7.X Administering class and what bothers me with this is that the ticket "segregation" not only occurs for the Companies identified as the Support Company but also based on the Requester's Company. To me that makes no sense. In my opinion no matter what Company the person is a member of that is submitting or requesting a ticket should not make a difference on who can see the ticket. It should be based on what they are requesting (or reporting as an incident) and what group ended up handing their request or incident. Example: If someone in HR puts in the ticket reporting that they have a PC issue, the ticket would go to the Desktop group and the Desktop Group's Company should be the ones that can see the ticket (and also the submitter as well). It should not matter that the person was from HR and their Company is "Human Resources" since the content of the request may not be considered sensitive. On the other hand, if someone in Information Technology submitted a request or incident regarding their pay stub or something with their employment records, then this ticket would go to HR and only HR should be able to see it. Again, it shouldn't matter that the Requester was from IT. What matters is that the ticket by nature is sensitive based on what Operational CTI, etc is identified in the ticket and if it routed to the HR group. I fail to see the value in segregating tickets based on the Requester's Company. Thanks Peter Lammey ESPN MIT Technical Services & Applications Management 860-766-4761 ________________________________________________________________________ _______ 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"
