[rt-users] editing tickets (comments and replies) - I know the answer, but dont understand why...

[Duncan Shannon]

HI-

>I support the "NO" basis, even though I regularly go "Doh... if only I could edit that..." . Management used to complain a bit.. >but theres a simple solution: Tell them its just like an Accounting System: No Deletion, Only Adjustments. As soon as they >see the parrallels between a ticketing system used to track events and maintain an 'audit trail' and their 'oh so precious' >Accounting system that essentially behaves the same in this regard its all good.

 
Does the Average RT user need the system to have the same level of integrity and inability to change info to the level of an accounting system? I'd be suprosed if the integrity of the data was that importiant to most of the RT crowd. Anyone?
 

>And why is it important ? Because RT provides full audit trails, and other things which are very handy from a legal >perspective. More than once I've dagged tickets and their entire comment history out and managed to 'head someone off at >the pass' purely with the data that can be provided and can be provided "as presented" with no possibility of it having been >altered.

 
I can surely see where an "unmodified" or "pure" version of the ticket has value in some cases. So... can we not maintain the integrity of each and every ticket (if that really is as importiant as some think) and provide an "unmodified" version in the archives somewhere (or as the primary version) and ALSO have a version of the ticket that is editable, or can be cleaned up that we could slam "NOT ORIGIONAL COPY" all over the place if it was needed?

If the feature of having unmodified tickets is so critical, why not just keep a copy somewhere and provide the ability (for the RT admin) to display the unedite version by default, or the version that $RTUSER with $RT-EDIT-PERMS has modified for easier readability etc.
 
>The moment you add the 'concept' even of being able to edit 'inplace' tickets, it breaks the whole potnetial integrity of the >historical accuracy of the tickets - How can you prove that was the original ticket and not an altered/doctored version if any >old person could edit it?

I am not asking that anyone be able to edit tickets. I think that there are cases where it makes sense, and that there should be the ability to assign or delegate that permission level. 

All it taks is some local (CLI or PhpMyAdmin or something similar) access to the DB, and the integrity is shot w/o too much effort.
 
I see and understand the points made in your email as well as the list archives. I dont think that it has to be all one way or another. Really... I guess i dont need to be able to edit the content of the tickets, but rather the parts of the tickets that are displayed thru the UI... what about being able to HIDE parts of each ticket with java script or other handy dandy web stuff, to make navigting the ticket easier? (Sort of like LINKS/PEOPLE and the other Ticket Meta data can be windowshade open/close)
 
>Maybe if you understand the full ramifications and potential impacts and pitfalls of having editable tickets, and see it as no 
 
I think I do understand them. I am open to the idea that I am missing something. (and of course, im just debating here, not trying to be an ass or anything rude on this thread)
 
>issue for yourself, then go for it, and implement it yourself. Its not that difficult - i
 
Ooh... im not a programmer, and i certainly dont have the underlying knowledge of RT to understand how that works... but I guess that is what programmers are for :)
 
>n fact I think there is some contrib patches floating around to enable you to do what you want.

hmm... i searched the wiki and other ususal places, but didnt find anything. Do you have any ideas on where to look?
 

>Thats my whole $0.02 worth

Thank you.
 
Duncan

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20060102/c65a6e1b/attachment.htm>