There is no white paper that I'm aware of that explains the why. But thinking out loud about the subject just a little bit...
One issue is that the person that is assigned the ticket is assumed to be working the ticket for reporting purposes. They are credited with the number of tickets worked and judged by how long they spend and the results of surveys. Another issue is that the person assigned the ticket is likely working the the ticket themselves. In smaller environments communication is a matter of mentioning "hey, I have a solution" over the cubicle wall. In larger environments, it's not that easy. And another one is that there may be a closing out process. Before sending a message to the end user, the person responsible for solving the ticket would want to verify that the issue is resolved and potentially create a knowledge base article. Anybody can add a work info history entry, so there's that option. There's also the option of configuring some end users such that they have permission to update all tickets. But as you get the complaints, I would ask the question - why are you updating someone else's tickets? It would be better if the tickets were assigned to the people who are working them. As mentioned above - you don't want work duplicated, and you don't want the reports to reflect that some users are more productive than they actually are. Just my 2 cents. Steve On Wed, Feb 27, 2013 at 1:40 PM, 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**** > > 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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
