Edit ticket comments

[tim.alsop@…]

It is common for users to make mistakes when entering comments - when this happens, do we close the whole ticket and re-enter the comments correctly, then continue - surely not ! What would be more acceptable is a capability to edit comments in a ticket as long as appropriate permissions are provided (not everybody should be able to edit comments).

[anonymous]

It should also be possible to edit/change the ticket description. It might also be useful to delete comments from a ticket so that a corrected comment can be added ...

[anonymous]

There should be some kind of history for edits and removals, something like the wikipages maybe?

[daniel]

Allowing editing of any comment has a couple of major drawbacks:

• Easy to abuse. Simply erase everyones comments (script it for more havoc).
• Comments are not tied to a user or session. Too complicated.

Allowing an admin (TICKET_ADMIN perm) to delete comments should be quite sufficient. It's ok to make mistakes, and it's ok to resubmit a corrected comment.

The communication with the humans of the project still works. ;)

[anonymous]

I still think that not being able to edit comments is a major hassle. What if the Ticket already has comments that you want to keep around?

To minimize abuse, perhaps only allow the author of the ticket, or TICKET_ADMIN, the ability to edit a given Ticket.

I don't think the ability to edit a comment is as crucial. It's just the editing of Tickets themselves that's really a problem.

[josh aka anonymous above]

Sorry, and when I said "I still".. I did not mean that I am involved with any of the above discussion... I just came back looking to see if anyone else wanted this feature, and added my desire to the list. :)

[bkc@…]

I would like to be able to edit my comments on a ticket. I'm a big-boy, I have the TRAC_ADMIN permission, I think I should be able to edit my comments on tickets.

I forgot to indicate #!sql colorizing for a code fragment in a ticket comment and I want to go back and change it.

So, here's another vote for this feature, especially for TRAC_ADMIN

[cboos@…]

Yes, nearly the same for me (I left countless wrong #!diff markups instead of #!text/x-diff all over Trac...). Something like what I proposed for editing attachments in #948 is needed here: the TICKET_ADMIN or the creator of the comment should be able to modify/delete it.

[louis@…]

I'm interested in this too.

[cboos]

#1180 has been marked as duplicate of this ticket

[d.mills@…]

I'm not too sure about deleting comments being that good an idea, mabey a moderate down options (like what's used on www.osnews.com) would be more appropriate.

Like that abuse can be screened, but stuff can't just disapear.

[anonymous]

I think a TICKET_ADMIN permission, to be able to edit all comments, would be helpful. Or a default permission for any user to edit his or her own comments.

For example, I added the wrong "closed by changeset [111]" and I had to append another comment, instead of just editing the comment. That was kind of annoying.

I noticed something else, I renamed a module and the earlier comments continued to refer to the old module name. They did not update as I had expected.

[cboos]

Well, in the long term, I would suggest a default setup in which the ticket description, as well as the ticket comments, are editable by anyone, in true Wiki spirit.

