Editing tickets (comments and replies) - I know the answer, but dont understand why

RT Users
1

Hi-

I’d like to discuss why RT doesnt allow for editing the the comments and correspondance for any give ticket.

I searched thru the archives, and there are a couple threads that when people ask if you can, the answer is one of two things:

  1. No.

  2. No, its against the “philosophy” or RT3 (or Ticketing Systems).

Is anyone up for a discussion on why the answers are that way? I feel that the capability should be there, and should be a permissions setting.

I dont see any reason why the editing of ticket comments or correspondance shouldnt be a feature of RT (or ticketing systems).

Done right, it can be a very good thing. It can provide:

  • cleaning up of tickets for readability
  • condensing tickets to take out any fluff
  • removing of mistakes (oops, i replied to the wrong ticket kind of thing)

Sure, I get that it could be used for evil, but so could other parts of the system.

So, i know that the archives say the answer is NO, but i’d like to challenge that and see if anyone will bite and debate it.

duncan

2

At the risk of Biting…

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.

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.

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?

This is why, like with accounting, nothing is ever “deleted”… even
monumental stuff ups… They just get “adjusted”.

I guess it also comes down to use. I use RT for tracking user support
queries, processing some tasks, and tracking some orders between
vendors. For this reason, I dont want it to be ABLE to be altered.

Maybe if you understand the full ramifications and potential impacts and
pitfalls of having editable tickets, and see it as no issue for
yourself, then go for it, and implement it yourself. Its not that
difficult - in fact I think there is some contrib patches floating
around to enable you to do what you want.

Thats my whole $0.02 worth

Adrian

Duncan Shannon wrote:

Hi-

I’d like to discuss why RT doesnt allow for editing the the comments
and correspondance for any give ticket.

I searched thru the archives, and there are a couple threads that when
people ask if you can, the answer is one of two things:

  1. No.

  2. No, its against the “philosophy” or RT3 (or Ticketing Systems).

Is anyone up for a discussion on why the answers are that way? I feel
that the capability should be there, and should be a permissions setting.

I dont see any reason why the editing of ticket comments or
correspondance shouldnt be a feature of RT (or ticketing systems).

Done right, it can be a very good thing. It can provide:

  • cleaning up of tickets for readability
  • condensing tickets to take out any fluff
  • removing of mistakes (oops, i replied to the wrong ticket kind of thing)

Sure, I get that it could be used for evil, but so could other parts
of the system.

So, i know that the archives say the answer is NO, but i’d like to
challenge that and see if anyone will bite and debate it.

duncan

The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html

Adrian Carter
Technical Manager
Leading Edge Internet

Web http://www.lei.net.au http://support.lei.net.au
Direct +61 2 6163 6162 Support 1 300 662 415
E-mail cartera@lei.net.au

Adrian Carter
Technical Manager
Leading Edge Internet

Web http://www.lei.net.au http://support.lei.net.au
Direct +61 2 6163 6162 Support 1 300 662 415
E-mail cartera@lei.net.au

3

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 :slight_smile:

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

4

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?

I use RT in a corporate setting and also in a nonprofit org setting. In
the former case, we care about the auditability internally. In the latter
case, not at all.

I’m puzzled by the notion that disallowing even an RT sysadmin to delete
or alter content is perceived as somehow providing a level of legal
chain of evidence. All of RT’s data is stored in a relational database,
so anyone who has INSERT, DELETE, or UPDATE access on the tables can
already munge the data anyway they want. The source code and schema are
published information, so it’s not even security-through-obscurity. We
place trust in our sysadmins not to touch the data, but at many sites the RT
admin also has DBA privileges on the back-end database.

IANAL, but I would be very surprised if RT’s lack of a “friendly” delete/
alter feature would make RT hold up in court as an unalterable audit trail.
All the opposing lawyer would have to do is point out how easily the data
could be modified in direct SQL, and that would finish that argument. Just
because it requires technical knowledge to alter the data doesn’t mean a
court would believe it to be impossible. You can still put the sysadmin on
the witness stand and ask, under oath, “Did you alter the data?” That tactic
doesn’t rely on RT somehow providing a false sense of non-alterability.

