Since they can, people routinely edit their own issue followup comments. Sometimes drastically so. This is annoying, since it's confusing for people reading the issue when latter followups are referring to text that's now gone. It's also very confusing for people reading the issue via email, since we don't send another email when someone edits a comment, so you see the original text but not what someone edited it to say. Also, we prevent people from changing project or issue info while editing -- we always want people to modify an issue by adding another comment.
So, I'd like to add a permission to this module that you have to have to be able to edit issue comments, and then configure things on d.o so that only site maintainers have this permission. It might require a minor hack, since issue followups are comments (IFAC) now, but I think it'd still be worth doing. We'll probably also run into similar problems with #185855: Remove reply links in comments on issues, but at first, I wouldn't mind if the edit links are still there but when you click on them, you get an access denied. Not ideal, but better than what we have now, IMHO.
Comments
Comment #1
webchick-1. I find the ability to edit issue follow-ups invaluable for fixing minor typos and things like that. It's very annoying to have to post another issue follow-up just to re-clarify a sentence, and it's equally annoying to preview every single comment. I use this feature about 3 times daily.
The number of people I've seen who make more than minor adjustments I can count on one hand, and I think we can just educate them on etiquette around the feature. I don't see what we gain from locking other people out of it, really.
Comment #2
webchickAlso, even bigger -1 for introducing a usability problem that will result in 10,000 posts to the webmasters queue about "why do I get access denied when I click edit?" That sounds way, way more annoying than asking people nicely once in awhile to not make major edits to their follow-ups.
Comment #3
dwwHrm. ;) Ok. I'll leave this open for a little while longer to see what arises, but it smells like the future of this issue is in the land of "won't fix"... alas.
Maybe a compromise (not that anyone would read it) would be that if you edit an issue, you get a warning drupal_set_message() that says something like "WARNING: Any changes you make here won't be visible to people following this issue via email. Furthermore, please be conscious if other replies refer to this comment and don't change what they're referencing. If you have something important you want to add or you want to change something about this issue, please just post a new comment."
Comment #4
webchickWell, or 'postponed' until Drupal 6. Just because the feature exists doesn't mean we have to use it on d.o.
hook_menu_alter() lets us do some fun stuff like overriding the access control for comment/edit/%comment to add in a check for user_access('reply to issue follow-ups') or whatever.
I think the dsm() is a waste of time, unfortunately. :( Doesn't seem to stop people from re-titling issues either. :(
Comment #5
gregglesfwiw, I'm in favor of something to fix this. I need hands and toes to count the number of times I've seen it. And educating takes that many *2 comments to educate the user...
I'd also be happy with a dsm since it doesn't push the problem to the webmasters queue and would have at least some effect on people even if it is minor.
Comment #6
Wolfflow commentedJust my two cent on this: I was educated after have understand that some issue are sent through mailing-list.
From the point of view of a beginner as "Site-Maintainer" with "edit" access rights was very easy to understand and take care of not repeating the same error again. ;-)
Sorry forgot to ask @dww what does the abbreviation IFAC mean?
Comment #7
dww@wolfflow: "@dww what does the abbreviation IFAC mean?"
From my original post: "since Issue Followups Are Comments (IFAC) now" (emphasis added). ;) See #18920-36: make project_issue.module use comment.module. for the origin of this acronym.
Cheers,
-Derek
Comment #8
aclight commented@wolfflow: Yet you *still* edited your comment in #6 after you posted it.
Comment #9
Wolfflow commented@aclight:
yes indeed I know, sorry it's because I was convinced that there is a time-delay for "action/triggers" that
control the mailing-action. I'm sorry to say this is a bit confusing, because you do not know which issue is
mailed and which is not. Thanks for remind me. ;-)
Comment #10
Wolfflow commented@dww thanks for your feedback, yes I have oversee your writing.(being in need of new glasses :-)
Comment #11
aclight commented@wolfflow: After you submit a comment, by the time the page has finished loading the emails have been sent. This is different from, for example, groups.drupal.org, which waits until cron runs next before sending messages.
Comment #12
webchickSo this illustrates my point exactly. If we implement this, what role are we going to base this permission on? Obviously, people who are prolific contributors as wolfflow are still getting this "wrong." The 20 site admins? :P
Comment #13
Wolfflow commented@webchick: Thanks for "prolific" attribution. ;-)
@aclight: If this is issue about "edits" is some how managed differently on g.d.o. why we do not apply the same routine on d.o.?
Comment #14
aclight commented@wolfflow: because different modules are responsible for handling the different types of emails. In addition, project issue comments are typically more "urgent" than g.d.o postings, so it makes sense to send them out as soon as they are posted.
Comment #15
Wolfflow commented@aclight: So I understand that on d.o. the issue should be handled differently. I would ask you to be so kind and give me a short summary on when and where this happen, we could insert this information in the Drupal's work space: the issue queue as to inform better all contributors.
Thanks
Comment #16
aclight commented@wolfflow: I don't understand what you are asking me.
Comments should not be edited at all except to correct *minor* typos. For example, if you misspell a word or forget a word it is fine to edit the comment. However, if you are adding new information, changing information that is there, or otherwise changing the content of the comment, you should instead create a new comment.
Comment #17
Wolfflow commented@aclight trying to be more clear: Just wanted to know if the "mailing-trigger" is valid after an "edit" action for all type of "Issue" postings? (i.e. Webmaster-queue Documentation-queue etc.) or there are some differences ?
Comment #18
dww@wolfflow: No, once a comment or issue is *first* created, an email is immediately generated for it. After that, editing does *not* generate any email at all. That's a big part of the premise for this task, and what we've repeatedly said along the way. ;) Not sure how to be any more clear than that...
Comment #19
aclight commented@wolfflow: all issues handled by the project issue module, which means all queues on drupal.org, are handled the same. And mailing is the same whether it's an issue or a comment on an issue. Even if mail wasn't an issue, editing issues other than for typos is *still* a bad idea.
Comment #20
Wolfflow commented@dww @aclight thank you very much for the explanation, and more thank you for your patience with my query.
Cheers
Comment #21
Tor Arne Thune commentedI suggest the ability to edit a post before a certain time limit expires. This way people can fix their own typos and such, but not be able to edit their own posts several days or months after it was posted, leading to confusion for those reading through an issue's comments for the first time, trying to understand the issue.
Comment #22
Wolfflow commentedHi @1V since your post come after almost 3 year this issue was create and I have understood that expert Drupal.org users and contributors just work fine with administrating and managing their issues and comments I think it's time to close this issue.
Kind Regards
Comment #23
dwwI still think we should consider improving this. I don't like that random people can (and do!) go back and edit their comments from weeks/months/years ago. All those "edit" links are just too tempting, and no one seems to consider the impact of "rewriting history" on everyone else trying to understand an issue.
Comment #24
lars toomre commentedI too would encourage turning off edit capability after some period of time as outlined in #21.
I find most of my updates occur within about 10 minutes of original posting. I sometimes need to go back to add punctuation, correct a spelling error or add/correct a link. Does it make sense to delay the automatic e-mail for say 10 minutes to allow for these minor type of edits to occur?
For older comment updates (say after a day), I might suggest that the module automatically append to the bottom some text like "Last edit on XX-XX-XXXX at XX:XX PM".
Comment #25
mgiffordThe one day window sounds good to me. I'd hate loosing the ability to edit out a mistake, but after 24hrs it should just be a new comment.
Appending that text to the bottom of the issue queue edited after that might be good... I can't see it happening all that often though...
Comment #26
Wolfflow commentedWhat's the Status yet?
Seem to me that the majority is for setting a time limit.
I'm not sure it is so yet because it's a long time ago I have learned to check carefully
what I write and then post.
Should we close it as it is now?
Eventually if i am missing something now (I'm sure I am :-) then free to change.
PS:Oh, suggestion #25 is OK for me.