Of course, this implies proper history management, such a possibility to revert changes, in order to control ticket butchers :) (e.g. see the tortured change history of #126 ...)

[anonymous]

Authorized person should be able to change wrong comments and to cleanup and clarify history. Otherwise there is a lot of crap gets accumulated in comments which is totally useless and obscures overall picture.

[fg@…]

Something that happens all the time for us is that a user reports a python traceback in a comment, but without the proper {{{ }}}. As an administrator I want to edit the comments and fix the formatting.

[cboos]

Note that by editing the comment, one would loose the old content. Is that OK?

If not, one possibility would be to do the following:

• edit the old comment, save it
• this creates a brand new comment, referring to the old
• to old comment is marked as deleted, it would be still listed, but with an empty content. Only the "TICKET_ADMIN" would have the possibility to view the old content (and eventually to undelete it?)

[Joe Wreschnig <piman at sacredchao.net>]

One of our tickets got spammed. I expect this to happen significantly more in the future, because well, that's how spam works. It'd be really nice to be able to remove/elide it without database twiddling.

[cboos]

In the case of spam, it would make sense to delete the whole comment.

But concerning the "normal" case, I would still be interested in getting some feedback to the question I asked two comments above, before starting to implement something.

[Jeff Forcier (jforcier at strozllc dot com)]

I'd be fine with an edit simply replacing the old content, believing that the case of a ticket admin wanting to make honest, necessary changes to a comment would be much more common than some evil, evil ticket admin wanting to screw with things.

On the please-don't-lose-any-data side of things, I think the best route would be a comment change history as in wiki pages or source files. Assuming that's a little too complex, your suggestion (mark old comment as deleted, created the 'edit' as a new one w/ pointer to old) would work pretty well, provided the 'deleted' comments don't take up much room vertically--otherwise a ticket with lots of comment edits would start to look really messy.

Perhaps replace the comment text in-place, but put small links in the bottom of the comment that would bring up the previous version(s) of the edit? That gets dangerously close to needing a history, though.

[chris@…]

The main reason I want this is to delete spam comments. I spent an hour in sql yesterday deleting a ton of spam comments on the Growl trac, having a button or some checkboxes to delete them all would be nice, since I'm the only one with access to actually remove spam comments right now.

Giving other devs the ability to remove spam comments would be great.

[mgood]

This is not a test system. Do not abuse it.

[anonymous]

I'm starting to look at Trac for issue tracking on a system that has SLA requirements including response time to customer issues. From my perspective, any change that basically allowed a revisionist view of history would not allow Trac to be a valuable tool to demonstrate to our customers that their issues are being responded to in a timely and appropriate fashion.

Having worked with other tracking systems in the past, I'm painfully aware of many of the issues related to mal-formed comments and "wrong" comments (e.g., "Fixed") making the narrative less-than-readable.

I don't have a significant issue with being able to edit comments, as long as all history is preserved and easily viewable.

[chris@…]

Whereas my main issue with not being able to is that my admins are unable to remove spam in a timely manner.

[Joe Wreschnig]

If people with administration permissions are going to do malicious things, whether it's delete real tickets or make it look like things were fixed "too fast", a full history isn't going to stop them. Using Trac to prevent "revisionist history" is stupid, when someone could just go in and muck with the database manually if you were intent on fleecing someone (I'm not saying you are, I'm saying that holding up "Trac logs everything" to the customer as proof you're not is worthless).

DELETE_COMMENT_FOREVER_FOR_REAL and DELETE_TICKET_FOREVER_FOR_REAL is a feature that you need to deal with spam, period. Hiding it doesn't cut it, it still lowers your search engine rankings and raises the spammer's (and so makes the spamming effective, and so people keep spamming). You need to delete it forever. And ticket spam is a real problem that is here, now, and growing, as opposed to "oh, we might lose a valuable comment."

Please, just allow comment deletion. Screw history.

[lycos42@…]

Same here, spam is getting everywhere, we should really have this feature, or at least another method to limit spam without using meta possibilities (catchpas, spam detection system(spamlookup))

It's a major problem.

[jacob@…]

Not to pile on, but we just got hit by a spambot that looks like it's deliberatly targetting Trac (it hit every *open* ticket, but none of the closed ones). Spam bad, mmmmkay?

[lycos42@…]

Same here, our trac installation has just been targeted again :-( ...

Is there any "unofficial way" to edit/block spam actually ?

[chris@…]

Ya, we just got hit again too. I'm probably just going to disable anon access to everything since going into the database is just getting annoying.

[anonymous]

Deleting tickets is simply not good enough. I'm evaluating Trac as bug tracking application for our project, but without some functional spam blocking for ticket comments I don't see how it could remain useful in the long run.

We are currently using a forum for bug/issue reporting, and we see hundreds of spambot hits per day occasionally. There is no way to handle this by simply deleting posts - they must be prevented. Our solution is to block posts with hyperlinks - plain URLs are fine, but hyperlinks are not. So far, this works perfectly.

From our experience, I'm pretty sure that any Trac installation will have to shut down or disable ticket comments sooner or later, as long as there is no spam blocking provided.

[cboos]

This ticket is not about spam prevention, see #1145 for that.

Editing/Deleting ticket comments is also useful beyond spam healing.

[Gunnar Wagenknecht <gunnar@…>]

I think that moderating/editing/deleting comments should never be done for spam prevention. There are much better options (for example, don't allow anonymous posting).

When I usually comment on an issue in any ticket system I always expect that my ticket content will never be modified by somebody else. It's like sending an email to a mailing list and then allowing the list moderator to change the content of the mail.

Unfortunately, there are some ticket systems, which introduced this capability. The system in our corporate environment also allows. However, all system limit the editing capability to the creator of the specific comment/note or an admin. With each change a log is generated in the ticket history covering the editor's name.

There a lot large communities out there using Bugzilla. All community members have been able to work around the missing editing cabability since their beginning so honestly, I don't understand people using this as a reason for not using Track or Bugzilla.

Anyway, if such a capability is implemented it should be completely configurable, i.e. allowing the admin to define if anybody, only the admin, only the ticket owner or only the comment creator should be able to edit comments or if this capability should be completly disabled. Preferable the default should be disabled ;)

It should be also noted in the ticket history and/or next to the comment that this comment was edited on xxx by user yyy or that the comment was deleted.

I don't think that it's necessary to keep the old comment content around although this would be a nice option to correct accidental edits/deletes.

[chris@…]

So if you don't allow anonymous posting, how do public projects allow their users to post tickets to trac?

[Gunnar Wagenknecht <gunnar@…>]

So if you don't allow anonymous posting, how do public projects allow their users to post tickets to trac?

That's pretty simple. Allow them to register with their email address first. Doesn't provide Track such a feature?

[cboos]

Also, some installations create a guest user (with rights similar to those of anonymous), and publish the password somewhere, on their Mailing List or simply on the Wiki.

That's quite effective too, and doesn't require much effort on the admin side.

Speaking of the ticket itself, I'll try to come up with a prototype during those xmas holidays...

[cmlenz]

Also, some installations create a guest user (with rights similar to those of anonymous), and publish the password somewhere, on their Mailing List or simply on the Wiki.

The problem with this approach is that all users going through the guest account basically share one session, and thus cannot set their mail address and name so that it is used when posting tickets. Therefore I think this approach should be considered a workaround, not a real solution.

[cmlenz]

(Moving non-trivial enhancements to next milestone)

[dkocher@…]

Tickets get [spammed http://trac.cyberduck.ch/ticket/69]. It should really be possible to just delete these comments .

[anonymous]

Also interested in seeing this feature added. Too many occasions where it's necessary and it's a major adoption hurdle for some.

[anonymous]

originally i expected a comment or description be a normal wiki page (as it uses wiki syntax too), having a history. this would be the best i could imagine. we are also "signing a contract" with a partner, and it would help a lot having the history.

[eblot]

About last comment: you have history, as all comments are kept.

I agree with the original comment from daniel (05/24/04): comments could be edited by the admin (to remove spam, etc.), not by users. If you want Wiki history feature, simply use a wiki page and add a link from a ticket to the Wiki page. Comments should be preserved and be shown with no specific action from the user, as with many other bug tracking tools. Keep it simple.

[chris@…]

As of right now, anyone with access to sql can just remove it. This is probably the same person who is the admin. I see no point in leaving a history when it's just spam being deleted. If you can trust your trac-admin, who can you trust?

[jacob@…]

It's not that simple, Chris -- ticket spammers are also changing ticket properties, so just deleting the comment doesn't fix the incorrect info. There needs to be a way to revert an entire set of chances at once.

I can't belive that this ticket is still open -- this is a really serious problem!

[chris@…]

I guess I just assumed that when I said deleted, the entire changeset would be removed. But yes, I agree with you Jacob.

[Gunnar Wagenknecht <gunnar@…>]

Chris, Jacob, editing ticket comments is NOT a solution for any spam problem. There are several tracking systems out there without a way to edit ticket comments. They never had any issues with spam. The solution is pretty simple: don't allow anonymous editing of tickets. (See also my comment from 12/16/05 03:05:51.)

[chris@…]

Anonymous editing is part of why we chose Trac over other ticket systems.

[jacob@…]

Gunnar: of course disallowing anonymous ticket editing would solve the problem, but it would cause an even bigger problem. If people have to create an account to file a ticket, some of them simply won't file the ticket.

I'd prefer spam to having bugs in my code that I don't know about.

I haven't looked at the Trac code too closely, but it seems to me that this can't be all that hard. Am I missing something? Is there some reason that this ticket has been open for a year without even an optional patch?

[cboos]

No, it shouldn't be that hard to implement. I once wanted to do it, but got distracted by other stuff... If you want to have a try, here are some tips:

• removal of the comment should be a two step procedure, similar to the Delete this version of the Wiki UI.
• when deleting a comment, one should also delete all the ticket changes that were done at the same time. The tricky thing is that all the subsequent ticket changes have to be checked so that their old_value field contain the appropriate value (i.e. the value before the deleted change)

E.g.

1. comment added, version changed from 1.0 => 2.0, priority from low => high
2. version changed from 2.0 => 3.0
3. component changed from engine => doc
4. priority from high => normal

After the removal of comment 1., we should have:

1. version changed from 1.0 => 3.0
2. component changed from engine => doc unmodified
3. priority from low => normal

Hope this helps. The ticket is still on my list, but if someone wants to do it before I find time to do it, he's more than welcome :)

[andrei@…]

Not a fix, but temporary work-around. It looks like in most cases all these spam entries are in some aisan language. As a result following SQL allows you to remove them easily

delete from ticket_change where lower( author ) = upper( author );

[cboos]

Post-poning this. I think it also depends on #2703 in some ways.

In the meantime, for people interested in cleaning up a spammed ticket page, I'd suggest having a look at the TicketDeletePlugin.

[Axel.Thimm@…]

Does anyone have good step-by-step instructions on how to remove these spam comments on the database level?

Thanks.

[chris@…]

This is what I've been sending to other folks:

So here we go. These all require being in your trac-env/db folder (or however you have it setup, you want to be in the folder with the db)

- Deleting comments

1) Run this: sqlite trac.db "SELECT * FROM ticket_change WHERE ticket=406"

Change the ticket number to the one you want to affect.

2) You'll get something like this back:

406|1134596968|tick|commentThis is at least .9, but probably needs to be moved to 1.00

3) Copy the second set of numbers, in this case the 1134596968. This is the time you'll need for the next command

4) sqlite trac.db "DELETE FROM ticket_change WHERE ticket=418 and time=1136229618"

