<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>Re: [rt-users] editing tickets (comments and replies) - I know theanswer, but dont understand why...</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText98938 dir=ltr>
<DIV dir=ltr> </DIV></DIV>
<DIV>
<P><FONT size=2>>It's easy to implement "edit record" button, but it's hard
to make<BR>>things around this button.<BR></FONT></P><FONT
size=2></FONT></DIV>
<P><FONT size=2>Interesting. Has anyone created a contrib or other mod to
allow for editing? </FONT></P>
<P><FONT size=2> </P>
<P><BR>>Consider situation: you add reply "it'll cost you 1000$" with
misstake<BR>>(there should be 10000$). you submit message, see error and
this<BR>>button. What are you doing? Click and change? Can you? Would RT
notify<BR>>about change? What would be in notification? Do you want to
think<BR>>about notifications at all?<BR><BR>>Now, you don't need to think
about all this. You just press reply<BR>>again and write something like "I'm
terribly sorry, I've done<BR>>misstake. Price is 10000$." No one automated
diff algorithm generate<BR>>that for you.<BR></P>
<P>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.</P>
<P><BR>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!"</P>
<P> </P>
<P>duncan</P>
<P> </P>
<P><BR>On 1/3/06, Scott Courtney <scott@4th.com> wrote:<BR>> On Monday
02 January 2006 12:25, Duncan Shannon wrote:<BR>> > Does the Average RT
user need the system to have the same level of<BR>> > integrity and
inability to change info to the level of an accounting<BR>> > system? I'd
be suprosed if the integrity of the data was that<BR>> > importiant to
most of the RT crowd. Anyone?<BR>><BR>> I use RT in a corporate setting
and also in a nonprofit org setting. In<BR>> the former case, we care about
the auditability internally. In the latter<BR>> case, not at
all.<BR>><BR>> I'm puzzled by the notion that disallowing even an RT
sysadmin to delete<BR>> or alter content is perceived as somehow providing a
level of legal<BR>> chain of evidence. All of RT's data is stored in a
relational database,<BR>> so anyone who has INSERT, DELETE, or UPDATE access
on the tables can<BR>> already munge the data anyway they want. The source
code and schema are<BR>> published information, so it's not even
security-through-obscurity. We<BR>> place trust in our sysadmins not to touch
the data, but at many sites the RT<BR>> admin also has DBA privileges on the
back-end database.<BR>><BR>> IANAL, but I would be *very* surprised if
RT's lack of a "friendly" delete/<BR>> alter feature would make RT hold up in
court as an unalterable audit trail.<BR>> All the opposing lawyer would have
to do is point out how easily the data<BR>> could be modified in direct SQL,
and that would finish that argument. Just<BR>> because it requires technical
knowledge to alter the data doesn't mean a<BR>> court would believe it to be
impossible. You can still put the sysadmin on<BR>> the witness stand and ask,
under oath, "Did you alter the data?" That tactic<BR>> doesn't rely on RT
somehow providing a false sense of non-alterability.<BR>><BR>> The only
really good mechanisms to achieve nonrepudiation of transactions rely<BR>> on
public key cryptography to digitally sign the transaction. AFAIK, RT
doesn't<BR>> have that capability right now -- and even if it did, the courts
are still not<BR>> settled on just how heavily to weigh evidence that is
digitally signed.<BR>><BR>> My opinion, therefore, is that an option to
alter or delete should be available<BR>> as a high-level privilege, by
default available only to superusers but able<BR>> to be delegated to others
like any other permission. If a site doesn't want<BR>> people deleting
things, then they should leave this permission available only<BR>> to the
superuser and then not hand out the superuser privilege.<BR>><BR>> For
those subject to spammers creating tickets and userids in RT, the
ability<BR>> to truly purge that junk rather than just making it invisible
would be an<BR>> incredibly useful feature.<BR>><BR>>
Scott<BR>><BR>> --<BR>>
------------------------------------------------------------------------------<BR>>
Scott Courtney | "I don't mind
Microsoft making money. I mind them<BR>>
scott@4th.com | having a
bad operating system." -- Linus Torvalds<BR>> <A
href="http://4th.com/">http://4th.com/</A>
| ("The Rebel Code," NY Times, 21 February
1999)<BR>>
| PGP Public Key at <A
href="http://4th.com/keys/scott.pubkey">http://4th.com/keys/scott.pubkey</A><BR>>
_______________________________________________<BR>> <A
href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</A><BR>><BR>>
Be sure to check out the RT Wiki at <A
href="http://wiki.bestpractical.com">http://wiki.bestpractical.com</A><BR>><BR>>
Download a free sample chapter of RT Essentials from O'Reilly Media at <A
href="http://rtbook.bestpractical.com">http://rtbook.bestpractical.com</A><BR>><BR>>
WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and<BR>>
San Francisco - Find out more at <A
href="http://bestpractical.com/services/training.html">http://bestpractical.com/services/training.html</A><BR>><BR><BR><BR>--<BR>Best
regards, Ruslan.<BR></P></FONT>
</BODY>
</HTML>