The only really good mechanisms to achieve nonrepudiation of transactions rely
on public key cryptography to digitally sign the transaction. AFAIK, RT doesn’t
have that capability right now – and even if it did, the courts are still not
settled on just how heavily to weigh evidence that is digitally signed.

My opinion, therefore, is that an option to alter or delete should be available
as a high-level privilege, by default available only to superusers but able
to be delegated to others like any other permission. If a site doesn’t want
people deleting things, then they should leave this permission available only
to the superuser and then not hand out the superuser privilege.

For those subject to spammers creating tickets and userids in RT, the ability
to truly purge that junk rather than just making it invisible would be an
incredibly useful feature.

Scott

Scott Courtney | “I don’t mind Microsoft making money. I mind them
scott@4th.com | having a bad operating system.” – Linus Torvalds
http://4th.com/ | (“The Rebel Code,” NY Times, 21 February 1999)
| PGP Public Key at http://4th.com/keys/scott.pubkey

5

It’s easy to implement “edit record” button, but it’s hard to make
things around this button.

Consider situation: you add reply “it’ll cost you 1000$” with misstake
(there should be 10000$). you submit message, see error and this
button. What are you doing? Click and change? Can you? Would RT notify
about change? What would be in notification? Do you want to think
about notifications at all?

Now, you don’t need to think about all this. You just press reply
again and write something like “I’m terribly sorry, I’ve done
misstake. Price is 10000$.” No one automated diff algorithm generate
that for you.On 1/3/06, Scott Courtney scott@4th.com wrote:

On Monday 02 January 2006 12:25, Duncan Shannon wrote:

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?

I use RT in a corporate setting and also in a nonprofit org setting. In
the former case, we care about the auditability internally. In the latter
case, not at all.

I’m puzzled by the notion that disallowing even an RT sysadmin to delete
or alter content is perceived as somehow providing a level of legal
chain of evidence. All of RT’s data is stored in a relational database,
so anyone who has INSERT, DELETE, or UPDATE access on the tables can
already munge the data anyway they want. The source code and schema are
published information, so it’s not even security-through-obscurity. We
place trust in our sysadmins not to touch the data, but at many sites the RT
admin also has DBA privileges on the back-end database.

IANAL, but I would be very surprised if RT’s lack of a “friendly” delete/
alter feature would make RT hold up in court as an unalterable audit trail.
All the opposing lawyer would have to do is point out how easily the data
could be modified in direct SQL, and that would finish that argument. Just
because it requires technical knowledge to alter the data doesn’t mean a
court would believe it to be impossible. You can still put the sysadmin on
the witness stand and ask, under oath, “Did you alter the data?” That tactic
doesn’t rely on RT somehow providing a false sense of non-alterability.

The only really good mechanisms to achieve nonrepudiation of transactions rely
on public key cryptography to digitally sign the transaction. AFAIK, RT doesn’t
have that capability right now – and even if it did, the courts are still not
settled on just how heavily to weigh evidence that is digitally signed.

My opinion, therefore, is that an option to alter or delete should be available
as a high-level privilege, by default available only to superusers but able
to be delegated to others like any other permission. If a site doesn’t want
people deleting things, then they should leave this permission available only
to the superuser and then not hand out the superuser privilege.

For those subject to spammers creating tickets and userids in RT, the ability
to truly purge that junk rather than just making it invisible would be an
incredibly useful feature.

Scott

–

Scott Courtney | “I don’t mind Microsoft making money. I mind them
scott@4th.com | having a bad operating system.” – Linus Torvalds
http://4th.com/ | (“The Rebel Code,” NY Times, 21 February 1999)
| PGP Public Key at http://4th.com/keys/scott.pubkey

The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html

Best regards, Ruslan.