I'd like to see the title change reflected, too. In the past, whenever I've changed a title I've had to post both the previous title and new title as an Edit to the ticket. I do this not only for record-keeping, but also because users employ many different keywords and terms when doing a Search.
This is equally true for linking, which I also have to post as an Edit (a) in order for users to know that something has now been linked, and (b) in order for the linked ticket number to show up in a keyword Search.
I do agree with Nathan about electronic record integrity, though that bumps up against what I see as an equally significant need (with potentially costly legal repercussions) to edit out PII (personally identifiable information) in accordance with Privacy regulations (HIPAA, FERPA, COPPA, Gramm-Leach Bliley, etc.).
To that end, I've inquired in the past about an "Administrative Edit" capacity. I have issues with users from different regions posting *names* instead of IDs, when other regions' users have no legitimate business reason to see them.
This means--short of the suggested "Administrative Edit" capacity--I have no way to protect the privacy of that individual other than to delete the entire ticket and re-post it with the PII content edited out.
This has become a huge burden on me as an Admin. It is especially more burdensome when the posting of the PII occurs much later on the ticket, when several attachments have already been uploaded in earlier posts, &/o tickets have been interlinked. I then have to first download and save attachments in order to re-upload to the new (edited) ticket, and I also have to re-edit any /linked/ tickets to note where the new links are pointing.
From the highest-level view, an Admin user's ability to Delete an entire ticket is in itself effectively an "integrity" issue, so--as with all of these regulations--it all comes down to the "performed in accordance ... within reason" clause that's typically embedded in all these statutes.
We do need to be able to easily reflect all changes for integrity purposes, but we also need to put the necessary Admin Edit capacity in the hands of those Admins duly tasked with privacy and security compliance.
The only way I can see to do this is to employ an NTK-style metadata capacity at the database level to allow Admin users a view of the content that regular users cannot see. When an Admin edits a ticket, the original data do not get deleted, only deleted from all other users' view. The edited content, now “managed” by surrounding it with a metadata tag effectively indicating "Admin access only" (ex: <AdmOnly>edited content</AdmOnly>) is then “skipped” by the content display routine, and no longer visible to regular users.
Problem solved! :-)
