I would look at two things
Assignment and ownership these can be separated (not possible in 6.3) If the Service Desk retains ownership then they can always edit or retrieve a ticket. This is often essential if the ticket is incorrectly assigned, the SD can retrieve the ticket without reference to the assigned group and reassign. Ownership is a configuration within ITSM. With Assignment anyone can work on the ticket as long as they are in the assigned group. Assignment and ownership is separate from permissions. Stuart Schon Service Desk Systems - Manager From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of kunal das Sent: Thursday, 28 February 2013 11:43 AM To: [email protected] Subject: Re: You do not have permission....(users complain) ** Mark - I am really surprised so see you are finding this feature and how ITSM works is not really a good answer for you. This is the most required in any organization you are really serious about there data. Why an emplyee who works in Call Center should have access to a HR ticket.. Why R&D person should be able to access tickets of Support person in any Enterprise.. You are noticing the concept of Multi-tenancy is a feature in BMC Remedy IT Service Management suite (BMC Remedy ITSM suite) that enables you to control which records and configuration data are exposed to a user, based on the user's permissions. User access is controlled through the Company field, which can represent a company, business unit, or other group. You can use both support company access and multi-tenancy to give support companies (vendor companies or operational companies) limited access to data in another company. Using restricted access for support companies," describes how to configure BMC Remedy ITSM suite so that tickets (such as incident requests and change requests) can be assigned to support staff in a support company without giving members of the support company access to other tickets for the customer or contact company. Without this you are exposing everything to everyone unless your Company requirements do not have this. You are comparing 6.3 with 7.6.04 and that is a major release shift and comes with unique features that you will come to know in coming days. How ever I would leave you with this note that Multi tenancy in Remedy is driven by certain core field like 112, and 60900 that governs Row Level Security. You can work on them to stop this feature Hope this helps. Kunal On Thu, Feb 28, 2013 at 3:10 AM, Brittain, Mark <[email protected]> wrote: ** Hi All, This winter we started moving to ITSM 7.6.04 from ARS 6.3 which completely custom applications. On the Incident and Change all of the fields had the Public permission. Anyone could update any Incident or Change regardless of assignment. BMC designed ITSM to be much much more restrictive where you need to right Support Group and/or Functional Role to be able to modify an Incident or Change. So I am getting a lot of complaints from users about this. Incident is assigned to Joe, and Bill worked the issue and can't update/close the Incident because he is not in Joe's group. That's how ITSM works is not really a good answer. I need to be able to explain why. Is there a BMC/ITIL document or white paper that explains why the permissions are this why? Thanks Mark Mark Brittain Remedy Developer ITILv3 Foundation NaviSite - A Time Warner Cable Company [email protected] Office: 315-453-2912 x5335 <tel:315-453-2912%20x5335> Mobile: 315-882.5360 ________________________________ This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
