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

RT Users
1

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

Interesting. Has anyone created a contrib or other mod to allow for editing?

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.

Agreed, I think that since a reply went to the requetor, you dont need to think about it… you need to send another message referencing your mistake and provide a correct answer.

So what if we put the debate about change aside, and call it a ‘modify what you see’ thing… so instead of debating on wether or not the DB should be changed, we talk about wether or not there is a way to filter out parts of tix you dont want, or a way to minimize certain correspondance, or mark it “not interesting” or “filter me” so that when others go to view ticket, they see that there is some other content, but someone has already “Edited” it, or marked it as “not importiant, filter this out but still show that there is something behind me!”

duncanOn 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.

2

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.

Agreed, I think that since a reply went to the requetor, you dont need
to think about it… you need to send another message referencing your
mistake and provide a correct answer.

I can see this point. I don’t think the editing function is as important to
most of us as deletion, again because of the spam problem. I really don’t
want my database clogged with advertising.

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

3

If killing old records in their entirety is your only concern - Then use
Ruslan’s RTx::Shredder app to clean all tickets you have marked in the
DB as “Deleted”.

That will solve the “DB Clutter” issue without concern for messing
around with worry about ‘editing tickets’.

Now - An ability to dynamic filter the ticket display to only show X
updates or comments or whatever would be nice - but thats a different
request and more just a UI feature

Oh - And to all - my comments before about absoloute integrity was not
so much in a ‘gurantee in a court of law’ - more that for the most part
people are accepting the data is accurate because not even I can fudge
it (Not allowing for direct DB manipulation - but this is true of any
electronic storage medium without signatures as stated)- I’ve never had
RT tickets tested in court but I’ve used them a number of times and
demonstrated the audit trail and that has been sufficent for my purposes.
Cheers

Adrian

Scott Courtney wrote:>On Monday 02 January 2006 23:00, Duncan Shannon wrote:

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.

Agreed, I think that since a reply went to the requetor, you dont need
to think about it… you need to send another message referencing your
mistake and provide a correct answer.

I can see this point. I don’t think the editing function is as important to
most of us as deletion, again because of the spam problem. I really don’t
want my database clogged with advertising.

Scott

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

4

At Monday 1/2/2006 11:55 PM, Scott Courtney wrote:

I don’t think the editing function is as important to
most of us as deletion, again because of the spam problem. I really don’t
want my database clogged with advertising.

Scott

With spam, you’re talking about deleting whole tickets rather than
individual transactions, so it’s a different issue.

Re. deleting transactions, a Delete method did appear in the Transaction
API somewhere in the 3.4 series (I think) and I’ve used it successfully,
although there’s no UI control to invoke it (yet?).

The ability to edit history was requested by our Help Desk - to do things
like clean up tickets (remove large amounts of re-quoted emails etc.). We
shied away from doing this, because it seemed it would be a fairly
fundamental change and the ramifications of making history editable could
not easily be determined. I did find a piece of code with a comment
something like “history does not change so we can do this caching here to
improve performance” - the comment led me to believe that implementing
editable history would break this caching and hurt performance. And it also
made me wonder how many other pieces of code relied on the
history-not-editable assumption but are perhaps not so explicitly
commented. Basically, we were afraid that without spending a long time in
the code, it might really mess things up to make history editable.

To Duncan - thanks for bringing this up for debate, it’s an interesting topic.

Steve

5

With spam, you’re talking about deleting whole tickets rather than
individual transactions, so it’s a different issue.

Re. deleting transactions, a Delete method did appear in the Transaction
API somewhere in the 3.4 series (I think) and I’ve used it successfully,
although there’s no UI control to invoke it (yet?).

In my company’s use of RT, someone renamed the “deleted” status to “dead”, to
better indicate that the ticket is marked as defunct but is not physically
removed from the database. (This happened before I took over as RT admin,
but I think it’s a good idea.)

I’ll check out that Shredder applet. Sounds useful. My only concern is that
I might not want to wipe out all deleted tickets. Sometimes there is a need
to mark a ticket as “killed this project” but still have it available for
search later. That’s what we use “dead” status for…on rare occasions, one
of those tickets gets resurrected. The only ones I’d want to truly nuke from
the database are the spams, which have no historical value at all.

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

6

With spam, you’re talking about deleting whole tickets rather than
individual transactions, so it’s a different issue.

Re. deleting transactions, a Delete method did appear in the Transaction
API somewhere in the 3.4 series (I think) and I’ve used it successfully,
although there’s no UI control to invoke it (yet?).

In my company’s use of RT, someone renamed the “deleted” status to “dead”, to
better indicate that the ticket is marked as defunct but is not physically
removed from the database. (This happened before I took over as RT admin,
but I think it’s a good idea.)