Change the ticket number and the time to what you need. Viola, it's just gone.

- Deleting a ticket (I think, make a test ticket before doing this on a live one)

1) sqlite trac.db "SELECT * FROM ticket WHERE id=549"

2) sqlite trac.db "DELETE FROM ticket WHERE id=549"

Hope this helps. For Growl, the spam got to be too much and I just disabled nondevs ticket rights. It's sad, and not what I wanted, but oh well.

[Chris Ashworth]

Although it won't be sufficient when the spam gets really bad, I've been dealing with comment spam as follows:

I wrote two scripts, gettracdb and puttracdb to download (and upload) the trac.db file to my local machine. I grabbed SQLite Database Browser to edit the database. When I get spammed, I grab the database, open it, go to "Browse Data", select ticket_change, delete the offending rows, and then upload the database back onto my server.

Not a long-term solution, but relatively painless for small volumes.

[anonymous]

i also support verson tracking of ticket edits

[cboos]

#3609 marked as duplicate.

[Pedro Algarvio, aka, s0undt3ch <ufs@…>]

For those worried about spam, wether wiki related or ticket related, I posted a message to the trac-users ML.

• Fighting Trac Spam - It's the way Michael Renzmann is handling this problem. [Direct link to article]

Still, I'd like to be able to at least edit my own tickets on other trac envs, and have full edit/delete power on my own trac envs.

