Allow users to edit comments for a limited period only

This is a duplicate of #345737: I can't delete my own attached files but not of #288592: It's not possible to add/edit attachments after the issues has been posted , which is about being able to edit attachments to issue nodes, not comments.

This has been rehashed several times in those issues, so there's no reason to create yet another issue. The suggestion of having a time window during which users can change their comments/issues has been suggested before, and I think the general consensus was that this was a bad idea, particularly with respect to tracking project issues. For some projects/issues, the activity is so low that you could give a 24 hour window for editing and that would not cause a problem. But for some active issues, especially in the Drupal project queue, there might be 5-10 comments on an issue within this time window, so if someone went back and changed a comment it's unlikely that anyone would see the change and if they did it would be quite confusing.

One other problem that some don't seem to realize is that emails for issues and comments are sent *immediately* after the user presses the submit button on an issue/comment. If the page has refreshed with the new comment/issue, the email has been sent. Some people, like myself, follow issues almost exclusively via email instead of using the issue tracker on d.o. It is *very* confusing when I read the email of a followup and then go to d.o to reply to find that the content of the comment or issue has changed. Right now this can only happen if a site maintainer was the one who made the change, but there are enough site maintainers that this happens occassionally.

We all understand why some people want to be able to edit comments, but the risk of confusion and altering what should be a mostly permanent record seem to overcome the desire to have editable comments.

@greg.harvey:

I disagree this is a duplicate. In fact, new issues for specific requests is broadly encouraged behaviour on Drupal.org in my experience.

Sure, new issues for specific requests that have not already been requested or for issues that have not already been discussed are fine. But you yourself found at least two duplicate issues already, since you linked to them in your original issue posting. Furthermore, you yourself made the same feature request in another issue at #345737-15: I can't delete my own attached files.

I also disagree that a 15-30 minute edit window for comments and attachments would pose a problem.

I'm not sure if you are aware of this, but actually until fairly recently it was possible for regular users to edit their comments, at least those on issues. See #306132: Add a permission that prevents users from editing issue followup comments for just one example of some of the problems this created. Since that issue editing of comments on issues has been turned off for all but site maintainers.

Your example of linked in is not really a similar situation. As far as I can tell, that is some kind of social networking site, not a software development site. From my experience it is rare that issue tracking sites allow you to edit comments/follow ups or attachments once you have uploaded/saved the comment/attachment. Google code doesn't, the bugzilla sites I've used don't, I don't recall seeing an edit button on a few Trac sites I've interacted with, etc.

But if your mind is made up, I'll save my typing fingers for something more productive.

It's not just *my* mind that is made up, but the minds of several other drupal.org infrastructure gurus/webmasters. I don't think any of us would have a problem allowing people to make *minor* edits for typos, etc. and other cases where the overall content of a comment does not change. However, as I pointed out in one example, people did not follow that practice, and instead often substantially edited comments and/or changed the attachments, which is an even bigger problem. If I say the patch in #8 is RTBC, and then the author of #8 changes the patch that's attached to #8, the development workflow breaks down.

If you're still determined to try to push this issue, please at least do so in one of the issues that already exists and in which there has already been a fair amount of discussion. Creating a new issue for a problem already discussed just fragments the discussion.

Oh, it seems that all users can still edit their comments. I got the impression from your issue that this was no longer the case. I'm a site maintainer and would be able to edit them either way, so it wasn't obvious that you are primarily speaking of not being able to edit attachments, which is something that it seems even site maintainers can no longer do.

As for crossing out text in a comment that's edited, that is better than not doing so but again any substantive changes will not necessarily be seen by people following the queue via email, since emails are never sent when a comment is edited, only when it's created.

Nobody knows how long it's needed to re-upload the attachments.
Some modules have some posts every few months, so then if you see that nobody replied to actual thread and you made the better patch, then you can't re-upload it again. So making it for 20 minutes is similar to functionality which doesn't exist at all.
There are some modules like node_expire, so after some modification can be done, but what for?
Millions of comments will have their own expiry datetime.

I think it can be easily done by allowing the users viewing the revisions. Everybody can check what was changed recently in some comment or even diff the changes.
It can be extended by functionality, that user can unpublish some revision, which he decide that it's not important for public, but the project maintainer will still see those unpublished revisions for his own purpose. Eventually user will see only some crossed out filenames, that there were uploaded before, but after deleted.

P.S. I agree, everybody can have some their own feature requests.

@kenorb: Drupal core only supports revisions on nodes, not on individual comments nor on file attachments on nodes or comments, so what you propose wouldn't work without a contrib module to support and keep track of all changes to comments.

But that would be a new feature request, so it doesn't belong here. And I don't think there would be much support for this idea anyway. What we have now works quite well for development. If you have a new patch, you just create a new comment, ideally explaining what is different about your new patch compared to the old. It's not difficult, and in the vast majority of cases works quite well.