I’ll check out that Shredder applet. Sounds useful. My only concern is that
I might not want to wipe out all deleted tickets. Sometimes there is a need
to mark a ticket as “killed this project” but still have it available for
search later. That’s what we use “dead” status for…on rare occasions, one
of those tickets gets resurrected. The only ones I’d want to truly nuke from
the database are the spams, which have no historical value at all.
As you understand I couldn’t implement AI into shredder tool that
calculate value. If you can find tickets you want to wipeout forever
then this could be implemented into shredder with
RTx::Shredder::Plugin::*. Last versions has “search plugins” feature
that allow to select objects for deletion with custom code.

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

Best regards, Ruslan.

7

The other solution is to introduce a new Status called ‘dead’ and rename
‘deleted’ to dead, and then that at least fixes the problem moving
forward → dead is a synonym for resolved or deleted or whatever and
deleted means that : deleted.

You could bulk update old project files and mark them under the newly
defined status and then run Shredder on the deleted tickets - voila -
problem solved without complex search funxtions

Scott Courtney wrote:>On Tuesday 03 January 2006 10:11, Stephen Turner wrote:

With spam, you’re talking about deleting whole tickets rather than
individual transactions, so it’s a different issue.

Re. deleting transactions, a Delete method did appear in the Transaction
API somewhere in the 3.4 series (I think) and I’ve used it successfully,
although there’s no UI control to invoke it (yet?).

In my company’s use of RT, someone renamed the “deleted” status to “dead”, to
better indicate that the ticket is marked as defunct but is not physically
removed from the database. (This happened before I took over as RT admin,
but I think it’s a good idea.)

I’ll check out that Shredder applet. Sounds useful. My only concern is that
I might not want to wipe out all deleted tickets. Sometimes there is a need
to mark a ticket as “killed this project” but still have it available for
search later. That’s what we use “dead” status for…on rare occasions, one
of those tickets gets resurrected. The only ones I’d want to truly nuke from
the database are the spams, which have no historical value at all.

Scott

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

8

At Monday 1/2/2006 11:55 PM, Scott Courtney wrote:

I don’t think the editing function is as important to
most of us as deletion, again because of the spam problem. I really don’t
want my database clogged with advertising.

Scott

With spam, you’re talking about deleting whole tickets rather than
individual transactions, so it’s a different issue.

Re. deleting transactions, a Delete method did appear in the Transaction
API somewhere in the 3.4 series (I think) and I’ve used it successfully,
although there’s no UI control to invoke it (yet?).
No, there is no UI control and really each object in RT has Delete
method. In some classes this method delete also dependencies, but in
other could leave stale data in DB. I didn’t check that method in RT,
but I do know that with transaction you want delete at least all
attachments, attributes and custom field values tied to the txn.

The ability to edit history was requested by our Help Desk - to do things
like clean up tickets (remove large amounts of re-quoted emails etc.). We
shied away from doing this, because it seemed it would be a fairly
fundamental change and the ramifications of making history editable could
not easily be determined. I did find a piece of code with a comment
something like “history does not change so we can do this caching here to
improve performance” - the comment led me to believe that implementing
editable history would break this caching and hurt performance. And it also
made me wonder how many other pieces of code relied on the
history-not-editable assumption but are perhaps not so explicitly
commented. Basically, we were afraid that without spending a long time in
the code, it might really mess things up to make history editable.

To Duncan - thanks for bringing this up for debate, it’s an interesting topic.

Steve

Best regards, Ruslan.

9

First sentence didn’t make sense.

I meant create new status “Dead”, then rename the bodged “dead” back to
its original “Deleted”. Then do the clean up then do the shred.

The other solution is to introduce a new Status called ‘dead’ and rename
‘deleted’ to dead, and then that at least fixes the problem moving
forward → dead is a synonym for resolved or deleted or whatever and
deleted means that : deleted.

You could bulk update old project files and mark them under the newly
defined status and then run Shredder on the deleted tickets - voila -
problem solved without complex search funxtions

Scott Courtney wrote:>On Tuesday 03 January 2006 10:11, Stephen Turner wrote:

With spam, you’re talking about deleting whole tickets rather than
individual transactions, so it’s a different issue.

Re. deleting transactions, a Delete method did appear in the Transaction
API somewhere in the 3.4 series (I think) and I’ve used it successfully,
although there’s no UI control to invoke it (yet?).

In my company’s use of RT, someone renamed the “deleted” status to “dead”, to
better indicate that the ticket is marked as defunct but is not physically
removed from the database. (This happened before I took over as RT admin,
but I think it’s a good idea.)

I’ll check out that Shredder applet. Sounds useful. My only concern is that
I might not want to wipe out all deleted tickets. Sometimes there is a need
to mark a ticket as “killed this project” but still have it available for
search later. That’s what we use “dead” status for…on rare occasions, one
of those tickets gets resurrected. The only ones I’d want to truly nuke from
the database are the spams, which have no historical value at all.

Scott

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