[anonymous]

on an unreleated topic.

sorry for interrupting everyones sleep, wouldnt passing the comment through something like SpamAssassin? and listening to the results before posting the comment to the database be a way to prevent spam? or if not SpamAssassin?, another system, maybe the system thunderbird uses, which IMHO doesnt make any mistakes (AFAIK it hasnt marked one right email as spam for me and I used it for like 4 years)

since these systems already exist, it seems like if one of them marks your comment as spam, something is wrong with it, a fallback solution should be made where the ticket is marked as "moderate" and an administrator can allow/deny it.

sorry to make the comment here, I know cboos says this ticket aint nothing to do with spam, but a lot of people are talking about it and there is my 2c

chris

[cboos]

Replying to anonymous:

on an unreleated topic....

Have a look at the SpamFilter.

sorry to make the comment here, I know cboos says this ticket aint nothing to do with spam,

np, but I didn't say that... In comment:39, I said that editing ticket comments had its use beyond repairing spam damage. Of course, being able to edit/delete comments that made through the spam filter is also useful.

More related to the original topic, I made some notes in the TracDev/Proposals/DataModel about a way to store changes to properties themselves. That way, the old comments could eventually be kept for people wanting to be able to audit all changes that ever happened.

I'm not sure the above will make it for 0.11, though. What could be done for 0.11 is support for editing ticket comments without versioning the old comment content. And that should probably be a configurable feature disabled by default.

[anonymous]

removing my mail from CC (requires some text, otherwise it is accepted as spam)

[maz <mzizka@…>]

Going back to the original request (not spam-related): I've often found a need to edit a comment some other users made, usually in order to correct the formatting.

Yes, it's true that other ticketing systems do not allow comment editing, but in many cases their formatting rules are also a lot simpler, so there are fewer misses. Perhaps an option for an alternative format in ticket comments and description would take care of many of these editing needs.

[cboos]

Not for 0.11, as we need a better data model for storing the comment changes.

[anonymous]

I struggled with this same issue and found a workaround. There are two ways to edit Trac ticket comments directly using the sqlite in a root shell window.

To edit a comment on ticket 42:

$ cd /path/to/trac/project/db/
$ sqlite trac.db

sqlite> SELECT time,author,field 
  FROM ticket_change 
  WHERE ticket = 42;

1172336464|bob|summary
1172337066|bob|owner
1172337215|bill|comment
1172338123|alice|comment

sqlite> UPDATE ticket_change 
    SET newvalue = 'This is the new text of bill''s comment.' 
    WHERE ticket = 42 
    AND time = 1172337215;

sqlite> .exit

Note that in the sqlite console shell any single quotes in a string value must be doubled-up (ala. Python), or you can enclose the entire string value double-quotes, or tripled-double-quotes (another Pythonism)

The sqlite console shell does not allow literal newline or escaped newline characters in a string value, so to edit a multi-line comment you need to dump the entire database to a text file, edit the dump file, and restore the database like so:

$ cp trac.db trac.db.backup
$ sqlite trac.db .dump > dump.sql
$ vi dump.sql (search for the comment text and edit it)
$ sqlite newtrac.db < dump.sql
$ cp newtrac.db trac.db

Also note the trac.db file might not be readable with sqlite3 which is different than plain ol' sqlite which uses a different internal file format.

[trisweb]

I was appalled when I found out I could not edit or delete comments on tickets. This should be obvious and not argued about; if you can't roll back the entire ticket yet, then at least give a way to edit/delete comments. So simple. Just do it.

I can't believe people have to go into the database to manually do this... so dumb. Stop making it more complicated than it needs to be, just implement it now.

[robinbowes]

Well, I would be quite so arrogant as to demand that this be done NOW, but I do share your sentiment that it a fairly obvious defect in trac, and wonder why anyone would think it's not a sensible, high-priority enhancement.

[andrei@…]

Maybe we can "re-ignite" this issue. Maybe if number of replies to this ticket will double of triple, Trac people will pay more attention to it (though it has quite a lot of replies as of now)?

[anonymous]

There is th:TicketDeletePlugin that allows deletion of tickets and comments. That plugin may be integrated into the core at some point. So, the need for comment editing is not as important now unless you need to correct typos or something.

[eblot]

Replying to trisweb:

if you can't roll back the entire ticket yet, then at least give a way to edit/delete comments.

Actually, this is not fully true: th:wiki:TicketDeletePlugin does the job: it allows to delete a whole ticket or any field/comment. It does not perform edition though.

So simple. Just do it.

Really? Well, Trac is an open source project, and developers welcome patches.

[anonymous]

yeah, I commented in this thread nearly 3 years ago.

I run a closed Trac system. I'm admin, I should be able to edit any comment.

My interest in this has nothing to do with spam, and I'm concerned that this ticket has "SPAM" as a keyword. The original request has nothing to do with spam.

I think tying this ticket to spam fighting is way off track.

:-(

[eblot]

Replying to robinbowes:

wonder why anyone would think it's not a sensible, high-priority enhancement.

So many things to implement...

OTOH, Subversion does not allow to delete things...

Moreover, deleting comments may leave orpheneaous links for other locations that pointing at them, so this feature may not be as straightforward as it might look like.

Comment deletion woud still be a nice feature to have for sure. There are many other things that would be nice, still.

[bkc]

The title of this ticket is "Edit Ticket Comments".

Why delete? I just want to fix a typo in a comment. :-(

[anonymous]

If this would be a useful feature to you, either write the code or pay someone to write it. This is open source software after all. Otherwise stop whining.

[anonymous]

I think its marked spam because its killing the open trac systems. Well those of them who have not already implemented mod_security or something to stop it. Either way, bots are on the prowl for trac ticket comment spam.

I would think if this were a huge deal somebody would just make a patch and submit it. You can't demand things when it comes to stuff like this without paying somebody to do your bidding. I personally don't think its a huge deal but maybe thats just because I know how to stop it. But I will admit, it would be very nice feature enhancment. Other than that, I love trac! You simply can't beat it.

[anonymous]

Why don't you try using the Trac plugin which is available for download - the plugin allows you to role back ticket comments. I find it very useful when a ticket has been updated and mistake made.

[anonymous]

Replying to anonymous:

Why don't you try using the Trac plugin which is available for download - the plugin allows you to role back ticket comments. I find it very useful when a ticket has been updated and mistake made.

Because that resolves only the administrative portion of the request. It does not resolve normal user editing abilities, such as correcting typos and whatnot.

This is not just about spam.

[anonymous]

I'm not trying to pile on, but this issue is probably going to keep me from using trac. I'm not expecting anyone to scream oh noes! and run off to do this feature on my account, but I do want to register another vote here. This kind of thing is important, especially since there isn't even a preview for looking at what your wiki stuff is going to look like.

I'll poke around and if its not that hard, maybe I'll submit a patch. But until then, I just submit a vote.

[eblot]

Replying to anonymous:

This kind of thing is important, especially since there isn't even a preview for looking at what your wiki stuff is going to look like.

Sorry, but what are you refering to? You can preview your comments before submitting your changes.

[anonymous]

Replying to eblot:

Replying to anonymous:

This kind of thing is important, especially since there isn't even a preview for looking at what your wiki stuff is going to look like.

Sorry, but what are you refering to? You can preview your comments before submitting your changes.

Doh! I thought I took that part out, after noticing the 'preview' button. Please disregard that part of the comment.

Hey, if I could edit my comment, I could have taken that part out.

[anonymous]

I mark the above comment as the single most important comment made in this thread, it's more important than all of the blabbing by eve